うさぎの伝言（その1）
前回の宣言どおり、こまめに更新していきます。
今回から数回に分けて、先日のIIJさんとの合同勉強会で聞いたRabbitMQについて調べたことを書いてみたいと思います。めずらしく技術ネタが続く予定です。
◆ 久しぶりのメッセージングミドルウェア
以前のコラムにも少し書いたとおり、私はかつてCORBA (Common Object Request Broker Architecture)に始まり、メッセージングミドルウェアに割と長いこと携わっていました。CORBAに直接的に関わらなくなった後も、SOA (Service Oriented Architecture)に関連する技術を扱っていた関係で、ESB (Enterprise Service Bus)やSCA (Service Component Architecture)の実装をひたすら追っており、それらが連携をサポートしている各種ミドルウェアをいじっていたのです。
また、SOA関係の仕事をしていたころは、システム全体のアーキテクチャを設計することも多くありました。システム全体とは、何らかの形で連携し合うシステムすべてが対象で、多いときには数十のシステムが対象になるようなものです。そんなプロジェクトでは、どのようなアーキテクチャをどんなテクノロジで実現するべきかということに腐心していたので、メッセージングミドルウェアの話題を耳にすると自然とテンションが上がります。
そんな私が勉強会で耳にしたのがMQ (Message Queue)の実装の一つであるRabbitMQです。これはいじってみないわけにはいきません。
◆ MQとは？
MQという言葉になじみのない方のために、簡単にご紹介しておきます。なお、詳しく知りたい方はWebで調べていただければ数多くの情報が入手できると思います。
MQというのは先述したとおりMessage Queueの略語です。これは、システムとシステムをキュー（先入れ先出し）を仲介として連携させるためのものです。MQでは一般的に「パブリッシャ」や「プロバイダ」と呼ばれるメッセージの提供システムと、「レシーバ」や「コンシューマ」と呼ばれるメッセージの受信システムが登場します。これらの間を取り持つのがMQサーバです。
MQはその概念上、単一障害点になりやすいので、MQ製品に求められる可用性も自然と高くなります。MQサーバは未処理メッセージの永続化はもちろん、組み込みのフェイルオーバー機能やレプリケーション機能などが豊富に実装されているのが特徴です。また、メッセージの出し入れの性能がシステム全体の性能に大きく影響するため、単位時間当たりにサーバが処理できるメッセージ数が大きな製品の差別化要因になります。
◆ Advanced Message Queuing Protocol
私がミドルウェアを調べるときには、その製品の生い立ちや実装された背景、製品として目指している方向を真っ先に理解するように努めます。これを知っておくと、情報の行間を読むのに役立つからです。
RabbitMQはAMQP (Advanced Message Queuing Protocol)準拠のMQ実装のようです。このAMQPというのは、2003年頃にJPMorgan Chase & Co.のJohn O'Hara氏によって立ち上げられたもので、MQの通信プロトコルレベルでの互換性を確立するためのオープンな仕様です。つまり、AMQPに準拠している製品同士であれば、MQのパブリッシャ（メッセージキューにメッセージを送信するプログラム）とコンシューマ（メッセージキューからメッセージを受信するプログラム）が異なるMQ製品で実装されていても通信ができるということです。かつてJMS (Java Messaging Service)ではAPIレベルの互換性を保つための仕様が策定されていましたが、そこからさらに一歩進んだ取り組みといえます。
AMQPの取り組みは、今ではOASISに取り込まれているそうです。このAMQPの取り組みですが、主には金融系システムにおけるメッセージング基盤として期待されているようです。
◆ RabbitMQの歴史
さて、話をRabbitMQそのものに戻します。
RabbitMQは2007年の2月にバージョン1.1.0がアルファ版として公開されています。その後数カ月の頻度でバージョンアップを繰り返し、2009年9月には最後の（？）ベータ版としてバージョン1.7.0をリリースしています（リリースノートには当初から「このリリースはアルファ版である」とか「ベータ版である」という記載がされているのですが、1.7.0を最後にこのような記載がなくなっています）。このリリースの履歴を見るだけでも、製品開発は活発で、成熟度も高く、信頼できそうな印象があります。
RabbitMQは、当初LShift社とCohesiveFT社のジョイントベンチャーであるRabbit Technologies社によって開発が開始されています。しかし、その後製品が発展するとともに、Rabbit Technologiesは、2010年にVMWare社の部門であるSpringSourceによって買収されることになりました。現在ではRabbitMQの商用サポートはVMWare社によって提供されているようです。
ちなみにこの当時は、さまざまなオープンソースコミュニティから商用サポート等を提供する企業が立ち上がっていたころです。EJBコンテナとして開発が始まったJBossのJBoss, Inc.やSpringのSpringSource, Inc.がそうでした。そこから、大手企業によるオープンソースのフルスタック戦略が始まったのもこのころです。いくつかの企業は、連携可能なサーバやミドルウェア、ビジネスプロセスエンジン等を次々と買収し、製品スイートとしてサポートをし始めたのです。
ここまで見てみると、RabbitMQは製品としての歴史もあり、開発当初こそAMQP互換を目指したわけではなさそうですが、すぐに互換製品としての方向性を明らかにしていることが分かります。オープンな仕様に基づく運用互換製品というのは、一般的に差別化が難しいと同時に参入障壁も高く、市場として発展しなかった例が多くあります。そんな中、ここまで製品としての発展を続けているAMQPとRabbitMQはかなり気になる存在です。ミドルウェア製品としての筋の良さを感じます。
◆ Erlangの実装
RabbitMQのサーバはErlangで記述されているそうです。これは、個人のレベルで見るとややリスクを感じる部分です。私がErlangを書けないことが理由なのですが、私がアーキテクトとして製品の採用可否を判断する上で、問題が発生したときに最終的に自分が直せるかどうかを考えます。直せないにしても、読み書きのできる言語で記述されているものであれば、なぜその問題が発生するかを想像して回避策を導き出せます。しかし、少なくとも今の段階で私はErlangが書けないので、RabbitMQに何らか不具合があった場合はその理由すらイメージできないと思います。
サーバ製品を導入する場合に、一般的には有償でのサポートの有無などを先に確認する方も多いでしょう。私も当然実際に採用する場合は有償サポートを提供している企業があるかどうかは確認します。それでも、やはり自分で直せるかどうかということを重視しています。おそらく私は自分が責任を持つシステムにおけるブラックボックスをできるだけ減らしたいという性格なのでしょう。
ちなみに、簡単に調べた限りではRabbitMQのサポートを日本で提供している企業はなさそうです。そうなると、一人の技術者としても、企業に属する人間としても、RabbitMQの採用には大きな判断が必要そうです。
◆ 次回予告
実装言語や有償サポートの有無など、サービスの基盤として利用するには躊躇（ちゅうちょ）する要因も多いですが、個人の楽しみで触る分には遜色はありません。次回以降はRabbitMQを用いて、実際に何かを実装する手順などをお伝えしたいと思います。