2016-04-04 8 views
9

スラックボットを実装するには、スラックの「リアルタイムメッセージングAPI」に対処する必要があります。 Slackからのイベントをリアルタイムで受信し、ユーザーとしてメッセージを送信できるWebSocketベースのAPIです。詳細:https://api.slack.com/rtmスラックボットをチームの1000にする方法

だけ1チームのためのボットを作成するために、私は1つのWebSocket接続を開き、イベントのためにそれを聞く必要があります。

別のチームのスラックボットを利用できるようにする。新しい websocket接続を開く必要があります。 ので、

  • 1チーム=> 1つのWebSocket接続
  • 2チーム=> 2のWebSocket接続
  • Nチーム=> N用WebSocket接続
  • 私は私のWebSocketをスケールするために何をすべきか

無限のチームのための接続?

どのような種類のアーキテクチャで、1000sのウェブソケット接続の自動スケーリングを処理できますか?たるみソケット付き

答えて

7

、あなたはスケールするものがたくさんあります:ソケットの

  • 数。これは、安価なサーバーでも50kを超えるような何千ものソケットを処理できるため、簡単です。しかし、各ソケットは、次に列挙する負荷のカップルの他のタイプを表します。
  • チームごとに使用されるメモリの量は、独自のサーバー実装によって異なります。大量のメッセージ履歴をメモリに保存しようとすると、メッセージ処理コードが多少ステートレスである場合よりも、サーバーの制限を速く打つことになります。
  • I/Oの量によって、イメージを別のロードバランサにオフロードできます。

さらに、フォールトトレランスが考慮されます。スティッキーロードバランシングを行い、サーバーの1つが50チームを処理しているとします。そのサーバーは50台のチームを扱う唯一のサーバーなので、ダウンすると50台のボットがすべてオフラインになります。あるいは、別のサーバー上でチームごとに複数のソケットを開き、メッセージ処理キューを使用して、各メッセージが1回だけ応答するようにすることもできます。

私が提案するアーキテクチャーは、最初のレイヤーとしてのRTMソケット用の薄い冗長ロードバランサーであり、その下には信頼できるメッセージキューがあります。

+0

ノードは多数の同時ソケットを管理できますが、レイテンシは規模が予測できなくなります。パフォーマンス重視のコードをお持ちの場合は、複数のプロセス間で負荷を均等にするために、何らかの種類のクラスタリングシステムを使用する価値があります。 – tadman

関連する問題