akano です。
今回は、江島健太郎氏のチームが開発した、「ブラウザ上で動くチャット」Lingr の研究を行いました。
チャットという Web アプリは 20世紀から存在するネットアプリです。CGIBOY のチャットは自分もよく使っていました。
チャットというのは複数の人間が同時にアクセスしており、その Web ページはリアルタイムに変化することになっています。そのリアルタイム性を担保するために Web ブラウザは○秒おきにサーバに対してリクエストを送り、サーバは○秒毎の最新のページを生成しブラウザ（クライアント）に送信します（ボーリング）。
それはすなわち、「ただページを表示するだけで」チャットサーバに対して膨大なアクセスがくることを意味します。例えば、1000 ユーザが同時接続している状態で、１秒に１度の間隔でポーリングを行うと、月間で26億ヒットとなり Google のページビュー（12億/月）も超えてしまいます。これではコストが高くチープ革命が達成できません。
開発者江島氏のブログ（前編：機能紹介）（後編：技術解説）によると、この Lingr の特徴として、タグクラウドやプライベートルーム（コミュニティ/アクセス制限）、パーマリンクや画像/動画の貼り付けといういわゆる Web2.0 的な機能の他、お手軽さということを売りにしています。
Lingr は新たにソフトウェアをダウンロードすることなく、firefox 等既存のブラウザ上で、ボーリングによる画面のちらつきや情報の遅延がなくリアルタイムな情報表示が行われます。（ちなみにMSNメッセンジャーは擬似的な P2P モデルで実装されています。）
その仕組みとして、Comet という JavaScript で実現されている仕組みを用いています。
Comet: Low Latency Data for the Browser ： 命名者 Alex Russell による Comet の説明
上ページの和訳
ここでいう Comet とは、従来サーバとクライアントの間でぶつ切りで行われている通信を繋ぎっぱなしにする技術です。
As is illustrated above, Comet applications can deliver data to the client at any time, not only in response to user input. The data is delivered over a single, previously-opened connection. This approach reduces the latency for data delivery significantly.
The architecture relies on a view of data which is event driven on both sides of the HTTP connection. Engineers familiar with SOA or message oriented middleware will find this diagram to be amazingly familiar. The only substantive change is that the endpoint is the browser.
上で図示されるように、Comet アプリケーションはユーザー入力に対するレスポンスに限定されず、好きなときにクライアントにデータを配信できる。データは単一の、事前にオープンされたコネクションを通じて配信される。このアプローチを使うと、データ配信の遅延を大幅に削減できる。
このアーキテクチャは HTTP コネクションの両端でデータがイベントドリブンのように見えるということに拠っている。 SOA やメッセージ指向ミドルウェアに馴染んでいるエンジニアはこの図がそれとびっくりするくらい似通っていることに気づくだろう。本質的な違いは、一端がブラウザであることだけだ。
図は Alex Russell のページで確認してください。
Lingr以外にも、実際にComet型チャットを実装し公開している方もいます。
Dojo には Comet 用の API が装備されています。
しかし、Web サーバの側では、「サーバに対してHTTPコネクションを張り続ける」必要性に対応しておりません。Apache では IdentityCheckTimeout（ Ident リクエストがタイムアウトするまでの期間）を 30 秒に定めるように RFC 1413 で推奨されています。そのため、Comet の機能をフルに用いたアプリを作るには、以前までの作り方の根本を見直す必要があるようです。
Lingr は Java ベースの Jetty 6 を採用し、独自のメッセージング・ハブを構築する道を選んでいます。Jetty による Continuations(継続)については Collection & Copy さんのまとめが分かりやすいです。
江島氏曰く、
チャットというアプリケーションでは、全体のうちかなりの割合の期間をアイドル状態（何もイベントが発生しない状態）が占めます。全体に占めるアイドル期間が長ければ長いほどCometを採用することによる利得が大きくなるということです。
（中略）
従っ先にポーリングだと1000コネクションでグーグルのページビューを超えるほど恐ろしくリソース食いだという話をしましたが、Lingrの現在の見積もりでは、1000同時コネクション程度ならもろもろのアプリケーションオーバーヘッド込みでもLinuxサーバ数台で片付くのではないかと見ています。むしろデータベースへの負荷の方がよっぽど心配です。
とのこと。早速われわれウノウも接続し使ってみました。
使ってみた感想として、確かにリアルタイム性は快適だったのですが、サーバ接続に関しては重いという印象を受けました。これは jetty システムの不適合というよりも DB まわり等、他の問題の可能性があります。
Comet を大々的に取り入れている挑戦的なサービスなので、そのサービスの運営のノウハウは今後の Web 制作の大きな指針となる可能性があると思います。
1016_1st posted from
フォト蔵
1016_2nd posted from
フォト蔵
