Node におけるスケールアーキテクチャ考察(Scale 編) - Block Rockin’ Codes
[追記] 途中までは Node での複数プロセス起動、プロセス間通信等について書かれていますが、後半は自分が前回の記事 を書くにあたって自分が考えてたことを少し強引に広げて書いた個人的な妄想が多く含まれ、Node におけると言っときながら、後半は Node 関係ない感じになってしまいました。 正直まだ分かっていないことが多いです。変なところをどんどん指摘していただけるとむしろ嬉しいです。 Node におけるスケールアーキテクチャ考察(SSP 編) - Block Rockin’ Codes の続きです。 もともと何となく結論があって書き始めたんですが、書きながら色々調べているうちによくわからなくなりました。 まだまだ調べたらないことがわかったので、とりあえず今わかっているところまで書きます。 結局何がいいたいのかよくわからない感じかもしれないけど、ゴールは SSP のバックエンドの Nod
Elastic Load Balancerをつかってwebsocketを処理する方法
AWSにはElastice Load Balancerというロードバランサがあります。これはとても安いこともあって多くのお客様のwebサービスで使っていただいています。 最近はwebsocketを使いたい!という声もありますが、いくつかの制限により、 ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法がおすすめです。 そもそも問題は、 ELBの場合、HTTPモードだとそもそも同じポートのままではwebsocketに遷移できない。 ELBでTCPモードにした場合でも60秒でタイムアウトする。 の2点が原因です。そのため、2つの方法があります。 解1: ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法 C ---------> ELB(HTTPモード) --> S ふつうにHTTPでアクセス。
WebSocket アプリの負荷分散 : DSAS開発者の部屋
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
WebSocketについて調べてみた。 - Qiita
実はけっこう前からWebSocketの詳しい仕組みについて気になってて、遂に一念発起して調べてみた。何かとても良さげっぽい。 そもそもWebSocketとは Webにおいて双方向通信を低コストで行う為の仕組み。インタラクティブなWebアプリケーションではサーバから任意のタイミングでクライアントに情報の送信とかしたい事があって、例えばFacebookのチャットアプリみたいに多数のクライアントが一つのページにアクセスしてて誰かがメッセージを投稿するとそれをその他のユーザーに通知したい場合があって、そういった時に双方向通信の必要性が出てくる。 元々はWebにおいてはHTTPしか通信の選択肢が無くてHTTPのロングポーリング使って無理矢理双方向通信実現したりしてたんだけど、流石に無駄が多すぎるし辛いよねって事でWebSocketというプロトコルが作られた。 WebSocketにおいては、TCP上で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Websocketのロードバランス
kakeru.me
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
