10

AmazonのEC2でクラスター化されたTigaseXMPPサーバーを実行した経験のある人はいますか？主に、私をつまずかせる可能性のある、自明ではないことについて知りたいです。（たとえば、EC2でEjabberdを実行すると、Mnesiaが原因で問題が発生する可能性があります。）

または、UbuntuにTigaseをインストールして実行するための一般的なアドバイスがある場合。


追加情報：

私が開発しているシステムは、モバイルアプリとサーバーの間で（ほぼリアルタイムで）通信するためだけにXMPPを使用しています。

ユーザー数は最初は少ないですが、うまくいけば増えるでしょう。これが、システムがスケーラブルである必要がある理由です。おそらく、ほんの数千人のユーザーにとって、cc1.4xlarge EC2インスタンスは必要ないでしょうか？（そうでないと、これを実行するのに非常に費用がかかります！）

XMPPサーバーデータベースには、AmazonRDSでホストされているMySQLデータベースを使用する予定です。

また、 SleekXMPPを使用して、Pythonで記述された外部XMPPコンポーネントを作成する予定です。私が作成しているアプリケーションはインスタントメッセージングとはまったく異なるため、サーバーのすべての「作業」を行うのはこの外部コンポーネントになります。この部分では、Pythonで記述された外部XMPPコンポーネントをTigaseサーバーに接続する方法を理解していません。ドキュメントは、コンポーネントがTigase専用に記述されていることを示唆しているようです。予想どおり、 XEP-0114： JabberComponentProtocolを使用して一般的なXMPPサーバー用に記述されているわけではありません。

この追加情報を使用して、他に何か考えていただければ、喜んでお知らせします。

ありがとうございました ：）

4

1 に答える 1

26

私はたくさんの経験があります。自明ではない問題がたくさんあると思います。Tigaseのようなアプリケーションを実行する唯一の信頼できるインスタンスのようにcc1.4xlargeです。他の人はCPUの可用性に問題を引き起こします。これは、他の人が働いている忙しくないサーバーでサービスを実行するのに十分幸運であるかどうかにかかわらず、宝くじです。

また、ネットワークトラフィックに対応できるようにするには、I/Oが可能な限り高いインスタンスが必要です。高いI/Oは、特にデータベースインスタンスに適用されます。

これが明らかかどうかはわかりませんが、EC2のホスト名にはこの問題があり、インスタンスを起動するたびにホスト名が変更され、IPアドレスが変更されます。Tigaseクラスターはホスト名に非常に敏感です。インスタンスのホスト名を強制/変更する方法があるため、これが問題を回避する方法である可能性があります。

もちろん、私は何百万ものオンラインユーザーのクラスターと、1秒あたり10万XMPPパケット以上のトラフィックが非常に多いことについて話しています。一般に、大規模なインストールの場合、専用サーバーを使用する方がはるかに安価で効率的です。

通常、TigaseはAmazon EC2で非常にうまく動作しますが、特にクラウドでのテスト後に多くの最適化が追加されているため、最新のSVNコードが本当に必要です。あなたがあなたのサービスについてもう少し詳細を提供するならば、私はいくつかのより多くの提案があるかもしれません。

その他のコメント：

コストに関して言えば、専用サーバーは常にサービスを実行するためのより安価なオプションです。サーバーのオン/オフを1時間ごとに切り替える予定がない限り、専用のサービスを利用することをお勧めします。コストは低く、パフォーマンスははるかに予測可能です。

ただし、本当にAmazon EC2に固執する必要がある場合は、具体的な数値をいくつか示します。以下に、インスタンスのリストと、クラスターが確実に処理できたオンラインユーザーの数を示します。

  • 5*cc1.4xlarge-1mln700kオンラインユーザー
  • 1*c1.xlarge-118kのオンラインユーザー
  • 2*c1.xlarge-127kのオンラインユーザー
  • 2 * m2.4xlarge（Tigase用に5GBのRAMを搭載）-236kのオンラインユーザー
  • 2 * m2.4xlarge（Tigase用に20GBのRAMを搭載）-315kのオンラインユーザー
  • 5 * m2.4xlarge（Tigase用に60GB RAMを搭載）-40万人のオンラインユーザー
  • 5 * m2.4xlarge（Tigase用に60GBのRAMを搭載）-312kのオンラインユーザー
  • 5 * m2.4xlarge（Tigase用に60GBのRAMを搭載）-327kのオンラインユーザー
  • 5 * m2.4xlarge（Tigase用に60GBのRAMを搭載）-28万人のオンラインユーザー

さらにいくつかのコメント：

  1. なぜメモリの量がそれほど重要なのですか？これは、CPUパワーが非常に信頼性が低く、cc1.4xlargeインスタンスを除くすべてのインスタンスで一貫性がないためです。8つの仮想CPUがありますが、一番上のコマンドを見ると、1つのCPUが機能していて、残りは機能していないことがよくあります。この不十分なCPUパワーにより、Tigaseの内部キューが大きくなります。CPUパワーが回復すると、Tigaseは待機中のパケットを処理できます。Tigaseのメモリが多いほど、キューに入れることができるパケットが多くなり、CPUの欠陥をより適切に処理できます。
  2. なぜ5*m2.4xlargeが4倍あるのですか？これは、異なる曜日と時間帯に何度もテストを繰り返したためです。ご覧のとおり、日時に応じて、システムはさまざまな負荷を処理できます。これは、Tigaseインスタンスが他のサービスとCPUパワーを共有しているためだと思います。彼らが忙しい場合、TigaseはCPUの電力不足に悩まされていました。

とはいえ、最大10,000人のオンラインユーザーをインストールすれば問題ないと思います。ただし、名簿のサイズなどの他の要因は、トラフィックと負荷に影響を与えるため、非常に重要です。また、大量のトラフィックを生成する他の要素がある場合、これはシステムに負荷をかけます。

いずれにせよ、いくつかのテストがなければ、システムが実際にどのように動作するか、またはシステムが負荷を処理できるかどうかを判断することは不可能です。

そして、コンポーネントに関する最後の質問：

もちろん、Tigaseは外部コンポーネントを接続するためのXEP-0114とXEP-0225をサポートしています。したがって、これは、異なる言語で記述されたコンポーネントでは問題にならないはずです。一方、コンポーネントの作成にはTigaseのAPIを使用することをお勧めします。これらは、内部Tigaseコンポーネントまたは外部コンポーネントのいずれかとしてデプロイできます。これは開発者にとって透過的であり、開発時にこれについて心配する必要はありません。これはAPIとフレームワークの一部です。また、Tigaseフレームワーク、スクリプト機能、監視、統計、テストの内部コンポーネントとしてコードを簡単にデプロイできるため、開発がはるかに簡単なすべての商品を使用できます。XMPP固有のものについて心配する必要はありません。processPacket（...）メソッドの本体に入力するだけで、それだけです。

また、マルチスレッドのPythonサポートと、非常に高い負荷の下でのPythonの動作について読むことをお勧めします。以前はそれほど素晴らしいものではありませんでした。

于 2011-12-29T19:38:19.767 に答える