今回は技術トピック。
アマゾンWebサービスから「Simple Queue Service (Beta)」がベータリリースされた。
キュー(待ち行列)というのは、要はイベントが発生する頻度についてヒマなときとピークのときで差が激しい場合、それを平準化するためのバッファのことである。
ただのバッファだから、性能要件から言っても根本的なスループットの不足を補うものではない。そう言ってしまえばそれだけなのだけれども、応用次第で性能要件を超えたところで味のある技術でもある。
単純なものではWebサーバに実装されているキュー(ApacheにおけるListenBacklogディレクティブ)がいい例である。アクセスが集中しているとき、プロセス(あるいはスレッド)のプール数が足りなければ、とりあえず溢れたリクエストはキューに突っ込んでおいて、順番が回ってきたらそれを処理してレスポンスを返すし、いつまで待っても順番がこなければタイムアウトしてコネクションを切る。
この例などは、アクセスの繁閑のゆらぎに対するバッファ用途としての典型的な例である。
しかし、バッファの持つ別の側面、例えば「永続化」や「アクセスインターフェースの標準化」という側面を捉えてみると、単なる性能バッファとしての役割以上の価値を持つようになってくる。
今回は、このアマゾンの新サービス登場をきっかけに、キューイング技術がどう発展していく可能性があるかについて考察してみたい。
■「キュー」とは何か
キューとは何か、と題しておきながら、エンタープライズ・コンピューティングにおけるキューの概念は、上記のようなバッファとしての定義をはるかに超えた意味合いで使われることが多い。
メッセージ指向ミドルウェア(MOM)というのがそれである。キューというのは正確にはMOMを構成するほんの一要素に過ぎないのだが、「MOM」と「キュー」は同一視されてしまっていることが多い。
ここで一般的なMOMの通信イメージを提示しよう。
例えばMOMの代表的なものとしてIBMのWebSphere MQというものがある。分散システムの各ノードにMQがインストールされていれば、あるノードから別のノードへと信頼性の高いメッセージ伝送を行ってくれるというMOMである。
ここではすでに、本来の単なるバッファの機能を超えた「配達保証」という、より上位の価値が織り込まれていることに注意しよう。上位アプリ(Producer)から預かったメッセージはMOMの責任において送信できるまでリトライするし、それでも落ちてしまった場合のリラン手順も単純化されている。通信モデルとしてはP2Pで、それぞれのノードがサーバでもありクライアントでもあるという意味で、対称性を持っている。(2)
ちなみに余談だが、「配達保証」といった場合に、「確実に届く」という言い方は正しくない。トランザクションの原子性が保たれる、すなわち「届いたか、届かなかったか、どちらの状態であるかハッキリする」というのが正しい。規定の時間内に何度リトライしても届かなかったら、諦めましたということを送信元に知らせてくれればそれでいいというわけだ。
しかしこのP2Pモデルでは、通信可能なノードのリストの維持や通信内容の管理といった側面で問題が多いことがわかってきた。
特に企業ユースでは、通信可能なノードはレジストリで集中管理したいというニーズは強いし、通信内容も一元化できればビジネス・プロセスを可視化することができる。
そこで、このモデルから発展して、現在ではEAI(Enterprise Application Integration)市場において一般的となったハブ&スポークのアーキテクチャが主流となってきている(3)。WebサービスやSOAの文脈では、ガートナーはこの概念モデルを「ESB(Enterprise Service Bus)」と命名している。
こうすることで、「バスに一度投げ込めば(Publish)、必要なノードすべてに届く(Subscribe)」というマルチキャストも可能になるというわけである。ここまでくると、企業内で分散しているシステム間のビジネストランザクションを一元管理できそうだ、と考えるようになってくるのも不思議はない。(いわゆるEAIベンダーは、BPMだのBAMだのといって、ここのバリューに勝負を賭けているわけである)
さて、ここまではまぁ、通り一遍の解説である。
しかし、ここで見落とされがちなのは、(2)にせよ(3)にせよ、各ノードが「リスナー」を実装しないといけないという点だ。リスナーというのは、簡単に言えば特定のTCP/UDPポートへの着信を待ち受けしている常駐プロセス(サーバプロセス)のことである。
リスナー実装モデルの普及は、カジュアルハック全盛の今日では容易ではない。ただでさえクライアントへの直接アクセスはワームなどの脅威に対抗するためファイアウォールなどでブロックされているのが通常だし、実際問題として並列処理、排他制御、デッドロック回避、バッファリング(つまり受信キューのことだ)など考慮すべき設計項目はぐんと増え、クライアントソフトウェアを作るハードルは一気に上がる。このため、普及を後押しするほど実装の多様性(お手軽なハック)が生まれないのだ。アマゾンのWebサービスでもSOAPよりRESTがメジャーになった背景には、ブラウザさえあれば簡単に動作テストができるというお手軽さにあったのは間違いない。
そんなわけで、もうひとつのトポロジーが浮かび上がってくる。
常にクライアントがトリガーとなってキューにアクセスできるモデルだ。これならキューイング技術のいいところとREST的な簡易実装フィロソフィーの良さを両立させられる。Amazon Simple Queue Serviceは、まさにこの非対称モデルを採用している。(WS-ReliabilityやebXML Message Service V3.0でもプル/ポーリング型のメッセージング仕様が取り込まれつつあるのも、同様の理由によるものだろう)
このモデルを採用することで失われるものは標準の欠如、すなわち将来登場するであろう似たような他のサービスにつながらないことだが、Amazon Simple Queue Service自体がフロンティアである現在そんなことを心配する段階にはない。
■テクノロジーの歴史はダウンサイジングの歴史
ITの歴史において、軍需産業あるいはエンタープライズ市場というのは最先端の技術のテストベッドである。
CPUから半導体メモリ、ハードディスク、そしてプログラミング言語まで、あらゆるテクノロジーの基礎はメインフレームから生まれ、ダウンサイジングを繰り返すことでパーソナルユースまで落ちてきた。
斬新すぎる技術は多くの場合、パーソナルユースではビジネスとして成立しない。
「イノベーションのジレンマ」の理論をかじっていると一瞬逆説的に聞こえるかも知れないが、テクノロジーの多くはまずハイエンド市場で育てられ、そこで実績を積んで(一旦上り詰めて)から段々と下に(破壊的な非連続性を伴いつつ)ジャンプダウンしていくものなのだ(その都度、非連続性を飛び越えられないプレイヤーたちが滅んでいくのは言うまでもない)。エンタープライズの市場で地歩を固めたSUNやOracleやBEAという先達があってこそ、LinuxやMySQLやTomcatの現在と未来がある。破壊的イノベーションというのは本質的に後追いの性格のものであり、決して画期的イノベーションではないのだ。
このイノベーションの変遷は、MOMのキューイング技術にもあてはまる。MQをはじめとするエンタープライズのMOM市場によって、キューイング技術まわりのボキャブラリーが豊かになってきた(例えばエンキュー、デキュー、など)。こういうボキャブラリーが安定して存在しているということはものすごく重要なことで、その存在がディスカッションの土台となり、新たな命名規則やAPIを生み、次世代のイノベーションの素地となる。さしずめ今、市場で起こっているのは、MOMのダウンサイジングということになる。
WebサービスはCORBAの焼き直しだから新しくないとか、そういう議論はくだらない。ダウンサイジングはそれ自体、本質的に新しいのだ。(とはいえ、現在の「WS-*」の仕様セットは、もはやダウンサイジングと呼べないほどオーバースペックである。エンタープライズ市場にあるテクノロジーを何でもかんでも輸入してしまう、ビジョンなきダウンサイジングに未来はない)
そしてこの文脈の中で、アマゾンの新サービスは登場したというわけである。
技術的に見れば何ら新しい要素はないし、ドキュメントを見る限り信頼性面でもちょっと不安があるみたいだ。でも、そんなことは問題じゃない。エンタープライズのテクノロジーとは無縁だった数多くのエンジニアたちがキューイング技術に触れるきっかけとなり、そして何よりも「アマゾンに繋がる」から面白いのだ。
こうして、いつの時代もプロプライエタリなプロダクトやサービスによってデファクトスタンダードが形成され、ISOやJISなどの権威的な標準はあわててその後ろを追いかけるという構図になるのである。
ここのところエンタープライズの先端技術がパーソナルユースに取り込まれるサイクルが早くなってきている。これまでにも何度か書いてきたことだが、GoogleやAmazonがやっていることは、B2Bの世界にも必ず大きなインパクトをもたらすことになるだろう。AmazonのSimple Queue Serviceも、単なる非対称モデルから、P2Pモデル、ハブ&スポークスモデルへと上り詰めていったエンタープライズのMOMテクノロジーの軌跡を辿り、いつかは追いつき追い越してしまうに違いない。
企業間取引でも紙ベースの契約書の存在を前提としなくなるであろう20年後の未来、商取引の標準はAmazon方式になっているかも知れない。少なくとも商法はそれに近い形に大きく書き換わっているだろう。今、WebサービスやSOAと言われているようなものの本流は、IBMやマイクロソフトのようなベンダー企業によってではなく、AmazonやGoogleのような、その頃に強力な支配力を手にしているであろうテクノロジー志向でレガシーフリーのユーザ企業が実装上のデファクトを握る形になっていくことだろう。このぐらい長期的に世の中を見据えたならば、「IT Does Matter」なのである。
♪ 綾戸智絵 / Desperado
※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
メンバー限定サービスをご利用いただく場合、このページの上部からログイン、またはCNET_ID登録(無料)をしてください。
nagahashiさん
そうですね。中小企業は自前でサーバを導入したり保守する人員がいないのが最大の問題だと思うんですよ。
だから、SMTP論者の多くはプロバイダが提供してくれるSMTP/POPサーバをそれぞれSend Queue/Receive Queueとして見立てているのだと思います。(メールと同じで、いつでもバックエンドがオフラインである可能性がある、ラフな運用形態)
ということは、SMTP/POPを使う場合には単なるトランスポートバインディングを超えた専用のプロファイル(実装ガイド?)が必要だと思います。特にPOPサーバ。ポーリング周期についてのプラクティスだとか、一度に全メッセージを取り込んで読むのか一通づつ読むのか、全部読んだ場合に途中でエラーが起きたらどうするのかとか、サーバサイドではメッセージ粒度でのロックもフラグも持てないからトランザクション系の状態は全部MSH as MUAが持つことになるなど、突き詰めると簡単に決められないことが山ほどあります。
しかし、上記でPOPの問題として挙げたことはそのまま、Webサービスなどにおける非対称Pullモデルのクライアント実装にも当てはまることです。(サーバ実装がPOPみたいに枯れてない分、よりハードルが高いとも言えます)
このあたり、ちょっとアイデアがあるので、そのうち形にして世に問いたいと思っています。