2012-03-25 8 views
1

EC2インスタンス(Amazon Auto ScalingとElastic Load Balancingと併用)を使用して、Amazon Web Servicesで動作するTCPサーバのインスタンスがいくつかあります。各EC2インスタンスは、(Amazon RDS上で実行される)集中データベースにアクセスできます。このバックエンドをスケーラブルにするために、(TCPサーバーの)新しいEC2インスタンスは、要求に応じて拡大縮小されます。EC2インスタンス上のTCPサーバをスケーリングする分散問題

サーバーはPython Twistedフレームワークを使用して作成されています。このシステムは、ユーザーが参加できる複数のグループチャットを使用して、カスタムインスタントメッセージングサービスを強化します。

ユーザーがサービスの使用を開始すると、TCPサーバーの1つにTCPソケットが確立されます。各サーバは、現在接続されているユーザ(即ち、開いているTCPソケット)と、各ユーザが現在「入っている」(従って加入している)「グループチャット」をメモリに記憶する。作成されたすべてのチャットデータはデータベースに保存されます。

問題は

ユーザーAがGroupChatZにメッセージをポスト、すべてのユーザーの中に "GroupChatZは、メッセージが表示されます。これは、1つのTCPサーバーしかない場合は簡単です。「グループチャット」内のすべてのユーザーのメモリを検索し、新しいメッセージを送信します。しかし、複数のサーバがあるので、新しいメッセージが作成されるとき、そのサーバがメッセージを他のすべてのサーバ(すなわちEC2インスタンス)に渡す必要があります。

この問題を解決する最も効率的な方法は何ですか? AWSコンポーネントを使用している可能性があります。私は考えることができる


一つの解決策は、それが最初の起動時に、データベースにそのIPアドレスを保存し、他のすべての接続されているサーバのIPアドレスを取得し、それらとのTCP接続をセットアップするために、各サーバー用です。新しいメッセージが受信されるたびに、それを処理するサーバーは、それが接続されている他のすべてのサーバーにメッセージを送信できます。

しかし、TCP接続は100%信頼性がなく、このソリューションは複雑さを増します。私はシンプルな加入者パブリッシャタイプのメカニズムを実装するためにいくつかのAmazon Web Servicesコンポーネントを使用するための良い方法は、実際にそこにある疑いがある


(オブザーバー・デザイン・パターンを考えます)。私。あるサーバーが何かを追加して、他のすべてのサーバーがそのサーバーからメッセージをリアルタイムで取得します。

+0

クイックアップデート、私はちょうどAmazon SNSを使い始め、Twistedサーバーが購読するトピックを作成し始めました。これまでのところ、結果は有望に見えます。 –

答えて

0

TCP接続が100%信頼できないだけでなく、EC2インスタンスも信頼できません。彼らはいつでも消え去ることができます。インスタンスの内部IPアドレスも変更される可能性があります(たとえば、再起動した場合)。エラスティックIPアドレスを使用する場合、AWSデータセンター(チャットクライアントなど)の外部からの接続には、安定した(一連の)IPが接続されます。しかし、サーバ間での通信にElastic IPを使用するのは、接続がAWSファイアウォールの外側にルーティングされてから戻ってくるため、比較的遅いです(最後に確認したとき)。ここで

は、考慮すべきいくつかの戦略です:可用性要件がそう指示する場合

  1. は、ホットスタンバイで、あなたのすべての接続を処理することができ、より大きなEC2インスタンスを使用します。トラフィックの上限がわかっている場合(エンジニアリングのチャットアプリケーションではなく、エンタープライズチャットアプリケーションの場合など)、エンジニアリングの作業を大幅に簡素化できる場合は、スケールアウトするよりもスケールアップする方がコストがかかりません。

  2. さらにスケールアウトする場合は、EH Cacheなどのトランザクション分散キャッシュを使用してチャットデータを保存することを検討してください。その種の問題はすでに解決されています。確立された分散キャッシュの1つがすでに処理しているすべてのケースを処理するのに、多くのエンジニアリング時間を費やします。

+0

1つのEC2インスタンスに冗長性はありません。高可用性を維持しながら、どのように設定変更や配備を行うのですか?キャッシュの考え方は良いですが。 – Diego

+0

@Diego:高可用性が必要な場合は、プライマリサーバ(オプション#1)の現在の状態を反映するホットスタンバイが必要です。サーバーの停止時に5〜10分のダウンタイムが許容される場合は、起動時にDBからチャット状態を自己初期化する方法を知っているEBSベースのAMIを持つことが適切です。元のサーバーのElastic IP(起動時にスクリプトを作成できる)を引き継ぎます。 –

0

私はAmazon SQS(シンプルキューシステム)が役立つと思います。各サーバーにメッセージキューを作成します。メッセージが受信されると、サーバーはすべてのサーバーのキューにメッセージを格納します。サーバーは新しいメッセージのキューを頻繁にポーリングします。サーバが接続されていないユーザ宛てのメッセージを取得した場合、そのメッセージは無視され、それ以外の場合は配信されます。

関連する問題