Hazelcastがオープンソースのストリーム処理エンジンJetをリリース

Hazelcastはオープンソースのインメモリ・データグリッドで主に知られている(一般的にはHazelnuts IMDG，あるいは単にHazelcastと呼ばれる)。しかしながらこの２年間は，オープンソースの新プロジェクトであるHazelcast Jetを中心的に開発を進めてきた。そして今週，この新しいテクノロジのリリースが発表されたのだ。

InfoQは同社CEOのGreg Luck氏，そしてJet CoreチームのエンジニアであるMarko Topolnik氏とコンタクトを取り，今回の新リリースのエキサイティングな点について詳しく聞くことにした。

InfoQ: Jetはストリームベース処理の世界で非常に意義のある改善である，と述べられていますが，その理由について説明して頂けますか？

Luck: Jetの本当の目的は，アプリケーションのインフラストラクチャとは離れた部分で，高速大容量データを可能にすることにあります。SparkやHadoopといったテクノロジには，アプリケーション開発者のアーキテクチャや考え方に深く踏み込み過ぎている感があります。私たちはJetを，アプリケーション構造ではなく，開発者が自身の問題に集中するためのツールとして提供したいのです。

Jetはパフォーマンスの面でも画期的です。Jetと他のエンジン – どちらも物理的ディスクと10ノードのクラスタを備えたもの – を比較したパフォーマンス値を測定しました。その数字がすべてを物語っています。

InfoQ: Jetの開発の過程で行われたアーキテクチャ的，あるいは技術的判断について話して頂けますか？このマーケットにすでに存在するプレイヤー，特にApache Sparkと比較した場合，どのような違いがあるのでしょう？

Topolnik: Jetのコア実行エンジンのモデルには，協調マルチスレッディング(cooperative multithreading)，一般に“グリーンスレッド”と呼ばれる原則に基づくものを採用しました。これは，タスクのスケジュールをOSに任せず，利用可能なCPUコアと同数のスレッドですべての処理を行なう，という方法です。私たちがタスクレットと呼んでいる基本的な処理ユニットが，コールの度に少し処理をしては戻るという方法で，実行エンジンと協調的に動作します。有界並列キュー(bounded concurrent queue)で小さなバッチを実行することで，この処理パターンを自然に実現することが可能です – タスクレットの各コールが，キューに登録されているデータを処理するのです。

これがなぜ，よいアプローチと考えられるのでしょう？まず挙げられるのは，コンテキストスイッチのコストがほぼゼロである点です。ひとつのタスクレットから別のタスクレットに処理を引き継ぐロジックは，ほとんど必要ありません。次に挙げられるのは，CPUコアとの親和性です – タスクレットがスレッド間をジャンプすることはありませんし，各ワーカスレッドがコアに固定される可能性が極めて高くなります。これによってCPUキャッシュのヒット率が高くなります。そして最後に，インプット/アウトプットキューを調べることで，どのタスクレットが実行可能かを即座に把握することができるのです。ネイティブスレッドを使うと，比較的ヘビーウェイトな待機/通知メカニズムを備えたブロックキューが必要になります。そうなればすなわち，タスクの実行はOS次第ということになってしまうでしょう。

ふたつめの重要な決定は，単一プロデューサ/単一コンシューマのコンカレントキューをすべての場所で使用する，ということです。N個の上流タスクレットとM個の下流タスクレットを接続するにはN×Mのキューが必要ですが，こうすることで非常に高速でウェイトフリーなアルゴリズムが，キューの両端で実現できるのです。CPUのストアバッファ上にあるアイテムをエンキューするlaseSetを使用しているので，揮発性書き込み(volatile writes)の必要もありません。コンシューマ側で必要なのは，キュー全体がスレッドローカルストレージに出力された後，たった一度のlazySetだけなのです。

Luck: これらのアイデアはもちろん，Martin Thompson氏や，彼が提案したメカニカルシンパシ(Mechanical Sympathy)の運動から直接的な影響を受けています。

InfoQ: Hazelcast IMDGにはすでに，かなりクリーンで分かりやすいパーティショニングのアプローチがありますが，Jetではそれをどのように改善しているのでしょう？“特定のデータパーティションにRunnableを送信する”というもの以外に，どのようなユースケースが大きく改善されるのですか？

Topolnik: パーティションにRunnableを送信するというのは，単一のDAG頂点における動作に似ています。Jetのメリットは，頂点で読み込んだデータを変換し，別のパーティションに属するアイテムを生成することで，それらを下流の頂点に送信する際に並べ換えて，再び正しくパーティショニングできるという点です。この動作は，同一キーを持つすべてのデータ項目を監視してユニット数を減らす必要があるという点で，あらゆる種類のMapReduce操作において不可欠なものです。ネットワークトラフィックを最小限に抑えるため，Jetでは，ローカルメンバ上で生成されるデータスライスを減らした上で，部分的な処理結果の合成を行なうリモートメンバに対して，キー毎にひとつの項目のみを送信しています。

Luck: 当社は分散バージョンのjava.util.streamも所有しています。このソースとスキンはJertアーキテクチャの核心的な部分として使用されており，Jetのアーキテクチャで優れた処理を行なっています。将来のバージョンではソースとしてMap-with-Predicateも追加して，Jetのデータソースとして機能できるように，フィルタリングとフィールドプロジェクションを可能にしたいと思っています。

InfoQ: Jetが特に影響を与えられる，あるいは成功を収められると期待できるような，特定の産業あるいはユースケースはありますか？

Luck: IoTや金融サービス，支払処理，不正監査など，CEP(Complex Event Processing)を多用する産業では大きなメリットがあると思います。Jetに関して重要なのは，分析の一部としてよりも，運用状況においてDAG計算が必要な場合の有用性にあると思っています。

InfoQ: JetでもIMDGと同じような形式の製品戦略を行なうのでしょうか？OSS版と，サポートとプレミアム機能を備えた有料版を提供するのですか？

Luck: 必ずしもそうではありません。今日(2月8日)からIMDGと同じように，Jetでもプロフェッショナルサポートの提供を開始します。JetはIMSGと特に親和性が高いので，JetのローンチでIMDGの利用が増加すると期待してはいますが，Jetにはクローズドソースの部分はありませんし，その方向に進むつもりもありません。年内に管理監視の機能を有償で追加するかも知れません。そういった方法を行なうことは事実ですが，まだ何も決めていないのです。

現時点では，Jetの収益化には重点を置いていません – それよりも，Apache 2ライセンスのオープンソースプロジェクトとして成功を収めたいと思っています。

InfoQ: Jetのロードマップはどうなっていますか？

Luck: 今回0.3を公開しましたが，今後は毎月１回を目標にしています。

また，0.3でリリースを逃したものを整理して，２週間後に0.3.1を提供する予定です。具体的にはIMDG 3.8を提供し，さらにJetクラスタのエラスティックスケーリング(ジョブを実行中でも可能な)も取り上げます。

0.4リリースには，パフォーマンス関連の開発が多く含まれるはずです。現在でもJetのパフォーマンスは傑出していますが，0.4ではさらに向上するつもりです。真のストリームソースとして，JCacheのサポートとIMDGリスナも追加する予定です。IMDGは現行のリリースでもサポートされていますが，バッチソースとして，本当の意味でのストリーミングサポートも加えたいと思っているのです。

KafkaとHDFSはすでにサポートされていますが，それらをファーストクラスのサポート状態にするために，パフォーマンスの向上とドキュメント追加を行なう必要があります。

その他の機能としては，DAG可視化ツールを，EclipseとIntelliJのプラグインとしてリリースしたいと思っています。

Jetをコミュニティの前に出して，彼らの意見を聞きたいと思っています – それが実現できれば，ロードマップを真にコミュニティ主体のものにできるでしょう。