低遅延、大規模なメッセージ キューイング

Question

私は Facebook アプリケーションとクラウド コンピューティングの時代における大規模マルチプレイヤー ゲームについて少し再考しています。

問題の範囲を広げるために、既存のオープン プロトコルの上に何かを構築し、1,000,000 人の同時プレイヤーにサービスを提供したいとします。

各プレイヤーに受信メッセージ キュー (チャットなど用) があり、平均してさらに 1 つの受信メッセージ キュー (ギルド、ゾーン、インスタンス、オークションなど) があると仮定すると、キューは 2,000,000 個になります。プレーヤーは一度に 1 ～ 10 のキューをリッスンします。各キューには平均して 1 秒あたり 1 つのメッセージが含まれますが、特定のキューではレートがはるかに高く、リスナーの数も多くなります (レベル インスタンスの「エンティティの場所」キューなど)。システム キューのレイテンシーが 100 ミリ秒以下であると仮定します。これは、軽度のアクション指向のゲームには問題ありません (ただし、Quake や Unreal Championship のようなゲームには問題ありません)。

他のシステムから、単一の 1U またはブレード ボックスで 10,000 人のユーザーにサービスを提供することは合理的な期待であることがわかります (物理シミュレーションなど、他に高価な処理が何も行われていないと仮定します)。

したがって、クライアントが接続ゲートウェイに接続し、その後メッセージ キュー サーバーに接続するクロスバー クラスタ システムでは、100 台のゲートウェイ マシンを備えたゲートウェイあたり 10,000 人のユーザーが得られ、100 台のキュー マシンを備えたキュー サーバーあたり 20,000 のメッセージ キューが得られます。繰り返しますが、一般的なスコープのみです。各 MQ マシン上の接続の数はごくわずかです。それぞれのゲートウェイと通信するには約 100 個のメッセージが必要です。ゲートウェイ上の接続数はさらに多くなります。クライアント + すべてのキュー サーバーへの接続に 10,100。(これに加えて、ゲーム ワールド シミュレーション サーバーなどへの接続を追加しますが、今のところは分離しておこうとしています)

これを最初から構築したくない場合は、既存のメッセージング インフラストラクチャやキューイング インフラストラクチャを使用する必要があります。私が見つけた 2 つのオープン プロトコルは、AMQP と XMPP です。XMPP の使用目的は、このゲーム システムが必要とするものに少し似ていますが、オーバーヘッドがかなり顕著です (XML、冗長プレゼンス データ、その上に構築する必要があるその他のさまざまなチャネル)。AMQP の実際のデータ モデルは上で説明したものに近いですが、ユーザーはすべて大規模なエンタープライズ タイプの企業のようで、ワークロードはリアルタイムのゲーム アップデート関連ではなく、ワークフロー関連のようです。

これらのテクノロジーまたはその実装に関する日中の経験を共有できる人はいますか?

Answer 1

@MSalters

「メッセージキュー」に関して：

RabbitMQ のデフォルトの操作は、まさにあなたが説明したとおりです。一時的なパブサブ。ただし、UDP ではなく TCP を使用します。

最終的な配信の保証やその他の永続化および回復機能が必要な場合は、それもオプションです。これが RabbitMQ と AMQP の要点です。たった 1 つのメッセージ配信システムで多くの動作を実行できます。

あなたが説明するモデルは、一時的な「ファイアアンドフォーゲット」であり、受信者がどこにいてもメッセージをルーティングするデフォルトの動作です。人々はまさにその理由から EC2 でマルチキャスト検出を行うために RabbitMQ を使用します。ユニキャスト TCP pubsub 経由で UDP タイプの動作を取得できます。きちんとしたね？

UDP に関して:

ここで UDP が役立つかどうかはわかりません。Nagling をオフにすると、RabbitMQ の単一メッセージの往復遅延 (クライアント-ブローカー-クライアント) が 250 ～ 300 マイクロ秒と測定されます。Windows の遅延との比較については、こちらを参照してください (Windows の遅延は少し高かったです)。 http://old.nabble.com/High%28er%29-latency-with-1.5.1--p21663105.html

往復遅延が 300 マイクロ秒未満である必要があるマルチプレイヤー ゲームはあまり思いつきません。TCP を使用すると 300us 未満になる可能性があります。TCPウィンドウ処理 は 生の UDP よりも高価ですが、高速化するために UDP を使用し、カスタムの損失回復またはシーケンス番号/ACK/再送信マネージャーを追加すると、再び速度が低下する可能性があります。すべてはユースケースによって異なります。本当に本当に UDP や遅延 ACK などを使用する必要がある場合は、RabbitMQ の TCP を取り除いて、おそらくそれを実行できるでしょう。

これが、私が Jon のユースケースに RabbitMQ を推奨した理由を明確にするのに役立つことを願っています。

Answer 2

実は今、そのようなシステムを構築中です。

私は、RabbitMQ、Qpid、ZeroMQ など、いくつかの MQ をかなりの量評価しました。これらのレイテンシーとスループットはいずれも、このタイプのアプリケーションには十分以上です。ただし、良くないのは、50 万以上のキューの中でキューの作成に時間がかかることです。特に Qpid は、キューが数千になると非常に著しく低下します。この問題を回避するには、通常、独自のルーティング メカニズムを作成する必要があります (キューの総数が少なく、それらのキュー上のコンシューマは関心のないメッセージを取得します)。

私の現在のシステムはおそらく ZeroMQ を使用しますが、かなり限定された方法で、 内部 クラスター。クライアントからの接続はカスタム SIM で処理されます。私が libev を使用して構築したデーモンは完全にシングルスレッドです (そして、非常に優れたスケーリングを示しています -- 1 台のボックスで 50,000 の接続を問題なく処理できるはずです -- 私たちのシミュレーション。ただし、ティック レートは非常に低く、物理演​​算はありません)。

XML (したがって XMPP) は、これには非常に適していません。I/O に束縛されるずっと前に CPU 処理 XML をペグすることになりますが、これは望んでいることではありません。現時点では Google プロトコル バッファーを使用していますが、これらは私たちの特定のニーズによく適しているようです。クライアント接続にも TCP を使用しています。私は過去にこのために UDP と TCP の両方を使用した経験があります。他の人が指摘したように、UDP にはいくつかの利点がありますが、操作が少し難しくなります。

発売がもう少し近づいたら、さらに詳細をお知らせできると思います。

Answer 3

Jon、これは AMQP と RabbitMQ の理想的な使用例のようですね。

AMQP ユーザーが大企業タイプの企業ばかりだとなぜおっしゃるのかわかりません。当社の顧客の半数以上は、大企業から小規模企業に至るまで、「ウェブ」分野に属しています。多くのゲーム、賭博システム、チャット システム、ツイッター タイプ システム、およびクラウド コンピューティング インフラストラクチャが RabbitMQ から構築されています。携帯電話用のアプリケーションもあります。ワークフローは多くの使用例のうちの 1 つにすぎません。

ここで何が起こっているかを追跡しようとします。

http://www.rabbitmq.com/how.html (del.icio.us のユースケースのリストも必ずクリックしてください!)

ぜひご覧ください。私たちはお手伝いをするためにここにいます。info@rabbitmq.com までお気軽にメールしていただくか、twitter (@monadic) までご連絡ください。

Answer 4

FWIW、中間結果が重要ではない場合（位置情報など）、Qpid には最新の値のみをサブスクライバーに配信できる「最終値キュー」があります。

Answer 5

私の経験は、非オープンな代替手段である BizTalk でした。私たちが学んだ最も痛ましい教訓は、これらの複雑なシステムは高速ではないということです。そして、ハードウェア要件からわかるように、それは直接的に多大なコストにつながります。

そのため、コア インターフェイスでは XML に近づかないでください。サーバー クラスターは 1 秒あたり 200 万のメッセージを解析します。これは、XML でゆうに 2 ～ 20 GB/秒になる可能性があります。ただし、ほとんどのメッセージは少数のキューに対するものですが、ほとんどのキューは実際にはトラフィックが少ないです。

したがって、COTS キュー サーバーから開始し、ボトルネックが特定されたときに各キュー (タイプ) をカスタム キュー サーバーに移動しやすいようにアーキテクチャを設計してください。

また、同様の理由から、メッセージ キュー アーキテクチャがアプリケーションのすべての通信ニーズに最適であるとは考えないでください。「インスタンス内のエンティティの場所」を例に考えてみましょう。これは典型的なケースです。 しないでください 保証されたメッセージ配信が必要です。この情報を共有する必要がある理由は、情報は常に変化するためです。したがって、メッセージが失われた場合、その回復に時間を費やす必要はありません。影響を受けるエンティティの古い位置情報のみを送信します。代わりに、 現在 そのエンティティの場所。テクノロジー的には、これは TCP ではなく UDP とカスタムの損失回復メカニズムが必要であることを意味します。