夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想=『夢』と、潰えた夢=『ガラクタ』の集積場です。

Twitter Heronの論文でのStormの問題とHeronの利点は?(サマリ

こんにちは。

前回TwitterBlogのHeronの記事を読み込んでみたので、
次は論文を読むか、とはりきってみた所、有料だったので撃沈した今日この頃です。
この後開発が進んでいくことを考えると今買って読んでしまうか悩みますね・・

と思っていた所、下記のPaperを読んだ結果のサマリが投稿されているサイトが見つかったので、
実際論文読むかの参考という意味でも読んでみます。

blog.acolyer.org

ただ、そのまま挙げているわけではなく、Nathanさんのブログの記事云々とか等、
一部省略している所もあります。

1. Twitterでは既にStormを使用していない。

Twitterでは既にStormは使用しておらず、Heronがストリーム処理の基本となっている。
ここ数カ月で既に数百のTopologyを複数のデータセンターで運用している。
=====
このあたりは、さすがStormとAPI互換を保った成果が出ている、という感じですね。
=====

何十TBのデータを処理し、何十億の出力を行っているが、
スループット、レイテンシの大幅が改善がされた上で、CPUリソースの利用率は削減できている。

Heronを開発するにあたってStormを改造して使用するか、の検討も行われたが、
Stormの限界も下記のように明らかになり、打開するにはコア部分から作り直す必要があった。

  1. Taskのスケジューリングが複数のメカニズムによって成り立っており、複雑かつ予測しにくい。
  2. 各WorkerプロセスはTaskを複数個、複数種類保持しており、各Task毎のパフォーマンスやリソース使用量を切り分けることが困難。
  3. ログファイルに各Taskのログが混在して出力されるため、特定のTaskのエラーを追う際に他のTaskのログに埋もれて追いにくい。
  4. 1Taskで例外がハンドリングされなかった場合、Workerプロセスごと死んでしまう。
  5. 各Workerプロセスは全て均質なものとして扱っているため、存在するリソースに応じた最適化が困難で、しばしばリソース超過が発生する。
  6. Workerプロセスに多くのメモリが割り当てられているため、プロファイリングツールを使うのが困難。実際使った場合、HeartBeatが停止することでSupervisorによってWorkerプロセスが殺されてプロファイル結果を取得できないケースが多々ある。
  7. 上記の事情を受けて仮にStormでWorkerプロセスが1Taskを実行するように再設計した場合、リソースの非効率や並列度の確保の困難が発生する。
  8. 各Tupleがプロセス内の処理を完了するためには4スレッドを通過しなければならず、オーバーヘッドや競合の問題を発生させる。
  9. Nimbusが機能的に過負荷に陥りやすく、運用における大きなボトルネックとなる。
  10. あるマシン上で複数の異なるTopologyに所属するWorkerプロセスが動作しており、個々のTopologyのリソース解析を困難にする上に、互いにリソースの干渉を発生させていた。Twitterではその問題に対処するために1マシンには1Topologyのみがデプロイされるようにしていたが、これは当然非常に効率が悪い。
  11. Nimbusが単一障害点となっている。Nimbusがダウンすると新たなTopologyのデプロイや既存Topologyの終了が出来ず、障害が発生したTopologyの検出、復旧も出来なくなる。
  12. BackPressureの機構を保持していない。結果、Ack無効時にSpoutから取得するTupleの数を制御できずに溢れるケースが発生する。結果上流コンポーネントの処理が不明確な状態になったり、無効になってしまうことがあった。
  13. Tupleツリーの末端で障害が発生した場合であってもTupleツリー全てが失敗として扱われてしまう。
  14. 大容量メモリを確保したWorkerプロセスでGCが発生した場合、分単位の時間がかかることもある。(結果、HeartBeatが失われてkillされる。)
  15. 通信用のキューにおいて競合がしばしば発生する。特に、Workerプロセス中で複数のExecutorが動作している場合はより顕著に表れる。
  16. これまで述べたパフォーマンスが予測しにくく、問題が発生することに対して、Twitterは多くの場合余剰のリソースを割り振って対処していた。あるTopologyでは600コアを平均20~30%使用する、という効率が悪い状態になっていた。Stormの性能上の課題が無ければ、本来150コア程で運用できていたはず。

これらのニーズへの対応のため、Twitterは高性能/スケーラブルで共有のインフラ上で動作するストリーム処理基盤を求めていた。
=====
いや、いい感じにボコボコにされてますね(汗)。Storm。
まぁ、大部分はその通りなんですが、WorkerプロセスでGCに分単位の時間がかかるようなメモリ量を割り振る等、明らかにこれ最初の前提がおかしいだろ、というのもあるのでちと微妙な感じですね。
=====

2. Heron入門

Heronはコンテナベースの実装となっている。
Heron TopologyはMesos上のAurora Scheduler(Apache Aurora)で動作しているが、YARNやAmazon ECS上でも同様にデプロイすることが出来た。

Auroraのような外部のスケジューラを使用するようにしたのはStormでNimbusがスケジューリングを行っていた状況からの脱却のため。
Twitterの内製スケジューラのAuroraやその他のオープンソースのスケジューラ(YARN等)が洗練されてきているため、自前でスケジューラを作るのではなく、これらを利用して自分達は別のものを開発した方が有効だと判断した。

Heronでは1コンテナ上で下記のように複数のプロセスが起動している。
f:id:kimutansk:20150705221358p:plain

1コンテナ目はTopology Masterと呼ばれるプロセスを起動する。
残りのコンテナは各自がデータのルーティングを行うStreamManager、メトリクスの収集/レポートを行うMetricsManagerといくつかのHeron instance(Spout/Bolt等ユーザロジックを実行)を起動する。
複数のコンテナが1物理ホスト上に割り振られる。これらはAuroraベースのスケジューラで配分され、クラスタのリソースをより有効活用できる配置となる。(Twitterにおいて、AuroraはコンテナをLinux cgroupsで実現)
Topology Masterは待機系のプロセスも起動可能になっており、これによって耐障害性を高めている。
Topologyのメタデータ(起動ユーザ、稼働時刻、プロセス配置等)はZookeeperに保存される。

Stream ManagerはTupleのルーティングを担当する。
あるTopologyに所属するStreamManagerは相互に接続しており、 O(k2)の接続を確立している。(K=Stream Managerプロセス数=コンテナ数)
コンテナ中のHeron Instanceは同一コンテナのStream Managerと接続している。Heron Instance(n個)はStream Manager(k個)よりも数は多い。
そのため、O(n2)の論理的な接続がO(k2)の物理的な接続の上に多重化されて乗っている形になる。

HeronはBackPressureの機構を保持している。Stream Managerが同一コンテナ上に存在するSpoutのデータ取得量を制御することによって実現している。
BackPressureはバッファサイズが最高水準(High Water Mark)に達した時点で発動し、バッファサイズが最低水準(Low Water Mark)になるまで継続する。
この設計とした理由としては、BackPressureの緩和に伴う極端なデータ出力/入力から来る急速なブレからTopologyを守るためとなっている。

Heron InstanceはSpout/Boltの処理を担当する。
各Instanceが1JVMプロセスとなっており、各Heron InstanceはGatewayスレッドとExecutionスレッドの2スレッドを保持している。
GatewayスレッドはHeron Instanceの全データ入出力を担当している。
GatewayスレッドがStream ManagerやMetrics ManagerとのTCP接続を維持し、Stream Managerから受信したTupleをExecutorに渡し、結果を受け取ってStream Managerに送信する役割を持っている。

=====
コンテナと形で区切られてはいるものの、JVMプロセスの数自体はStorm時代と比べてかなり多くなっているようです。
ただ、1プロセス1Taskとなっているのでどこに問題があるか、等もわかりやすくはなるとは思いますが・・・ 実際にリソース効率はどういいんでしょうかね。

=====

3. HeronがStormより優れている点は?

これらの構造を基に組み上げられたHeronがStormより優れている点としては、下記が挙げられる。

  1. リソースのプロビジョニングはクラスタマネージャのレイヤで抽象化され、共有インフラを有効に活用することができる。
  2. 各Heron Instanceが1Taskしか実行しないため、デバッグが容易になった。
  3. メトリクス収集の単位がSpout/Boltと合致したことによって、システム内で発生した障害や性能問題に対して透過的に扱い、解析をすることが可能になった。
  4. HeronはTopologyの1Task単位で必要なリソースを指定可能となっているため、OverProvisioningが発生しない。
  5. 各TopologyのTopologyMasterが独立したことで、特定のTopologyの障害が他のTopologyに対して一切波及しなくなった。
  6. BackPressureの機構により、一定の処理速度と、性能の予測が立てられるようになった。また、BackPressureはTopologyのコンテナ群を別のコンテナ群にマイグレーションする際のキー技術にもなっている。
  7. 単一障害点が無くなった。

論文中においても、どの指標においてもHeronはStormを上回っていた。


・・・というわけで、記事を読んでみました。

こっそりBackPressureがコンテナのマイグレーションにもつながっていることが書かれていますね。
動作中の更新などもより動的に行えるようになるのかもしれません。
単に性能的な面だけでなく、そういった扱いやすさの面でも改善はされてそうですので、楽しみですね。