Comet: 1秒未満のレイテンシで1万人超のユーザを処理する

作者 Alexander Olaru , 翻訳者 岡田 英久 投稿日 2008年2月14日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

RIA ,

Java ,

パフォーマンス&スケーラビリティ

タグ

Jetty ,

Dojo

リバース AJAX としても知られる Comet の主な目標は、HTTP 1.1 がもつ永続的接続の特性を生かし、サーバ側で発生した状態の変化をリアルタイムにキャッチしてクライアント側の更新を可能にすることである。 Infoq.com で以前も説明したとおり(記事)、Comet と同様の他のプッシュ技術も存在し、同じ目標の達成を目指している。

Greg Wilkins 氏と、オープンソースの WEB サーバ Jetty (source)の主要開発者によって結成された会社 Webtide(source) にある彼のチームは、Comet のスケーラビリティを測定する目的で多くのパフォーマンステストを実施し、その調査結果について記事を書いている(source)。より具体的に言うと、そのテストでは Jetty 上で Bayeux プロトコル(source)の実装である Dojo Cometd(source) を走らせた。Cometd が稼動しているサーバも、クライアントマシン（ 1 ～ 3 台で構成され、全体で 20,000 ユーザに相当する負荷を生み出す）も、同様に Amazon EC2 仮想サーバの Large Instance (source)である。このテストの結果をグラフにまとめると次のようになる。

このテストから得られた結果で強調すべき点は次のとおりである。

• ユーザが 20,000 人いてもレイテンシを 1 秒未満に抑えることは可能だった。しかし、レイテンシとスループットの間にはトレードオフがある。5,000 人のユーザがいる場合、スループットが毎秒 2,000 メッセージであればレイテンシは 100ms 、スループットが毎秒 3,000 メッセージであればレイテンシは 250ms 超に増大する。
•  テストに使ったアプリケーションは一部屋に最大 200 ユーザが入ることのできるシンプルなチャットルームである。各テストのための負荷として、50 バイトのペイロードが、ランダムに選択された 10 個のチャットルームに向けて一定間隔で一斉に送られた。間隔は選定されたものであるため、サーバ CPU のアイドル時間はおよそ 10% と 50% という安定した状態が得られた。
• Greg 氏は「 1 台のマシンでは、それぞれ自分のコンピュータとネットワークインフラをもつ 20,000 人のユーザと同等の負荷を生み出し、処理することはできない」ということを認識していた。この制限を部分的に補うために、テストの一部（上記グラフの緑色の円を参照）では 3 台の異なるマシンを稼動させてユーザをシミュレートした。
• 3 台のクライアントマシンによるテストで、1,000 人のユーザをシミュレートしたマシンからレイテンシの測定値を取り出した。厳密に測定されたわけではないが、Greg 氏は、残りの 20,000 人のユーザを処理する他の 2 台のクライアントマシンのために観測されたレイテンシの上限は、1 台のクライアントマシンでテストを行ったときに観測されたレイテンシと同程度になるだろうということに言及している。
• Jetty 6.1.7 にバンドルされている Cometd のデモにいくつかの変更が必要である。変更のうち一部はサーバのスレッドプールにおけるロックの欠乏状態を軽減することに関連しており、その他はセットアップ処理に関わっている。

コメントおよび Greg 氏の以前の投稿(source)で述べられているとおり、Jetty は非同期にメッセージをクライアントに送ることができるので、同じ数のユーザを処理するにもリソースが少なくて済む。今回のテストで適用したスレッドプールのコードへの変更はこちらからダウンロード(source)することができ、Greg 氏が InfoQ に語ったところによると Jetty の次のリリースに組み込まれることになるそうだ。彼はさらに、Webtide が現在ロードバランサを通した類似のテストを行っており、まもなくより多くのテスト結果が公開されるだろうと付け加えた。 

Comet のスケーラビリティに関する問題に対処するもうひとつの興味深いアプローチは Lightstreamer(source) が採用している方法だ。その実装は、アプリケーションサーバや WEB サーバに依存しないスタンドアロンのサーバに基づいている。ストリーミングエンジンとして動作するよう拡張された WEB サーバやアプリケーションサーバはコネクションごとにひとつのスレッドを割り当てるモデルを用いている。それに対して Lightstreamer はサーバが維持可能なコネクションの数をサーバが管理するスレッドの数から切り離しているため、サービスをたくさんのクライアントにスケールすることができる。

Lightsteamer の CTO、Alessandro Alinone 氏との対話によると、彼らは金融業界に顧客をもっており、その運用においては同時アクセスしてくる平均 10,000 人のユーザに対してそれぞれ毎秒平均 3-5 回の更新リクエストを処理している。また、Lightstreamer は OEM 契約のもと TIBCO Ajax Message Service のコアエンジンとして採用されており、TIBCO のフロントエンドにも次第に興味深い機能が現れつつある。

サーバのほか、Lightstreamer のバックエンドアーキテクチャ(source)には以下のものが含まれる。

• A Data Adapter - データソースを Lightstreamer につなぎ合わせるためのプラグインモジュール。Data Adapter にはどのようなテクノロジを利用してもよいが、非同期なデータフィード（例えば JMS、TIB/RV、MQ ）を使えば、クライアントへとつながる非同期のチェーンが破壊されるのを避けることができる。
  
• A Metadata Adapter - プッシュセッションのメタデータを Lightstreamer サーバに送るためのプラグインモジュール。

NET. クライアントサイド(source)では、通常ブラウザは静的な WEB ページをサーバから受け取るが、Lightstreamer サーバからはプッシュされてきたリアルタイムの更新を受け取る。これらの更新データを利用するのは、ほとんどのブラウザに互換性をもち、ほとんどのサードパーティ製 AJAX フレームワークやツールキットと共存・統合が可能な Lightstreamer JavaScript ライブラリである。Lightstreamer からプッシュされてくるリアルタイムの更新は、Flash/Flex アプリケーションでも、Java や .NET で開発されたデスクトップアプリケーションでも、受け取ることができる。

原文はこちらです：http://www.infoq.com/news/2008/01/comet-scalability

• 次へ >