ポーリングを越える?PubSub、PushおよびMOMを検討

作者 Gavin Terrill , 翻訳者 編集部 投稿日 2008年8月6日

セクション

エンタープライズ・アーキテクチャ,

運用/インフラ,

設計/アーキテクチャ,

デベロップメント

トピック

AMQP ,

メッセージング ,

Webサービス ,

データアクセス ,

SOA ,

Architecture ,

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

エンタープライズアーキテクチャ ,

データベース ,

XMPP

共有 |

OSCON '08(リンク)において、Evan (Rabble) Henshaw-Plath氏(リンク)とKellan Elliott-McCrea氏(リンク)が、「Beyond REST?Building Data Services with XMPP PubSub」(リンク)をプレゼンした。Robert Kaye氏(リンク)がその様子を報告している。

Kellan氏は、FriendFeed(リンク)について話した。それは、自分の友達が新しくアイテムを共有するときに、ユーザに知らせるサイトである。この例では、Kellan氏はFriendFeedはFlickr(リンク)2.9を数百万回ポーリングし、45000人のユーザのアップデートを確認することを指摘した。この45000人のユーザのうち、6700人のみがつねに ログインしている。当然、これは変更されたコンテンツを確認する方法としては頼りない方法である。Kellan氏は「ポーリングは最低だ!」と言う。

この問題を解決するためには、標準REST Webサービスは無視し、メッセージパッシングを使用する方法を探すことが重要である。メッセージパッシングは変更されたコンテンツをユーザに通知する、直接的な通信手段である。

この文脈においては、ポーリングはRESTful Webサービス(リンク)を使用し、各ユーザがアップデートされることである(リンク)。対照的に、PubSub(Publish/Subscribe)(リンク)はアーキテクチャのアプローチであり、パブリッシャーはサブスクライバーから分離されている非同期メッセージパッシングプロトコルを使用する。このような 特徴は、多数のクライアントにアップデートの通知が送信される必要があるシナリオにおいて、PubSubを拡張可能な選択にさせる。

そのプレゼンでは、Evan氏とRabble氏がJabber(リンク)の長所について説明した。Jabberは、XMPP (Extensible Messaging and Presence Protocol)(リンク)に基づいたPubSubサービスである。

1. 持続的な接続上で、XMPPが動作する
2. ステートフルである(SSLはチープになる)
3. イベントストリームプロトコルとして設計
4. 元来フェデレーテッドおよび非同期
5. ID、セキュリティおよび存在が内蔵されている
6. Jabberサーバが構築され、配置される。

プレゼンは、さまざまな議論を巻き起こした。Kirk Wylie氏(リンク)はAMQP(リンク)のようなMOM(Mesage Oriented Middleware)(リンク)ベースのシステムは、ここでさましく必要とされていると主張し、Joshua Schacter氏(リンク)(del.icio.us(リンク)設立者)は、HTTPコールバックに基づいた単純なアプローチが使用できるかもしれないことを指摘した。

頻繁にポーリングをするのではなく、単純に記述されていれば、クライアントは記述先のリソースおよびエンドポイント付きの通常のHTTP要求を送信し、アップデートを以下に提供する。 http://your.app/subscribe?resource=/some/user&callback=http://my.app/endpoint

おそらく、リソースがアップデートされたときのみエンドポイントはRSSアイテムフラグメントを受信する。セキュリティのため、交換には適切なプロトコル から借りた、ある種のトークンを含むようにする。サブスクリプションは、たとえば24時間後に失効する。もしくはパラメーターとして終わる。

評者(リンク)は、そのようなシステムはすでに存在していることを指摘した。Webhook(リンク)である。

Rabble氏は、Callbacksを使用することの自身の考えを述べた(リンク)。

いくつかあるが、Pingbackシステムは、脇へ置くことについて考えたことである。それが明らかに可能であるので、Pingback/Webhook はよいパターンのようである。おそらくアンチパターンではないか?

スケールの大きいWebhookシステムを作成すると、統合機能/クローラーの問題にぶつかるので、そういう場合に役立つ。まったく実行可能である。 XMPPでは、フェデレーションおよびすばらしいインターフェイスがあるその機能性を取得する。また、潜在的にそれに対し委譲権限を追加することができ る。

WebhookのようなアプローチはJabber/XMPPを使用することよりも非常に単純である。しかしながら、Blaine Cook氏(リンク)は複雑性は当然であると考えている。

このシステムが10ラインPHPスクリプトによって使用可能になる必要があると議論するならば、実装が不完全な出力メッセージキューは、当然のことであ る。中程度のスケール(10000ユーザ、各50コンタクト、1/5オフサイト、1日につき2ポスト)では、1秒ごとに2.3リモートHTTP要求がある が、それはまったく問題にならない。

通知用にPubSubを使用するのは、アーキテクチャ上は良いアプローチであるが、多くの人がプレゼンのタイトルで問題を抱えた。Dare Obasanjo氏はRESTはGolden Hammer(リンク)ではないと指摘し、総括した(リンク)。

このように、 Evan氏やKellan氏の話のように、スケーリングしないし、RESTの問題ではない。 たまたま別のシナリオでうまくいくので、これは、問題を解決するのに間違ったツールを使用するという事例である。

他にないのであれば、その議論はAPIコンシューマーの使用パターンを検討することは、適切な設計を決定する際に大きな役割を果たすという事実を強調している。

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