XMPPはクラウドサービスの将来像か？

作者 Gavin Terrill, 翻訳者 編集部 投稿日 2008年2月22日 午後6時48分

コミュニティ

Architecture

トピック

EAI,

Webサービス,

SaaS,

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

タグ

Atom

プッシュアーキテクチャ対プルアーキテクチャの議論が再び活発になってきている。この発端は、Jive Software(サイト・英語)のCTOであるMatt Tucker氏(source)が、次のように、XMPPのプッシュベースアプローチがクラウドサービスの将来像(source)であると宣言したことだ。

Webサービスアーキテクチャでは、新たな動きが起きています。クラウドサービスについて、現在は、これがWebアーキテクチャにおける基本的な流れであり(source)、これにより、個別に分かれたサイロの結合から抜け出し、統合がより大きな効果を発揮するサービスのコラボレーティブネットワークへと移行できると盛んに言われています。問題は、現在のクラウドサービスを動かしているプロトコルです。SOAP、およびその他のさまざまなHTTPベースプロトコルは、すべて一方向の情報交換です。このため、クラウドサービスはリアルタイムではありません。また、スケーラビリティが十分ではなく、ファイアウォールをクリアできない場合もあります。このような壁を取り払い、将来のSaaSモデルの原動力となるプロトコルについて真剣に考える時期がきています。解決の手段は、XMPP (Jabberとも呼ばれる)です。聞いたことはありませんか？わずか数年で、Google、Apple、AOL、IBM、Livejournal、およびJiveのすべてが導入しています(source)。

Matt氏は、クライアントが、更新の確認のためにサーバをHTTP経由でポーリングするというよく使用される方法は、非効率的だと述べている。その例として、Tivo、Twitter、およびSalesForceなどを挙げている。これらでは、ポーリングに十分なスケーラビリティがない。

インターネットの登場以来、2つのサーバ間でサービスを同期する場合は、クライアントが一定の時間間隔でホストに問い合わせを行う、ポーリングと言われる方法が最もよく使用されてきました。ポーリングは、私達の多くが電子メールのチェックに使用している方法です。数分ごとにメールサーバに問い合わせ、新しいメールがないかを確認します。これは、ほぼすべてのWebサービスAPIが使用している方法でもあります。

XMPPは、1998年にオープンソースIMサーバjabberdでのプロトコルとして登場して以来、着実にその実績を積み重ねている。XMPPには、次のような利点がある。

• 中央集中型ではない。つまり、誰でもXMPPサーバを立ち上げることが可能である。
• オープン標準に基づいている。
• 成熟性 - クライアントおよびサーバの複数の実装が存在する。
• SASL(source)およびTLS(source)によって強固なセキュリティがサポートされる。
• 柔軟性 - 拡張可能であるように設計されている。

XMPPは、当初はIMを対象としていたが、現在では多種多様なアプリケーションで使用されている。例えば、このインターネットドラフト(source) (Atomフィードフォーマットを使用してシンジケーションされるリソースについて、通知を送信するというもの) はアプリケーション統合の面白い可能性を広げている。Matt氏によれば、XMPPのさらなる普及を妨げている最も大きな理由は、これがHTTPで動作しないという点である。

XMPPの最大の障壁は、HTTPで動作しないことです。現在では、新しいものはすべてWebベースであるべきだというのが常識になっています。この考えに従えば、勇気ある先駆者が私達のために道を切り開いてくれない限り、クラウドサービスにおいてXMPPのアプリケーションが広く普及することはないということになります。

では、XMPPがクラウドコンピューティングにうまく適合できる点はどこだろうか。Matt氏は次のような点を挙げている。

• 双方向通信が可能なので、ポーリングをやめることができます。より強力な、パブリッシュとサブスクライブの機能性が組み込まれています(source) 。
• XMLベースであるので拡張が簡単です。新しいインスタントメッセージ機能、およびカスタムなクラウドサービスのどちらにも最適です。.
• 効率的です。Google GTalkなどでは、単一のサービスで数百万の同時ユーザに対応できることが証明されています。また、世界規模のフェデレーションモデルも組み込みで用意されています。

XMPPだけが、パブリッシュとサブスクライブの機能を実現するものとしてWebアプリケーション開発者の大きな関心を集めているわけではない。例えば、Comet(source)への関心(source)は大きくなっている(source)。 WebtideのCTOであるGreg Wilkins氏(source) は、最近、Jetty(サイト・英語)、およびDojoからのCometd(サイト・英語)を稼動させたサーバでのAmazon EC(サイト・英語)上で、20,000人のユーザ(source)をサポートしていることを報告している。Cometは、XMPPと異なり、HTTPに基づき、Bayeuxプロトコル(source)と連携し、データ交換にはJSONを使用する。

よく聞きたくなる質問の1つとして、どの程度のスケーラビリティが必要かというものがある。Sean McGrath氏も、マッシュアップの構築においてプルまたはプッシュをどのように行うか(source)を考えて、次のように述べている。

Web (XMLからRSS/Atom、AJAXなどのさまざまな付属物を含む) は、プル中心デザインに非常に適しているプラットフォームです。Web上では、情報をプルしようとして失敗した場合は、単にもう一度プルします。成功するまでプルを繰り返し、だめならあきらめます。複雑なことはありません。ただただ、繰り返すだけです。これは、機械が非常に得意とする処理です。昨日の情報を見る場合は、単純に昨日の情報を含むURLを表示します。これにも、複雑なことはありません。URLに日付を含む単純な名前変換で可能です。

XMPPがクラウドサービスの将来像であるかどうかはまだ検討の余地が残るが、現時点において「Webアプリケーションアーキテクトであるなら、XMPPを知っておく(source)必要がある」ことは確かだ。

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

• 次へ >