Twitter HeronはStormに比べてどう進化しているのか？
こんにちは。
今月頭、TwitterがHeronという新しいリアルタイム解析基盤について発表していました。
読んでみると、StormとAPIの互換性を保ったまま新しいHeronというリアルタイム解析基盤を開発したそうな。blog.twitter.com
ですので、一度Heronの記事を読んでまとめて、Stormと比較しておこうと思います。
StormもOSS化されて4年近く経過し、ストリーム処理プロダクトも世代交代の時期に来ているようですので、その意味でのまとめとしても。
その前に、そもそもStormって？
2011年にTwitterがOSS化した耐障害性を持つ分散ストリーム処理基盤です。
どういうものかは下記あたりの資料を読むのが私が何か下手に書くよりわかりやすいと思います＾＾；
初めて広く広まったストリーム処理基盤のOSSで、その分野の走りだったのではないか、と考えています。
www.slideshare.net
www.slideshare.net
Stormの課題は？
StormがOSS化されたのは2011年のため、様々な所で使用され、問題も多く発生してきました。
いくつかの発表（下記）や、私自身が使った感覚からすると、下記のような問題があります。
www.slideshare.net
1. 上流のコンポーネントの処理性能の方が下流より高い場合、溢れる。
StormにおいてSpout/Boltは完全に非同期で、かつ常時全速で動作し続けます。
結果、上流に存在するSpoutの方が処理性能が高かった場合、その差分がどんどんプロセスの中に溜まり続け、結果溢れてプロセスが飛ぶ・・ということが発生します。
ですので、上流のコンポーネントより下流のコンポーネントの方が処理量が多くなるようにチューニングする必要がありました。
2. メッセージの基本配分方式がラウンドロビンのため、効率が悪い。
Stormにおいて、メッセージの基本配分パターンは下流のコンポーネントに対してラウンドロビンで配分する、というものです。
これは一見上手く分散するように見えて、プロセス間通信によるロスを考慮していないため、効率が悪い。
グルーピング定義の調整とコンポーネントのスレッドの数のチューニングでプロセス間通信を削減することは可能ですが、逆に言うとそれだけ中身がわかっていないと性能は引き出しにくいわけですね。
3. 状態管理等に負荷が集中する個所があり、スケーラビリティに課題がある。
Stormは処理の統計情報や生存情報をZooKeeperに保存します。
ですが、その頻度と量が多いため、クラスタの規模が大きくなった場合にZooKeeperをあふれさせるということが良くあります。
また、起動時にNimbusという管理サーバからアプリケーションを取得するのですが、アプリケーションのファイルサイズやクラスタの規模によってはその取得に時間がかかり、アプリケーションの起動に時間がかかったり、タイムアウトすることがあります。
＃特に、Stormクラスタ上で依存性の問題を除去するためにアプリケーションをFatJarにしておくと発生しやすい。
4. デバッグが大変
これは分散システムだったら何でもそうだろ、といえば実際そうなのですが、Stormでも大変でした。
ログが複数のサーバに配分されている上に、StormはWorkerプロセスが死んだ場合に自動で復旧させるので、問題があるようなんだけどプロセスは問題なく動いているように見える・・・という状況が多々ありました。
一応、Workerプロセスにリモートデバッグをかけるという力技もやってやれないことはないのですが、それでも厄介なことには変わりありません。
・・尚、ここまで一切Heronの記事については考慮せずに書いています。
ですので、リアルなStormの課題を書くことができたかと。
で、ようやくこれからがTwitter Heronです。
Twitter Heronとは？
意義とアプローチ
ストリーム処理基盤は大容量のデータを常時解析するのに有用で、下記のような性質が求められる。
- 数十億件／分のイベントを処理できること
- 秒未満のレイテンシと、スケール時に挙動が予測できる構成
- 障害発生時にハンドリングが容易
- スパイク発生や特定個所で詰まった場合に耐えられること
- デバッグが容易
- シンプルなデプロイ方式
上記のような性質を満たすシステムを構築するために、TwitterではStormの拡張や他OSSの利用も含めて検討を行ったが、結論としては新たな基盤の開発を採用した。
理由としては、Twitterで求めていた上記のような要求に対して、Stormのコア部分が追随できなくなっていたことと、他OSSもスケーラビリティ／スループット／レイテンシの面で見合わなかったため。
だが、StormのAPIと互換性を保てない基盤を開発してしまうと、既に開発済みのTopologyもマイグレーションが必要になり、そもそもモデルも大きく変更されてしまう。
そのため、TwitterではStormのAPIと互換性を保った新たなストリーム基盤を開発する方針となった。
＝＝＝＝＝
Stormのコア部分が要求に追従しきれなくなった、はわかりますが、Twitterであっても既存のTopologyの移行には課題が大きいというのが意外でした。
Heronの概要
Heronを開発するにあたって、Twitterでの目標は下記だった。
- パフォーマンスの予測精度の向上
- 開発効率の向上
- 管理の容易性
Heronのアーキテクチャは下図の通りとなる。
ユーザはTopologyを開発すると、StormのAPIを用いてSchedulerにSubmitを行う。
Schedulerは複数のContainerから構成されるプロセスとして各Topologyを実行する。
ContainerのうちいずれかはTopology ManagerとしてTopologyの管理を行う。
残りのContainerは各自がデータのルーティングを行うStreamManager、メトリクスの収集／レポートと「Heron instances」と呼ばれるSpout/Boltを実行するプロセッサの数を把握するMetricsManagerを実行する。
これらのContainerはクラスタ内のノードのリソース状況に応じてSchedulerによって配分される。
Topologyの物理配置状況や実行構成詳細といったメタデータはZooKeeper上で管理されている。
＝＝＝＝＝
メタデータ、という形でZooKeeperに保存する情報を絞ったように見えます。これでZooKeeper死亡、は起こりにくくなる・・？
＝＝＝＝＝
Heronで特筆すべき特徴としては下記がある。
リソースマネージャ非依存
Schedulerを抽象化することにより、アダプタを記述することでMesos、YARN、またはそれ以外の個別スケジューリングフレームワークの上で実行することが可能になっている。
スパイクや混雑への対応として、BackPressureの機能を保持
Heronではスパイクや特定のコンポーネントが詰まった場合への対応として、BackPressureの機能を保持している。
処理できる量のデータのみを上流コンポーネントに要求することで、変動に対応可能となっている。
＝＝＝＝＝
Reactive Streamsで出たBack Pressureですが、さらっと取り込まれているあたりはさすがではありますね。上流のコンポーネントが性能高くて溢れる、ということもこれで防げそうです。
＝＝＝＝＝
デバッグの容易性
各Task（Spout/Boltにマッピングされるもの？）は各プロセス内で全て動作し、1プロセス内で解析が可能となっている。
結果、動作の把握や性能の解析が容易になっている。
加えて、TopologyのUIで下図のようなメトリクスを見ることも可能になっている。
＝＝＝＝＝
プロセスに各Taskを全て保持することで、1プロセス内で処理が完結するルートを設けたということですね。
これはデバッグが容易になる他にもプロセス間通信を削減できるので性能向上に大きく寄与しそうです。
＝＝＝＝＝
Stormとの互換性
HeronはStormと完全な互換性を保っている。
そのため、Storm上で開発したTopologyをコード修正なしでHeron上に移行することが可能になっている。
スケーラビリティと低遅延
Heronは大規模なTopologyにおいて、高いスループットと低レイテンシを両立している。
それにより、システムはより大規模なTopologyを扱えるようになっている。
Heronの性能
Heronの性能を確認するために、2013年10月の時点のOSS版Stormを用いてWordCountTopologyを用いて比較を行った。
150万のWordをカウントし、Ackを有効化した状態で性能比較結果は下記のようになった。
- レイテンシ
スループットの図からわかる通り、StormもHeronも並列度の追加に応じてほぼ線形に性能が向上している。
だが、Heronの方が全検証パターンにおいて10～14倍のスループットを誇っていた。
同様に、レイテンシについてもHeronはStormの5～15分の1のレイテンシで処理を行うことが出来た。
＝＝＝＝＝
2013年10月ということはその時点だとStormの通信はデフォルトZeroMQで行われています。
2014年3月の時点でデフォルトがNettyに差し替えられて性能が跳ね上がっているのですが、それを入れ込んでいないのはちとずるい比較ですかね。
（Making Storm fly with Netty | Yahoo Engineering）
とはいえ、Nettyを適用し、その上でチューニングを行ったStormと比べても性能が高い、というのは確かでしょう。
ただ、倍率自体は後で記述されているハードの削減効果にある3倍位に見ておくのが無難なように思えます。
＝＝＝＝＝
