Twitterがストリーム処理エンジンHeronをオープンソース化

Twitterは，Heronのオープンソース化をアナウンスした。 Heronは，ストリーム処理エンジンであり，Apache Stormの後継にあたる。 HeronはApache Stormに対して後方互換性をもつため，開発者にとって参加しやすくなっている。 Twitterは，ストリーム処理エンジンをApache StormからHeronに置き換えた。 スケーラビリティ，デバッグ容易性，共有クラスタ基盤上で機能および性能の点において，Heronは優秀である。 全体的な機能の一覧は，公式ドキュメントを参照のこと。

InfoQはKarthik Ramasamy氏(Twitter社の技術マネージャかつ本プロジェクトの共同開発者)に対し，今回の発表についての取材を行った。

InfoQ: Apache Stormの話から始めましょう。Apache Stormにはどのような技術的限界があったのでしょうか?なぜ，オリジナルプロジェクトを拡張する代わりに新しいプロジェクトを始めることになったのでしょう?

Ramasamy氏: Twitterにおいて，私たちが扱う規模のApache Stormシステムは，徐々に制御が難しくなってきていました。 課題はスケーラビリティ，デバッグ容易性，管理容易性，および他のデータサービスとの間の高効率なリソース共有やクラスタリング化でした。

Stormでは，トポロジの複数コンポーネントからの処理は，OSの一つのプロセスにまとめられます。 これがデバッグを非常に難しくします。 加えて，Stormは専用のクラスタ資源を必要とします。 ですので，Stormトポロジを実行するために，特別なハードウェア配置をしなければならないことになります。 このアプローチでは，貴重なクラスタ資源の利用効率が低下しますし，状況に応じたスケーリングも難しくなります。

Stormを使用すると，新規本番トポロジのプロビジョニング時にはマシンを手作業で隔離する必要があります。 逆に，トポロジが要らなくなった場合，トポロジに割り当てていたマシンは割り当て解除しなければなりません。 マシンのプロビジョニングをこんな風に管理するのはとても面倒です。

最終的に私たちは，先ほど挙げた目標を全部実現したいと願うようになりました。 ただし，Stormを使ってすでに開発していたたくさんのアプリケーションを書きなおさなくてよい方法にしたかったのです。

いくつもの試行錯誤の上，私たちは，先ほど挙げた目標を達成するには，新しいストリーム処理システムを設計する必要がある，という結論に達しました。 この新しいシステムというのが，Heronです。 HeronはStormとAPIレベルで互換性があります。 これにより，既存のStormユーザはHeronに移行することが簡単にできます。 また，新しくHeronを使って開発をするユーザにとってもメリットとなります。 Twitter内のすべての本番トポロジは，Heron上で動作しています。 Stormと比較して劇的な性能向上と省資源化に成功しただけでなく，Heronはデバッグ容易性，スケーラビリティ，そして管理容易性に対しても大きな優位性を持っています。

InfoQ: Apache内だけでもたくさんのストリーミング・フレームワークがあります。 Heronがこれらのプロジェクトと違うところはどのような点でしょう?

Ramasamy氏: 私たちはHeronの設計指針をSIGMODの論文Twitter Heron: Stream Processing at Scale (2015年5月)にて概説しています。 TwitterはStormトポロジ開発に多額の投資を行いました。 他の大規模な管理をしている，あるいは管理しようという意欲のある会社も投資しています。 実際のところ，Stormは私たちの要求に応えるほどスケールしませんでした。 そして他のソリューションが，現れたのです。 それらは未熟で，未完成の箇所があったので，既存のトポロジをリエンジニアリングするにはコストがかかるものでした。

現在の状況は，私たちが当初予測した通りです。 世界的にリアルタイムの波が来ています。 成長を続けるためには極めて低レイテンシなリアルタイム分析が必要です。 Heronは急速に成長するリアルタイム業務分野に適用されるでしょう。 異常検知，IoT/IoEアプリケーション，組み込みシステム，VR/AR，広告入札，金融，セキュリティ，そしてソーシャルメディアといった分野です。

現時点で不透明なものは，スケールに対する信頼性です。 Stormは最初のソリューションでした。 Heronは，そのアップグレード版です。 障害レポートを10分の1に減少させ，効率も向上しました。 現行システムは，スケールすることにより，問題を起こす可能性があります。 しかし，Twitterは，他社事例のない独特の要求を持っているため，結果はわかりません。 私たちはこのエコシステムの成長と，オープンソース界で引き続きリーダとなっていけるかにとても注目しています。

InfoQ: あなたはブログの中で「Heronはストリーミング・アーキテクチャとして根本的に違う」と書いています。これはどういうことでしょうか?

Ramasamy氏: ストリーミング・アーキテクチャとして根本的に違う，というのは，Stormでのスレッド・ベースに対するHeronでのプロセス・ベースのアーキテクチャのことです。 ユーザは，トポロジがどのように機能しているのかの推測が簡単にできるようになりますし，コンポーネントのプロファイル/デバッグも独立して行えます。 この根本的な変更には，Stormの完全書き換えが必要でした。 しかし，Heronトポロジでは開発もデバッグも容易になったのです。 私たちの感覚では，開発に投資した分はすでに回収したと思っています。 障害レポートは10分の1に減りました。 HeronがTwitter規模で“使える”ということが示せました。

InfoQ: Twitterは，Heronにとって最大のコントリビュータなのですか? 他にはどのような会社がコントリビュートしているのですか?

Ramasamy氏: プラットフォームをオープンソース化するまでは，確かにTwitterがHeron開発をリードしていました。 しかし驚くべきことに，沢山の企業がHeron開発を支援してくれています。 HeronはTwitter規模での動作が確認できています。 これはストリーミング・フレームワークとしては唯一のものでしょう。 他社は私たちの設計を拡張し，先々のシステム改善に向けて実装を進めてくれます。 特に，私たちの初期リリース時に示しましたが，Microsoftはキー・コントリビュータとしてHeronをApache REEFによるYARN上で動作するようにしてくれました。 将来的な計算効率向上のため高度なパッケージング・アルゴリズムも実現されました。 私たちにはすでに50を超えるコントリビュータがおり，プル・リクエストの数は900を超えます。 私たちはさらに協力者が増えると期待しています。

私たちはさらに，きわめて多数の中国企業がHeronのベンチマークを実施していることに驚いています。 またTwitter以外では最大規模と思われる大規模なクラスタにHeronを適用しています。 私たちは顕密に連携しており，他にもアナウンスできればと考えている会社があります。

私たちは，オープンソース・コミュニティにコミットしています。 Heronに先立ち私たちはApache Stormを提供しました。 これは2011年にオープンソース化しました。 さらにクラスタマネージャApache Mesos，MapReduce ストリーミング・フレームワークSummingbirdさらに最近ではハイパフォーマンス・レプリケートDistributedLogがあります。 私たちは，Heronをオープンソース化を想定して開発しました。 最初にSIGMODで論文を発表して以来，私たちはよく，Heronのオープンソース化に対する質問を受けていました。 特に，リアルタイム要求が厳しい処理を扱う他社の方々や，私たちが提供しているシステムでの経験と似た問題を抱えている方々から質問が来ました。 興味を持ってもらえるのはありがたいことでした。そして今，協力していただけるのはありがたいことです。

InfoQ: Apache Stormとの後方互換性は，開発者がHeronに協力する上での鍵になっていると思われます。 これは将来のバージョンでも保障されるのでしょうか? 開発者の観点から見ての注意や，実装者の観点から見ての挑戦課題などあれば，教えてください。

Ramasamy氏:重要な点として，Twitterでのユースケースはそのままサポートされます。 後方互換性は，私たちのStorm利用に合わせたものです。 しかし，Apache Stormは新たなユースケースを含んでいます。 その中には私たちが必要としないものがあり，これはサポートすることもありません。 主にDistributed Remote Procedure Calls (DRPC)などです。 今，Heronはオープンソース化されました。 私たちはさらなる機能のサポートに対して熱心な協力者を探しています。 そういった中で，将来にわたってApache Stormに対するサポートが継続することを期待しています。 これはエコシステムとしても利益があると考えています。 可能な限り互換性を保ち，文法レベルでのサポートもできればよいと考えています。

InfoQ: Heronのロードマップを教えていただけますか?

Ramasamy氏:ロードマップの主要なものは，主なスケジューラの効率的なサポート，Apache Auroraのサポートです。 REEFによるYARNのサポートはすでに受け付けました。 SLURM，そして安定してはいますが以前として実験的なApache Mesosのサポート。 私たちは，DC/OS，Marathon，そしてKubernetesの実装レベルのサポートが開発段階に入っていると考えています。 私たちはシンプルなインストールと信頼性のあるオペレーションを目指しています。 さらに，私たちは，Heronの能力を拡張し，ホット・デプロイ，大きなイベント発生中の手動トポロジスケーリング，そして自動トポロジスケーリングができるようにしたいと考えています。 また，私たちはストリーム処理に関するいくつかの革命的なアルゴリズム開発の仕事をしています。 特に脱落が発生したときやネットワークが分断されたときのアルゴリズムです。

Heronは今後もTwitterのユースケースにフォーカスしていきます。しかし，製品にてテストされた機能は追加されていきます。 もしあなたが，特定の機能に対する協力に興味があったり，既存のマイルストーンを援助してくれるなら，Heronコミュニティに参加してください。heronstreaming開発者Slackチャネルもあります。 私たちはHeronコミュニティの成長を願っています。

Heronバイナリのダウンロードやトポロジ構成例の詳細はgetting started guideを参照のこと。