AWS Elastic LoadBalancerを使用してWebソケットの負荷を分散する方法について質問があります。
AWS Elastic LoadBalancerの背後に2つのEC2インスタンスがあります。
ユーザーがログインすると、サーバーの1つ(EC2 instance1など)とのユーザーセッションが確立されます。これで、同じユーザーからのすべてのリクエストがEC2instance1にルーティングされます。
今、私は別のシステムから来る別のステートレスリクエストを持っています。このリクエストにはuserIdが含まれます。このリクエストは、最終的にEC2インスタンス2に送信される可能性があります。リクエストのuserIdに基づいてユーザーに通知を送信することになっています。
さて、
1)ユーザーセッションがEC2インスタンス1とのセッションであるが、通知はEC2インスタンス2から発信されていると仮定します。この場合、ユーザーのブラウザに通知する方法がわかりません。
2)ユーザーがロードバランサーを経由するため、64KなどのWebSocket接続と複数のサーバーで克服する方法に制限はありますか?.
ありがとう
他のシステムからのイベントについてブラウザのWebSocketのサーバー側に通知するには、他に何かが必要になります。役立つ可能性のあるパブリッシュ/サブスクライブベースのソリューションがいくつかありますが、詳細を知らなければ、どのソリューションが最適かを判断するのは少し難しいです。一般的にRedisは良い答えであり、Elasticacheはそれをサポートしています。
AWS ELBの制限に関してこれを見つけました: http://docs.aws.Amazon.com/general/latest/gr/aws_service_limits.html#limits_elastic_load_balancer しかし、それらのどれもあなたの質問に関連していないようです。
Websocketリクエストは、WebSocketに渡す前にHTTP通信で始まります。理論的には、最初のHTTPリクエストにCookieを含めることができれば、ELBのスティッキーセッション機能を使用して、WebSocketを特定のEC2インスタンスに転送できます。ただし、WebSocketクライアントはこれをサポートしていない可能性があります。
推奨される解決策は、EC2インスタンスをステートレスにすることです。 WebSocketセッションデータをAWSElasticache(RedisまたはMemcachedのいずれか)に保存すると、使用されているEC2インスタンスに関係なく、着信接続がセッションにアクセスできるようになります。
このソリューションの利点は、個々のEC2インスタンスへの依存関係を削除し、アプリケーションのスケーリングと障害の処理を改善できることです。
ELBの着信接続が多すぎる場合は、自動的にスケーリングする必要があります。そのためのリファレンスは見つかりませんが。 ELBのスケーリングは比較的遅く、数秒ではなく数分です。トラフィックの急増が予想される場合、AWSはより多くのELBリソースを「事前にウォームアップ」できます。これは、サポートリクエストを介して行われます。
また、ELB接続のタイムアウトを考慮に入れてください。デフォルトではこれは60秒ですが、AWSコンソールまたはAPIを介して増やすことができます。アプリケーションは、タイムアウトする前に少なくとも1バイトのトラフィックを送信する必要があります。そうしないと、ELBが接続を切断します。
最近、crossbar.ioWebSocketをALBに接続する必要がありました。基本的に考慮すべきことが2つあります。 1)ターゲットグループの属性でスティッキネスを1日に設定する必要があります。 2)接続がアップグレードされていない場合に静的Webページを返す同じポート上に何かが必要か、ターゲットグループのそのポートを指定するカスタムヘルスチェックを備えた静的Webページを提供する別のポートが必要です。 ELBよりもALBを選択してください。ALBはws://とwss://をサポートしていますが、WebSocketを介したヘルスチェックが不足しているだけです。