Esperに迫る：イベントストリームプロセッシングフレームワーク

作者 Floyd Marinescu,Thomas Bernhardt , 翻訳者 編集部 投稿日 2007年10月15日

セクション

デベロップメント,

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

設計/アーキテクチャ

トピック

Java ,

メッセージング

タグ

Esper ,

Event Stream Processing

Esper（InfoQにてそのバージョン1.0のリリースが一年以上前に発表されている(記事・英語)）は、イベントストリームプロセッシング（ESP）で、またイベントストリーム内でイベントコンディションが生じた時に動作を引き起こすイベント相関エンジン(CEP)である。またそれはステートメントが登録されデータストリームが流通する上下逆になったデータベースとして考えられ得る。イベントプロセッシングはソフトウェア業界で現在流行となりつつあり、たくさんのスタートアップに次いで数社のベンダー達が市場に参入している。通常の使用ケースはアルゴリズムトレード、BAM、RFID、アドバンスモニタリングシステム、不正検出からSOAとの直接関係までに及んでいる。InfoQはそのプロジェクトの最近の開発状況を探るためThomas Bernhardt氏とAlexadre Vasseur氏に尋ねた。

Esperチームによれば、EsperはEsperTech(サイト・英語)と呼ばれる会社に商業的にサポートされている現在ただ一つの純粋なJavaオープンソースESP/CEPエンジンである。またそれは.NET実装を行っているものである。

EsperはBEAにライセンスされており、また6月にリリースされたWebLogic Event Server(サイト・英語)への導入のため修正されている。いろいろな反響(source)を踏まえてThomas氏はInfoQにて下記のようなコメントをしている。

EsperがBEAの製品において一躍買っているということは、Esperのプロジェクトを数方向で援助することになる。一つ目はフィードバックが向上したEsperに再合併されている。二つ目はBEAの製品はCEP/ESPテクノロジに関する認識を大幅に広めるので、その市場とマインドシェアを拡大するということになる。
3番目にそれはEsperのテクノロジがどれぐらいオープンで拡張性があり、またエンタープライズグレードに対応しているかという証明になっているということだ。Esperのコミュニティとユーザベースはその関係性を大変誇りに感じているようだ。

この市場の拡大と競合し合う実装の存在で標準化がいくつかの利点をもたらすことになる。ThomasはCEP言語の標準化の背景と可能性に関して説明した。

CEPコミュニティは明らかにCEPとESPを無償のものとみなしていて、また他のアプローチ（例：baynesianかneural networks）がCEP問題に適応するということを認識している。たくさんのアプローチとベンダ達の不賛成を踏まえて、最も関連性のある基準は”行シーケンス内のパターンマッチ”を提供するためのSQLを拡張するANSI SQL標準化委員会から誕生するように見える。

先ほど述べたトピックと標準化に関する努力が成されることは確かで、それはESP/CEP言語の標準化を超えることになるだろう。

多分Esperに関する一番重要なニュースは8月中旬に行われたパフォーマンスベンチマークキットと結果の発行(source)であるだろう。

Esperはシステムに登録された1000のステートメントを伴うVWAPベンチマークにおいて平均エンジンレイテンシータイム3マイクロ秒以下で、Intelベースの2GHzデュアルCPU上で500,000イベント/秒を超える。（99%の確実性で10マイクロ秒以下で）これは85%のCPU使用率で1秒に70マイクロビットを超える。

シンプルな使用ケースに基づいているのに関わらずベンチマークを再生するコンプリートキットと一緒に発売されるので、このベンチマークの公開はこの業界を揺るがせることを狙いとしている。Esperのイベントサーバはネットワーク上でマーケットストックイベントを送るリモートクライアントを監視している。またEsperエンジンは時間のスライディングウィンドウかイベントにおいてリアルタイムでフィードの出来高加重動作平均値を換算するように設定されている。

ベンチマークのような需要について聞かれ、Esperは下記のように答えた。

CEP市場にはベンダ達がその詳細を全く提供せずにプレスに数字を公表するので、パフォーマンスとレイテンシに関する曖昧な情報がありふれていた。この領域にはその比較となるベンチマークは未だ存在しない。

業界のこの曖昧なパフォーマンスに関する情報はProgress Apama(source)等(source)から既に批判を受けていた。以下はApamaのブログの一部である。

*Skylerは 200,000/秒と同等の率で動作する。
*キーとなる機能：Coral 8は1秒につき数千から数百万のイベントに対応する。
*StreamBaseはゼロに近いレイテンシと共に一秒100万以上のイベントを処理することによってパフォーマンスリーダーシップを拡張する。
*Aleri Labsはサブミリセカンドレイテンシーバリアを破壊する。

Apamaそれ自体は”一秒間に数千のイベントを処理する高パフォーマンスのスケーラブルプロセッシングエンジンである”と主張している(source)。そのような主張は他のものよりは劣るが、より正確な数字を提示してあるWebLogic Event Serverのリリース(source)に関するBEAの文言にもみうけられる。”私たちが発表するときには、一秒に50,000のコンプレックスイベントを提供しましょう。”

このような結果は一秒間における数百、数千のイベントがこの領域において一般的であり、またEsperがこの与えられたシナリオ(source)の中でどのように実行するかを確実にしているよう見える。またそれは混乱を起こさせがちだが、手ごろなオープンソースソフトウェアに投げられたベンダーのFUDに耳を傾けるよりも、ユーザのコミュニティにより良いパフォーマンスアクセスを可能にする重要な素材を提供する。

Esperチームはそのwiki上にてその実行の詳細を公開していて、またその製品のパフォーマンスセクション(サイト・英語)とパフォーマンスの最良実践の部分を更新している。もう一つのベンチマークソースは新たに形成されたSTACベンチマーク協議会(サイト・英語)から発足する可能性がある。
またそれはテクノロジトレードの顧客主導のベンチマーク基準の発足に狙いを定めている。

EsperとCEPの背景に関する情報は下記のURLにて参照して欲しい。
 http://infoq.com/jp/esper.


原文はこちらです：http://www.infoq.com/news/2007/10/esper

• 次へ >