AWSでのチャットのスケーリングのアイデアは？

Question

私はAWSでチャットサービスを拡張するための最適なソリューションを考え出しています。 - ユーザーは、サーバーがそのユーザーのIDに加入してサーバーへの接続を確立し

1. Redisのパブ/サブ：私はカップル潜在的な解決策を作ってみました。誰かがそのユーザーにメッセージを送信すると、サーバーはユーザーのIDでチャンネルに公開します。ユーザーが接続しているサーバーはメッセージを受信し、適切なクライアントにプッシュダウンします。

2. SQS - 各ユーザーのキューを作成することを考えました。ユーザーが接続しているサーバーは、そのキューをポーリングします（またはSQS long-pollingを使用します）。新しいメッセージが検出されると、そのメッセージはサーバーからユーザーにプッシュされます。

3. SNS - 私は100のトピック制限を発見するまで、この解決策を本当に気に入っていました。 100人のユーザーしかサポートしないユーザーごとにトピックを作成する必要があります。

AWSを使用して他の方法でチャットを拡大することはできますか？ SQSアプローチは実行可能ですか？キューにメッセージを追加するにはAWSがどれくらいかかりますか？

Answer 1

チャットサービスの構築は簡単ではありません。

XMPPサーバー、クライアント、およびSDKのすべてを構築しており、発生する微妙で困難な問題の一部を証明することができます。ユーザーがお互いを見てチャットするプロトタイプは簡単です。アカウントの作成、セキュリティ、発見、プレゼンス、オフライン配信、およびフレンドリストを備えたフル機能システムは、はるかに難しい課題です。それを任意の数のサーバーに分散することは特に困難です。

PubSubは、チャットサービスを構築する伝統的な方法ではなく、チャットサービス（see XEP-60）によって提供される機能です。私は魅力を見ることができますが、PubSubには欠点があります。

あなたのためのいくつかの質問： 1.これはウェブ上で行っていますか？ユーザーが接続しているか、ロングポーリングしているか、Web Socketsソリューションがありますか？

2. ユーザー数はいくつですか？ユーザーあたりの接続数はいくつですか？読み込みに対する書き込みの比率？

3. このようにSQSを使用するあなたの考えは面白いですが、おそらく縮尺は変わりません。チャットサーバーに50k以上のユーザーがいることは珍しいことではありません。各ユーザのSQS Queueをポーリングしている場合は、その近くのどこにも行きません。各サーバーのキューを持つ方がよいでしょう。サーバーはそのキューだけをポーリングします。次に、ユーザーがどのサーバーを使用しているかを把握し、メッセージを正しいキューに入れます。

   1. バックエンドに大きなRDSデータベース：

   私はあなたのような何かを行きたいと思う疑い。

4. クライアント接続を処理する一連のフロントエンドサーバー。
5. 中間層のJava/C＃コードはすべてを追跡し、適切な場所にメッセージをルーティングします。

チャットサーバを構築するための複雑さのアイデアを得るために読んでXMPPのRFCの：は RFC 3920 RFC 3921

Answer 2

（いくつかのフレームワークを使用していない場合）、私はそのようなことを実現するような方法は以下の通りです：

には、ユーザーからのmsgを受け入れるWebサーバー（on ec2）があります。 このウェブサーバー上でオートスキャングループを使用してください。ウェブサーバは、容易に拡大縮小できるアマゾンRDS上の任意のDBを更新することができる。

独自のdbを使用している場合は、sqs（すべての要求を同じキューに送信することによって）を使用してdbをデカップリングし、キューを消費するコンシューマを持つことができます。キューをX msgsより大きくすると、その消費者を自動収集グループの後ろに置くことができるので、キューがX msgsよりも大きければ、それはスケーリングされます（アラームでそれを設定できます）。

sqsは通常非常に高速です。 （それを送った瞬間からそれが待ち行列の上に現れた瞬間まで）、まれにそれ以上です。

Answer 3

SQS/SNSがあなたの欲しい要求に合わない可能性があります。チャットアプリケーションには適さない可能性のあるSQSのレイテンシがいくつか観察されています。また、SQSはFIFOを保証しません。私はAWSのRedisと協力してきました。すべてのベストプラクティスを念頭に置いて構成されていれば、非常に簡単で安定しています。

Answer 4

私はSNSを使ってチャットサーバーを構築することを考えましたが、説明したように、ユーザーごとに1つのトピックを実行する代わりに、チャットシステム全体について1つのトピックを実行し、長いポーリングやウェブソケットのチャットシステムを実行しています。次に、イベントが発生すると、データはSNS通知のペイロードで送信されます。サーバーはこのペイロードを使用して、キュー内のどのクライアントがレスポンスを受け取るべきかを判断し、無関係なクライアントはそのままにしておくことができます。私は実際にはこれのための小さなプロトタイプを構築しましたが、多数のユーザーにとって十分な堅牢性を確認するために1トンのテストを行っていません。

Answer 5

新しいAWS IoTサービスがWebSockets、Keepalive、Pub/Subを数ヶ月前からサポートし始めたので、簡単に弾力的なチャットを作成できます。 AWS IoTは、JavaScriptを含むさまざまな言語用のSDKが多数ある管理対象サービスで、ゼロの管理でモンスターの負荷（数十億個のメッセージ）を処理するために構築されました。

あなたはここにアップデート詳細を読むことができます：

https://aws.amazon.com/ru/about-aws/whats-new/2016/01/aws-iot-now-supports-websockets-custom-keepalive-intervals-and-enhanced-console/

---

編集：

最終SQS更新（11分の2016）：あなたが今使用することができますアマゾンシンプルなキューサービス（SQS）メッセージが厳密な順序で処理され、ファーストイン・ファーストアウト（FIFO）キューを使用して一度だけ処理されるアプリケーションが必要な場合に使用します。 FIFOキューは、メッセージの送受信順序が厳密に保持され、各メッセージが一度だけ処理されるように設計されています。

出典： https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-sqs-introduces-fifo-queues-with-exactly-once-processing-and-lower-prices-for-standard-queues/

今では、SQS + SNSを導入することは、あまりにも良いアイデアのように見えます。

Answer 6

HIリアルタイムチャットはSNSではうまく機能しません。それは電子メール/ SMSまたはサービスのために設計されています1または数秒の待ち時間は許容されます。リアルタイムチャットでは、1または数秒はではなく、が受け入れられます。

check this link

Latency (i.e. “Realtime”) for PubNub vs SNS 

アマゾンSNSは、待ち時間保証を提供していない、との待ち時間の大半は、1秒に亘って測定され、そして多くの場合、多くの秒遅くなります。繰り返しますが、これはやや無関係です。 Amazon SNSは、サーバーツーサーバー（または電子メール/ SMS）通知用に設計されており、数秒の待ち時間が許容され、期待されることが多いです。

PubNubは、既存の確立されたオープンネットワークソケットを介してデータを配信するため、公開からサブスクライブまでの遅延が0.25秒未満です（サブスクライブしたデバイスの95％パーセンタイル）。ほとんどの人間は、イベントが0.6〜0.7秒以内に知覚される場合、何かを「リアルタイム」と認識します。