ビッグデータのリアルタイム処理は、今日最も話題性のあるトピックの１つのようだ。Nokiaは新しいオープンソース製品、Dempsyをリリースしたばかりである。Dempsyは、Storm, Esper, Streambase, HStreaming,Apache S4と同類である。ソースコードがApache 2ライセンスのもとでリリースされている。
Dempsyの狙いは、大量の”ほぼリアルタイムな”ストリームデータを可能な最小の遅れで処理する問題を解決することである。待ち時間がより重要な この類の問題には、以下の様なユースケースがある。
- 広域に分散したシステムをリアルタイムに監視する
- ソーシャルネットワーク データの完全でリッチなストリームを処理する
- 広域分散システムから生成されたログ情報をリアルタイムに分析
- 地球規模でリアルタイムに車両トラフィック情報を統計的に分析
Dempsyの重要な特性は、
- 分散できる。すなわちDempsyアプリケーションは複数の物理マシン上の複数VM上で走ることができる。
- 伸縮可能。すなわちアプリケーションをより多くの（あるいは少ない）ノードに比較的容易にスケールできる。こうするのに、コードや設定の変更が不要であり、処理ノードを動的に挿入あるいは削除することで達成する。
- メッセージ処理を実装している。メッセージパッシングをベースにしている。メッセージプロセッサー間でメッセージを配信するが、これらはメッセージに作用して、エンリッチメント、変換などの単純でアトミックな操作を実行する。一般にアプリケーションは、少数で大きく複雑なプロセッサーでなく、より小さく単純なプロセッサーに分解することを狙っている。
- フレームワークである。J2EEコンテナのようなアプリケーションコンテナや単なるライブラリではない。そうではなくSpring Frameworkのようにパターンの集合であり、それらのパターンを動かせるライブラリであり、これらのライブラリを使ってパターンを実装するために、実装しなければならないインターフェースでもある。
Dempsyのプログラミングモデルは、メッセージを介して通信するメッセージプロセッサーをベースにしており、分散したアクターフレームワークに似ている。アクターが明示的に他のアクターにメッセージを直接送る、 Erlang や Akkaのアクターの意味で、厳密にアクター フレームワークだ、と言っているのではない。 Dempsyのメッセージプロセッサーは、 S4のProcessor Elementやある程度Stormの Boltsに似た、「POJOのようなアクター」である。メッセージプロセッサーは、アクターに似ていて、一度に一つのメッセージしか処理しないので、直接的に並行処理を扱う必要がない。アクターと違って、メッセージプロセッサーはまた、自分の出力メッセージの相手先を知る必要もない。これは内部でDempsyがメッセージプロパティを基に処理されるからである。
手短に言えば、Dempsyは大容量のメッセージ処理問題をPOJOのように実装された比較的単純な処理ユニット間のメッセージフローに分解することができる、フレームワークである。
Dempsy Tutorial にはもっと詳細な情報がある。
InfoQは Dempsyクリエーターで NAVTEQ Fellow のJim Carroll氏に話を聞くことができた。
InfoQ: NokiaはDempsyを何に使う予定ですか？
Jim:Nokia内では、Dempsyを使ういくつものユースケースがありそうです。幾つもの部門がそれを考えています。元々それは次世代の車両交通処理エンジンを実装するために作られました。鉄道センサー、交通事故やGPS配置を含んで、一日で何十億となる個別の生の交通データポイントを取り込み、道路交通情報を様々な最終結果、例えば車両ナビシステム、webベースの地図表示、など他にも多くある結果を提供できる車両交通処理エンジンのためでした。
我々は、膨大な量の生の入力データから、ほぼリアルタイムに、本質的に「リアルタイムなビッグデータ」問題となるような最小限の遅れで、これらの最終結果を生成する分析法が必要なことを認識しました。
InfoQ:様々な既存の実装ではなく、なぜ自分達で実装することを決めたのですか？
Jim: 我々は最初、CEP(ストリームベースサポート）、S4とAkkaのようなアクターモデルを含んで、様々なアプローチを評価しました。
CEPは本当に違う問題を解決するものです。もし大きなデータストリームを小さなサブセットに分解して、あるいは特別なサブセットを別け、その結果を分析したいなら、CEPソリューションは有効です。しかし、もしストリームの各データポイントに同じ事をしたいなら、CEPの能力を充分使いきれないことになります。通常機能を十分使い切れないと言うことは、TOCの増加を意味します。Dempsyはこの種の処理を行うシステムのTOCを削減することが目的です。
他の分散ストリーム処理システムの評価に移りました。評価時にはS4とAkkaが入手できました。
Akkaは違う問題にフォーカスしているようでした。Akkaチームは、JVM用の純粋アクターモデルの実装、「JVM用のErlang」に本当に焦点を当てていました。分散ストリーム処理エンジンではありません。その結果、例えばAkkaチームは Software Transactional Memoryのような課題を解決することに注力していて、分散デプロイを単純化するようなことではありませんでした。純粋なアクターモデルの実装であれば取り組みは意味がありますが、我々の求めているものではありませんでした。
S4を評価しました。処理モデルに関して言えば、S4はまさに我々が求めているものでした。S4の問題は大きな運用環境で常に走らせるには余りに未成熟だ、ということでした。この見方が正しかったことは、S4チーム自身Apacheコードベースから分岐して、S4の新しいバージョン(S4-Piper)を作り始めたことでもわかります。
2011年の９月の終わりにStormが出てきた時には、我々は開発に入ってました。我々はStormが好きです。しかし我々のフレームワークにはいくつか優位点があります。
まず、Stormは「きめ細かい」アクターモデルではありません。このために、両方のシステムで同じユースケースを実装すると、Dempsy実装のほうが小さくなることがわかりました。
また Dempsyが「制御の反転」に力点を置いているために、作成するアプリケーションのテストがより簡単になります。アノテーションの例外により、Dempsyにおいて仕事の不可分な単位であるメッセージプロセッサーは、フレームワーク自身に依存していません。StormのBolt（そしてS4のProcessing Element）はフレームワークのAPIを使って書かれる必要があります。
またシステムに推論できるものを語らせることを要求しない、という格言に従って、Dempsyではアプリケーションパイプラインのトポロジーじは実行時に発見され、事前設定が不要です。これは主に Dempsyが始めから「伸縮自在」であるように設計されている事実の副産物です。その結果、トポロジーは動的に変わることができます。
つまり、多くのブランチやマージのある複雑なトポロジーを持つアプリケーションは、自明に設定できます。ステージ間の依存関係がフレームワークによって実行時に発見されるからです。
InfoQ: あなたは、いろんな所で意図的に Dempsyはアプリケーションサーバーではない、と書いてますね。その意味は何ですか？
Jim: あなたが期待するであろう、アプリケーションサーバーはアプリケーションを助けることです。アプリケーションをアプリケーション・サーバーに「デプロイ」する傾向があります。それからアプリケーション・サーバーは、横断的なサービスセットへのアクセスを提供し、アプリケーションの分離を維持し、アプリケーション間の通信を提供します。分散アプリケーションサーバーは更にコンピュータによるリソース管理とフォールトトレランスのサポートを追加するでしょう。
しかし「１つのことをしろ、それをちゃんとやれ」という古いUnixの格言に従って構築されてきたフレームワークがこのようなことをなぜ実装するのでしょうか？これらは既に容易に入手できたり、これらのフィーチャが既に入手できるものと矛盾しそうな時にですね。業界はこのようなタスクのほとんどが長年、OS自身によって処理されきたことを気づいていないのではないですか？そしてシステムが堅牢なIaaSツールセットによってクラウド環境にデプロイされている時に、誰が新しいリソースの自動プロビジョニングや失敗したリソースの自動再プロビジョニングに責任を持つのでしょうか？専用のソフトウェアがアプリケーションサーバーに作られるべきなのか、あるいはIaaSツールが企業横断で責任を持つべきでしょうか？
それ故Dempsyは「伸縮自在性」の実装を通して、これらのサービスと協調するように作られているので、IaaSツールは、負荷に応じて新しいシステムをプロビジョンしたり、古いシステムを再プロビジョンしたりします。アプリケーションは自動的に応答します。このためにDempsyは単純になり、特定の目的で作られたツールと矛盾したり、競合するのではなく協調することに注力できますし、ツールとの相乗作用で結局、より安価なTOCで、より堅牢なエコシステムを作り上げることができます。
InfoQ:Dempsyはメッセージトランスポートして何を使ってますか？
Jim:Dempsyは抽象セットの上に構築されていて、フレームワーク自身が容易に拡張でき、適合できるようになっています。この中には、ルーティング戦略、監視、シリアライズ、クラスタ管理が含まれています。またメッセージトランスポートも入っています。これら抽象モジュールの最終デフォルト実装は、チームが最も重要であると考える順番で開発されます。シリアライズとメッセージトランスポートはリストの終りの方ですね。
なので1.0リリースの前はトランスポートにNettyを使う計画です。 Zero-MQも議論されましたが。現在は単純なTCP実装です。
InfoQ:Dempsyではルーティングはどのように実装されていますか？
Jim: Dempsyはメッセージキーを基にして、メッセージをメッセージプロセッサーにルーティングします。メッセージがどのキーを持つか決めるスキームは、アプリケーションが特定します。しかしそのキーは、クラスタマシンに分散した特定のメッセージプロセッサーインスタンスのアドレスになります。ルーティングはその時2つのステージプロセスです。１つは、我々が「ルーティング戦略」と読んでいるものを使って、メッセージプロセッサーが存在するクラスタのどのノードかを決めます。2つ目は、メッセージがそのノードに受け取られると、そのメッセージに責任を持つ特定のメッセージプロセッサーを見つけ出す。
既定のルーティング戦略は、メッセージのキースペースを「ビン」のセットに分割する（すなわち特定のメッセージクラス用の全ての可能なキーの集まり）。これらのビンとそのメタ情報は、分散ネゴシエーションスキームによって、動的に走っているノードに割当てられる。すなわち中心的なマネージャやブローカは介在しない。これは Apache ZooKeeperの「リーダー選出」ネゴシエーションユースケースに似ているが、Dempsyの場合は、それをするのは、各ビンの「ビン オーナーシップ」です。
InfoQ:Dempsyは個々のメッセージプロセッサーのスケーリングはどのようにサポートするのですか？
Jim: メッセージプロセッサーの粒度と独立性がキーで、それは本当にアプリケーション設計の一部です。もしキースペースが10でなく100万の単位なら Dempsyはそれをネットワーク・インフラが線形なスケーラビリティの唯一の限界点まで、コンピュータ上のリソースセット間でそれを線形的に分配します。
InfoQ: Dempsyクラスタのトポロジが変わった時、 Dempsyはどのようなメカニズムを使ってメッセージプロセッサーを再分配するのですか？
Jim:Dempsyは、クラスタ情報管理実装の通知機能に依存しています。既に言いましたように、クラスタ情報管理は、Dempsyフレームワーク内の抽象モジュールの1つなので、実装を外すことができます。既定では、分散モードで動いている時、クラスタ情報管理は、 Apache ZooKeeperを利用して実装されています。
トポロジが変わった場合、その影響を受ける全アップストリームノードは、変更を通知され、どのキーがどのノードに対応するか解釈し直します。影響を受けるクラスタ内の他のノードも通知され、ビンオーナーシップを再ネゴシエーションします。
InfoQ: メッセージプロセッサーノードの1つに障害が発生したらどうなりますか？
Jim:メッセージプロセッサーノードの障害は、物理的トポロジ変化の特別な場合です。ノードの1つに障害が発生したら、同じクラスタ内の他のノードが知り、新しく入手できるビンのために再ネゴシエーションします。このネゴシエーションにより、物理的トポロジ変化のアップストリームへの通知になり、その結果調整が行われます。