クラウドにおけるイベント・ベースAPIへのニーズ

作者 Boris Lublinsky , 翻訳者 渡嘉敷 満理子 投稿日 2010年3月9日

セクション

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

運用/インフラ,

設計/アーキテクチャ,

デベロップメント

トピック

SOA ,

Architecture ,

クラウドコンピューティング ,

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

イベント

共有 |

原文(投稿日：2010/02/24)へのリンク

William Vambenepe氏によると、

イベント、アラートおよび通知は、少なくともSNMPの最初のトラップが生成されて以来（おそらく、それよりもずっと前から）、IT管理において中心的な考え方となっています。一方で興味深いことに、クラウドの管理APIおよびプロトコルにおいて、そのようなものはまだ存在していません。

現在のクラウド管理APIの大部分は、まだポーリングに基づいている。George Reese氏によると、そのようなポーリングによるアプローチによって、

... クラウド・プロバイダでは、CPUの性能が極めて非効率的に使用されており、プロバイダとユーザ両方の帯域幅についても無駄に消費されています。われわれは、問題がない程度まで頻度を抑えてポーリングが行えるように、何度も最適化しています。...とはいえ、ほとんどの呼び出しで無駄が多いという肝心な点は残されています。

Reese氏はこの問題を解決するために、イベント駆動型のAPIを介して「対象とするリソースの変化をクラウド・プロバイダが通知すること」を提案しており、さらに、その提案が直面すると思われる課題の一部について、次のように言及している。

• イベント駆動型APIには、現在のクラウド業界にはまだ存在していない標準化の基準が必要です。個々のコンシューマに独自のコールバックAPIを定義させることはできません。さらに、個々のクラウド・プロバイダにおいて独自のコールバック・プロトコルを定義するクロス・クラウド・システムのサポートには、多くの問題が潜んでいます。
• データの提供には逆認証が必要であり、全体のプロセスが複雑になるため、コールバックを介したデータの提供はできません。
• 結局、コンシューマはコールバックAPIを完全には信頼することができません。信頼するには、クラウド・プロバイダが実際正常に機能しているか検証するために、独自に呼び出しを行う必要があります。

Reese氏は、このような課題に対応する場合のシンプルな解決策を以下のように提案している。

• 標準化されたコールバック・フォーマットの導入（[consumer-base]/[asset class]/[id]など、極めて単純なものである必要がある)。
• 既存のクラウドAPIへのイベント・コールバックの導入。

Vambenepe氏はWS-Notification仕様ファミリでの経験に基づいて、シンプルなAPIの構想を積極的に支持している。氏の見解では、クラウド中心のイベント・プロトコルは、より少ないユースケース（クラウドのシナリオのみ）に重点を置くことで作成できる。また氏によると、以下の要素をクラウド・イベント実装の基礎として使用可能だ。

• イベントのタイプ。クライアントは、対象リソースの情報のタイプを指定できる必要がある。

  どのような変更を対象としますか？リソースに対して決められた一連の状態があり、状態の遷移に関してのみ通知しますか？生成イベントについて最低限の重要度を示すことができますか？...

  Vambenepe氏の見解では、WS-Topicsにはこのような問題を解決する場合の最善のアプローチが記載されている。
• イベント・フォーマット。クラウド・イベントは、標準イベント・モデルの定義に忠実でなければならない。

  イベントのメタデータはどのように記録されますか（例えば、監視のタイムスタンプは、通知メッセージが送信された時刻と同一ではない可能性がある)？イベント・データがリソースの新しい状態を表す場合、そのデータは、変更されるフィールド（およびその古い値）を示していますか？

• サブスクリプションの作成。標準的なサブスクリプションのメカニズムを作成し、以下の質問について検討する必要がある。

  サブスクリプションが保持する条件を変更できますか？デリバリのエンドポイントを変更できますか？期限切れを設定するのは誰ですか？プロバイダは最長持続時間を設定できますか？ユーザはサブスクリプションを更新できますか？デリバリのエンドポイントのダウンが原因でサブスクリプションが削除された場合、どのような事態が起こりますか？... サブスクリプションを利用する場合、個別の"サブスクリプション管理"エンドポイント（イベントのデリバリ・ポイントにより異なる）を提供しますか？

• デリバリ・メカニズム。イベントのデリバリには、永続的にオープンされたHTTPコネクション（COMETのLong Pollingに類似）から、HTTP callback URL、XMPP、AMQP、電子メールに至るまで、多くのオプションがある。
• セキュリティ。デリバリのメカニズムに応じて、異なるセキュリティ実装が必要である。
• スロットリング。イベントの実装では、リソースもコンシューマも、生成/受信イベントの量に耐えられるようにしなければならない。

InfoQが以前に報告したように、クラウド・コンピューティングでは非同期APIが非常に重要となる。本格的なイベント・プロトコルの導入によって、この問題を含む、さまざまな問題が解決できるようになる。この仕様の著者が、WS-Notificationから学び、カバレッジやリーチを犠牲にすることなく、よりシンプルなものを作成してくれるよう期待している。