WebSocket on AWS Yuta Imai Solutions Architect, Amazon Data Services Japan, K.K.

WebSocketについて

•  リアルタイム/インタラクティブなアプリケーション、特にゲームなどでWebSocketが利用されることが増えている。

•  AWS上での利用事例も増えている。

•  WebSocketでも可用性やスケーラビリティをあげるためにロードバランサーを使いたい！

•  トラフィックの性質がHTTPと異なるので、Elastic Load Balancing(ELB)含め、ロードバランサーとの付き合い方を変える必要がある。

おさらい(1)：HTTPとTCPコネクションHTTPではリクエスト/レスポンスごとに空いているTCPコネクションを利用する(なければ新規作成する) ➔HTTPセッションとTCPコネクションが非依存

GET / HTTP/1.1...

HTTP/1.1 200...

GET /foo.html HTTP/1.1...

HTTP/1.1 200...

GET /a.jpg HTTP/1.1...

HTTP/1.1 200...

コネクション新規作成

空いていれば再利用

空きがなければさらに新規作成

時間

WebSocketはセッションごとにTCPセッションを作成し、セッション中は継続的に利用する。 ➔アプリケーションのセッションがTCPコネクションに依存する。 ➔アプリケーションのセッションが終了するまでそのTCPコネクションは専有される。

GET /chat HTTP/1.1 Host: ... Upgrade: websocket Connection: Upgrade

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade

message

message message

message

おさらい(2)：WebSocketとTCPコネクション時間

WebSocketとロードバランサー(LB)•  前述のとおり、WebSocketはクライアント・サーバー間でアプリケーションのセッション数に応じてTCPコネクションが持続的に専有される。

•  間にLBを挟むとLBのコネクションも専有してしまう。LBのリソースがボトルネックになり得る。

•  WebSocketはサーバーとクライアントを1対1でセッションを確立させ、それを維持して利用する仕組みなので、セッションが確立されてしまえばLBはあまり意味がない。遅延が増加するというデメリットもある。

•  セッション確立時だけLBを使うのが上手な付き合い方。

1. わたしはどこに行けば？

2. 君はApp server2へ！

3. WebSocket接続おねがいしまーす

App servers

GET /app HTTP/1.1 Host: ... Upgrade: websocket Connection: Upgrade

GET /dispatch HTTP/1.1 Host: ...

HTTP/1.1 200... ... Goto ws://App server2

セッション確立時だけELBを使うアーキテクチャ

コネクション数のレポート

Auto Scaling group Dispatchers ディスパッチ時に各サーバーのコネクション状態を確認

このアーキテクチャの利点

•  ロードバランサを挟まないため： –  ロードバランサによるコネクション切断はない –  ロードバランサのポート枯渇等による新規接続の棄却は起きない –  ロードバランサによる遅延の増加は起きない

•  負荷（例えばコネクション数）に応じてアプリケーションサーバをスケールさせられる

•  ソケットサーバの障害にも対応可能 –  クライアント側で別サーバーに再接続するなどの仕組みも重要

注意点

•  クライアントのディスパッチ先は別途管理して、アプリケーションがクライアントに正しく通知できるようにする

•  アプリケーションサーバの数を減らす際は、コネクション切断の影響を抑えるため、十分なクールダウンをする –  クライアントに再接続を実装することで影響を小さく

運用のTIPS

•  アプリケーション・サーバーは負荷（例えばコネクション数）に応じてスケールさせる

•  アプリケーションサーバの障害への考慮 –  クライアント側で別サーバーに再接続するなどの仕組みが重要。 –  ゲームの場合、そのゲームプレイは一旦終了させ、新たなゲームを始めてもらうイメージ。

まとめ

•  WebSocketを使うときはセッション確立とアプリケーションセッションを分けて考える

•  ELBはセッション確立（ディスパッチャ）側だけで使う

(参考)HTTPとELBセッションがTCPコネクションを専有しないので、LBとEC2の間で少ないTCPコネクションを効率的につかいまわすことができる。

(参考)WebSocketとELB•  現状、ELBはWebSocketをサポートしていない。

–  Socket.ioを使うと動くように見えるが、これは単にSocket.ioがHTTPにFallbackしているだけ

•  TCPモードで動かすことにより、セッション開始時のロードバランシングは可能。 •  しかしセッション確立後、クライアントは特定のEC2と継続的に通信し続けるのでLBの意味がない。

•  にも関わらず、ELBのリソース(コネクション)を利用されつづけてしまう

※もしそれでもこの方式をとる場合、ELBには非アクティブなセッションを切断する機能があるのでこれにも注意が必要。(タイムアウト値は設定可能)