InfoQ

News

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

作者 Alexander Olaru, 翻訳者 岡田 英久 投稿日 2008年2月14日 午前12時58分

コミュニティ
Java
トピック
RIA,
パフォーマンス&スケーラビリティ
タグ
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

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。