夢とガラクタの集積場

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

Twitterの新ストリーム処理基盤、Heronのアーキテクチャは?(詳細

こんにちは。

前回論文の前半部、Stormの問題点を読みましたが、
今回は中盤部、Twitter Heronのアーキテクチャについてです。
あと、後半部のStormとHeronの性能比較については下記のページでまとめているのの
事例が増えただけでしたので、とりあえず省略する方向で^^;kimutansk.hatenablog.com

では、前回の続きです。

5. Heron

5.1 Data Model and API

Heronの主要な設計目標はStormのAPI互換性を維持すること。
そのため、HeronのデータモデルはStormと同様のものとなる。
StormのようにHeronはTopologyを実行し、SpoutとBoltの有向非循環グラフとなる。
同様に、SpoutはTopology内に入力Tupleを生成or外部から取得し、Boltは実際の計算処理を行う。

Heron Topologyはデータベースシステム内の論理実行計画に相当する。
データベースシステムと同様に、この論理実行計画は実際に実行する前に物理実行計画に変換される。
Topologyの一部として、プログラマはタスク(Spout/Bolt)と、並列度、あとはTupleがタスク間をどう流れるかを示すグルーピングを指定する。
実際のTopology、各コンポーネントの並列度、グループ化の仕様からマシン上で実際に実行される物理実行計画は構成される。

HeronのTuple処理セマンティクスはStormのそれと下記のように似ている。

  • 1. At most once

全てのTupleは最大1回実行される。Topologyの状況次第では欠落することもあるが、複数回処理されないことは保証される。

  • 2. At least once

全てのTupleは最低1回実行される。Topologyの状況次第では複数回実行されることもあるが、少なくとも1回実行されることは保証される。

5.2 Architecture overview

Heronに対して求められる要素は、下記がある。

  • タスク管理の容易性向上
  • 開発者の開発生産性向上
  • 性能の予測可能性向上

そのため、我々はTwitterのスケール上でシステム内の異なるコンポーネントの綺麗な抽象化を行った上で、コンポーネント間の相互接続をしつつ動作させることが出来るアーキテクチャを構築する必要があった。

Heronの全体的なアーキテクチャは下図の通り。
f:id:kimutansk:20150715052542j:plain

ユーザはHeronのコマンドラインツールを利用してAuroraにTopology(Heron APIを利用して作成したSpout/Bolt群)をデプロイします。
AuroraはMesos上で実行される汎用的なサービススケジューラである。
だが、Heron Topologyは基本Auroraで動作するが、YARNやAmazon ECS上でも同様にデプロイすることが出来た。
この設計は、Nimbusがスケジューリングにも利用されていたという問題状況を脱するため。
Twitterの内製スケジューラのAuroraやその他のオープンソースのスケジューラ(YARN等)が洗練されてきているため、自前でスケジューラを作るのではなく、これらを利用して自分達は別のものを開発した方が有効だと判断した。

Heron Topologyは下図のようにいくつかのコンテナからなるAurora Jobとして構成される。
f:id:kimutansk:20150715052711j:plain

1コンテナはTopology Masterと呼ばれるプロセスを実行する。
残りのコンテナはStream Manager、Metrics Managerと、実際のSpout/Boltを実行するいくつかのHeron Instanceというプロセスから構成される。
複数のコンテナは単一の物理ホスト上で起動可能。
これらのコンテナはクラスタ内の各ノードの残リソース量にに応じてAuroraによってノードを跨いでスケジューリング/配置される。
TwitterではAuroraはリソース配分をLinux cgroupsを用いて行っている。)
また、Topology Masterの待機系も可用性向上のため利用することが出来る。
Topologyのメタデータ(起動ユーザ、稼働時刻、プロセス配置等)はZookeeperに保存される。

Heron InstanceはJavaで書かれたユーザコードを実行する必要があるため、Javaで記述されている。コンテナ内のHeron Instance毎にJVMが起動する形となる。
Heron Instanceは互いにprotocol buffers (protobufs)を用いて通信を行う。

5.3 Topology Master

Topology Master(TM)はTopology全体を管理するためのプロセス。
これはTopologyの状態を見るための単一のエンドポイントを提供するためであり、立ち位置としてはYARNのApplication Masterとよく似ている。
TMは起動時にZookeeper上にエフェメラルノードを作成し、外部からTMを検出可能としている。
エフェメラルノードを利用するのは下記2つの目的がある。

  1. あるTopologyに対して複数のTMが同時にMasterとなり、異なるViewを提供することを防止するため。
  2. TMに所属する他のプロセスがTMを検出可能とするため。

TMはTopologyのメトリクスを提供するエンドポイントとしても動作する。ただし、TMはデータ処理の経路上には存在しないため、そのことがボトルネックにはならないことを留意されたい。

5.4 Stream Manager

Stream Manager (SM)の主な機能は効率的にTupleのルーティングを行うことにある。
各Heron Instance(HI) は同一コンテナ上のSMに接続し、Tupleの送受信を行う。
Topology中の各SMは相互にコネクションをはり、{ \displaystyle O(k^2) }のコネクションから構成されるネットワークを構築し、通信を行う。
HIの数をnとすると、nはkより明確に大きくなる。SMが相互接続を行うことによって、{ \displaystyle O(k^2) }の物理コネクション上に{ \displaystyle O(n^2) }の論理コネクションを多重化して配置したオーバレイネットワークを構築したモデルになっている。
また、同一コンテナ中のHI同士の通信はローカルの短絡機構を用いてルーティングされる。

5.4.1 Topology Backpressure

Stormと異なり、Heronは動的にTopologyに流れるデータ流量を制御するBackPressure機構を有している。
この機構は異なるコンポーネントが異なる速度でデータ処理を行うTopologyにおいて重要な機構となる。
例えば、下流の実行状況が遅延したり、データのずれによって実行が遅れたケースにおいてデータパイプラインがどうなるかを考えて欲しい。
なお、このケースにおいては上流のコンポーネントの速度低下が問題になることはないとする。その場合、下流でデータを処理しきれなかった時点でバッファ上の長いキューを構成するか、Tupleを廃棄するほか無くなる。
Tupleが破棄されるということは、上流コンポーネントによる処理は行われているため、データの損失は勿論、パフォーマンス的な損失も大きい。
BackPressure機構は上記のような事情から、上流コンポーネントの速度を遅くするために必要とされる。

そのため、我々は実際にどういう方針で実装するかを下記のオプションから検討を行った。

  • TCP BackPressure

この方式では、HIから他の上流コンポーネントに対してBackPressureを伝播させるのにTCP Window機構を利用する。
HIとSM(同一コンテナ上)はTCPソケットを用いて接続するため、SMとデータを送受信する速度はHIの処理速度と等しくなる。
HIの速度が停止している場合は受信バッファが一杯になる。
SMはHI側の受信バッファの溢れを送信バッファの状態から検知し、他のSMと上流のHIに伝播させる。

この場合、速度が低下したHIがキャッチアップした場合のみ、BackPressure状態が解除されることになる。

この単純なTCP BackPressure機構は実装が容易となる。だが、この方式によるHI間のBackPressure機構はHI同士の論理コネクションがSM間の物理コネクション上にオーバーレイされているため、実際は上手くは動作しなかった。
多重化によって誤って違う上流HIの速度低下を招くだけでなく、異なる下流HIのストリームの速度低下も招いてしまった。結果、1か所の速度低下がTopology全体に大きく影響をあたえ、かつBackPressure状態の解除も非常に遅いものとなった。

  • Spout BackPressure

この方式ではSMがTopologyが外部から取得するデータ量を減少させるため、同一コンテナ上に存在するSpoutの速度を絞る。
この方式はSMとHIの間のTCP BackPressureを組み合わせて使用される。
SMは同一コンテナに所属するHIの処理速度が低下したのを検知した場合、ローカルに存在するSpoutを特定してデータの読み取りを停止する。
この方式はSMがローカルから受信するSpoutのバッファ(=Spoutの送信バッファ)を一杯になるため、Spoutからの受信メッセージを結果的にブロックする形になる。
影響を受けたSMはローカルに存在するSpoutを絞るための「BackPressure開始」メッセージを他SMに送信する。
他のSMはこのメッセージを受信すると、ローカルに存在するSpoutがTupleを読み込まないよう制御する。
速度が低下したHIの処理が追いついた場合、ローカルのSMは「BackPressure終了」のメッセージを他SMに送信し、他のSMはこのメッセージの受信に依ってローカルのSpoutからのデータ取得を再開する。
この方式は最上位のコンポーネントであるSpoutを直接ブロックする形になる。
この方式は必要以上にSpoutの処理速度を低下させる可能性があるため、最適ではないかもしれない。ただ、必要になったタイミングで即上流コンポーネントの処理速度を低下させることが出来るため、必要十分な機能でもある。
この方式の潜在的な欠点はBackPressure機構の開始終了を制御する特殊メッセージとなる。
しかし、この方式はTopologyの保持するSpout/Boltの数によってBackPressure機構の有効無効にかかる時間が変動しないという利点もある。

  • Stage-by-Stage Backpressure

Topologyは複数のステージからなる、とみなすことが出来る。
この方式では、Topologyにおいて、1段目を示すSpoutに達するまでBackPressureを1ステージ毎に伝播させる。
SpoutBackPressure方式と同様に、この方式はSMとローカルのHIのTCP BackPressure機構によって実現される。だが、SM間で利用されるBackPressureのメッセージの内容が異なってくる。

5.4.2 Implementation

Heronでは最終的に「Spout BackPressure」の方式を採用した。
この機構は実際に上手く機能した。また、Topologyのどこかが詰まった場合にそのイベントの発生元を確認することでBackPressureの発動の根本原因を突き止めることを容易にするデバッグ容易性も提供することが出来た。

全てのソケットチャネルはHighWaterMarkとLowWaterMarkによってサイズが制限されるアプリケーションレベルのバッファに紐づけられている。
バッファのサイズがHighWaterMarkに達した場合、LowWaterMarkを下回るまでBackPressureが有効化される。この設計を取った根拠としては、BackPressureの緩和に伴う極端なデータ出力/入力から来る急速なブレからTopologyを守るためとなっている。

この設計の結果、TupleがSpoutから送信された場合、Heronはプロセスまたはマシンの障害のシナリオの間を除き、それをDropしないということが確定される。そのため、Tupleの失敗をより確定的にすることが出来る。

TopologyがBackPressure状態になった場合、最も遅いコンポーネントにあわせてしばらく処理が行われることになる。
そのシチュエーションが継続した場合、Spoutが取得したデータが「Source」キューとして蓄積されることになる。Topologyの設定に応じて、Spoutは蓄積された古いデータを削除することも可能となる。

5.5 Heron Instance

Spout/BoltといったTopologyを構成するメインの処理はHeron Instance(HI)に切りだされて行われる。
StormのWorkerと違い、HIは単一のタスク(Spout/Bolt)を実行するJVMプロセスである。
このような設計にすることによって、各Spout/Boltのイベントやログのシーケンスを1タスク単位で見ることが出来るため、デバッグやプロファイリングが容易になる。
データ移動の複雑さはHIからSMに移譲されているため、HIを将来的に他の言語で開発することも可能になるだろう。
HIを実装するにあたり、「シングルスレッドモデル」「2スレッドモデル」のオプションを検討した。以後にその経過を記述する。

5.5.1 Single-threaded approach

シングルスレッドの設計においては、メインスレッドがローカルSMへの接続を維持し、Tupleを待つ。
Tupleが到着するとユーザロジックコードがメインスレッドによって呼び出される。
ユーザロジックコードが出力Tupleを生成する場合はバッファリングされている。
バッファが特定の閾値を超えるとローカルSMに通知される。
この方式はシンプルであるという利点を持つが、下記のようにユーザロジックコードがメインの処理を阻害する可能性があるという潜在的リスクも有する。

  • スリープシステムコールの呼び出し
  • ファイルやネットワークとの入出力待ち
  • スレッド同期待ち

我々はこの方式でまず実装を行い、上記のようなブロッキングはメトリクスの報告等必要な定期処理のために望ましくないものであることに気付いた。
ブロッキングの持続時間が変わる可能性もあるため、予期しない動作にもつながってしまう。
メトリクスが定期的に収集できなかった場合、収集元は確実にHIが「悪い」状態であるか否かを判断、トラブルシューティングを行うことができなくなる。

5.5.2 Two-threaded approach

下図に示すように、この設計方式ではHIはGatewayスレッドとタスク実行スレッドの2つのスレッドを保持している。
f:id:kimutansk:20150716052408j:plain
GatewayスレッドはHIと外部との全ての通信とデータの移動を制御することを受け持っている。同様に、ローカルSMとメトリクスマネージャへのTCP接続も維持している。
加えて、ローカルSMから送信されたTupleを受信する責任も持つ。これらの受信Tupleはタスク実行スレッドに送信され、実際の処理が行われる。

タスク実行スレッドにおいてはユーザロジックコードを実行する。
タスク実行スレッドが開始されると、それぞれSpout/Boltのどちらを実行しているかに依ってopen/prepareメソッドを呼び出して初期化処理を行う。
Tupleを受信した時、Boltを実行しているタスク実行スレッドはexecuteメソッドを呼び出し、Tupleの処理を行う。
Spoutの場合はデータソースからデータを取得するnextTupleメソッドを継続的に呼び出し、TopologyにTupleとしてこのデータを送信する。
Spout/Boltから送信されたTupleはローカルSMにTupleを転送するGatewayスレッドに送信される。

Tupleを処理することに加えて、タスク実行スレッドは「Tupleの処理する」「Tupleの送信数」「TupleへのAck送信数」「Tuple処理にかかった処理時間」等、いくつかのメトリクス情報の収集も行う。

先ほどのHeronのスレッド構成の図にに示されたように、Gatewayスレッドとタスク実行スレッドは3つの一方向キューを用いて通信を行う。

Gatewayスレッドはdata-inキューをタスク実行スレッドが処理するTupleを送信するために用いる。
タスク実行スレッドはdata-outキューをTopologyの他要素に対して送信したいTupleをGatewayスレッドに送信するために用いる。
metrics-outキューはタスク実行スレッドが収集したメトリクス情報をGatewayスレッドに渡すために用いる。

data-inキュー、data-outキューのサイズは制限がかけられている。
data-inキューのサイズがこの値を超過した場合、GatewayスレッドはローカルSMからの読み取りを中止する。
この動作によって、ローカルSMのBackPressure機能をトリガする形になる。

data-outキューのサイズが制限を超えた場合もGatewayスレッドはローカルSMがこれ以上データを受信できないことを想定することが出来、タスク実行スレッド側でこれ以上Tupleの処理/通信を行うべきでないことがわかる。

我々は制限付きキューを保持したTopologyを運用環境で実行した場合に予期しないGCの問題に遭遇した。
それまで全て正常に動作していたものの、ネットワークの切断によってGatewayスレッドがdata-outキューからデータを送信できない状態になった。
Tupleはdata-outキューにバックアップされはじめた。
このような状況はHIのメモリ上限に達するという結果をもたらした。ネットワークが復旧した際にGatewayスレッドはローカルSMに対してデータを送信するだけでなく、並行してデータの受信も再開する。
GatewayスレッドがTupleを送信する前にローカルSMからデータの受信を始めてしまうとdata-outキューで既にメモリの上限に達していた場合にGCを頻発させてパフォーマンスの低下を招いてしまう。

このようなGCの問題を回避するためには、data-outキューとdata-inキューのサイズを定期的に確認し、それによって制限値を増減させる対処を取っている。
キューの容量は継続的にサイズが増大し続ける場合はその時点の最終容量の半分まで容量が低減される。
キューの容量が安定して一定の値に戻るか、または0になるまでこの機構は定期的に呼び出される。
キューの容量が0になると新しいTupleを投入することが可能となり、結果新たなTupleを生成することにもなる。結果として、GCの問題から回復することも容易となる。
同様に、キュー内に保持されたTupleが設定されたリミットよりも小さくなった場合、設定された制限値か最大値に達するまでキャパシティを徐々に増大させることも行っている。

5.6 Metrics Manager

Metrics Manager(MM)はシステムの全コンポーネントからメトリクスを収集し、出力する。
これらのメトリクスにはTopologyのシステムメトリクスとユーザメトリクスが含まれている。
MMは各コンテナ上に存在し、SMとHIはそのMMに対してメトリクスの通知を行う。

収集されたメトリクスは各コンテナから内製のモニタリングシステムに送信される。
MMは併せて外部UIに表示するための情報をTopology Masterに送信する。
このようにコンテナ単位でMMを保持してそこから外部にメトリクスを送信するという仕組みによって柔軟に他のモニタリングシステム(GanliaやGraphite等に将来的に対応予定)に対する対応が可能となっている。

5.7 Startup Sequence and Failure Scenarios

TopologyがHeronに対してsubmitされると、初期化シーケンスが起動する。

Submit時、リソーススケジューラ(TwitterではAurora)はクラスタ上に存在する各マシン上のリソース状況を確認し、必要なリソースを保持しているマシンに対してコンテナの割り振りを行う。
Topology Master(TM)は一つ目のコンテナとして起動し、Zookeeperに対してディスカバリ用のエフェメラルノードを登録する。
一方、各コンテナ中のStream Manager(SM)はTMを検出するためにZookeeperに対して問い合わせを行う。
SMはTMに接続し、定期的にHeartBeatを送信する。

全てのSMが接続されると、TMは各コンテナに対してTopologyのタスク(Spout/Bolt)の割り当てを行う。
これを物理実行計画と呼んでいる。
割り当てが完了すると、SMは互いを検出するためにTMから物理実行計画を取得する。
現状、SMは互いに接続を行いメッシュ状のネットワークを構成している。

一方、HIは同一コンテナ上のSMを検出して物理実行計画の一部を取得して処理を開始する。これらの初期化ステップが完了後、データ/TupleはTopologyを流れ始める。

障害発生時の保護のため、TMはZookeeperに対して物理実行計画を保存する。

Topology実行中には複数の障害シナリオが存在し、Topologyの部分的に影響を与えるものから、全体に影響を与えるものもまである。
これらのシナリオはプロセスダウン、コンテナ障害、ハード障害といった要素で構成される。

TMがダウンした場合、コンテナはダウンしたプロセスを再起動させる。TMはZookeeperから状態を復旧する。
TMの待機系が存在する場合はTM待機系がマスターとなり、再起動したTMが待機系となる。
TMに接続を行っているSMはZookeeperから新たなTMを検出し、接続する。

SMがダウンした場合、TMと同様に同一コンテナ上で再起動される。起動後、SMはTMに接続して物理実行計画を確認し、変化が発生していないかを確認する。
他のSMは障害が発生したSMと接続が切断されてしまうが、新たなSMの位置を示す実行計画を取得し、それを基に新たなSMに接続する。

HIがダウンした場合はコンテナ内で再起動され、ローカルのSMと再接続する。
その際にSMから物理実行計画を取得し、自分が何を担当すべきだったかを認識して再度ユーザロジックコードを実行開始する。

コンテナレベルでの障害が発生して別マシンにコンテナが配置された場合、新たなコンテナ中のSMはTMを検出し、SMやHIの障害のシナリオと同じ流れに従う。

5.8 Architecture Features: Summary

最後に、Heronのアーキテクチャを見るにあたっては下記の要素に注目してほしい。

  1. リソースのプロビジョニング(コンテナやTM)がクラスタマネージャから制御可能なように抽象化され、共有のインフラ上での動作が容易になっていること。
  2. 各Heron Instanceがシングルタスクを実行するように動いているため、デバッグやjstask、ヒープダンプといった解析が容易になっていること。
  3. Topologyのコンポーネントのメトリクスが分離され、かつ透過的に取得できるようになっているため、システム内でどのプロセスに問題があるかを明確にマッピングすることが出来ること。
  4. コンポーネントレベルでリソース割り当てを可能にしたことに依り、Heronにおいては必要なリソースを明確にすることが出来、オーバープロビジョニングやリソースの無駄を回避できること。
  5. Topology毎にTopology Masterが存在することにより、各Topologyは互いに独立して動作/管理が可能になった。また、あるTopologyでの障害(主にユーザロジックコード上のBoltで発生)は他のTopologyに影響を与えなくなった。
  6. BackPressureの機構により、一定の処理速度と、性能の予測が立てられるようになった。また、BackPressureはTopologyのコンテナ群を別のコンテナ群にマイグレーションする際のキー技術にもなりえる。
  7. 単一障害点が無くなった。

6. Heron in Production

実際にHeronをプロダクション環境で動作させるにあたって、以下のような追加機能が必要になる。

  1. Topologyを容易に操作可能とする機能
  2. Topologyのメトリクス、傾向を確認可能とする機能
  3. Heron Instanceで発生した例外を確認可能とする機能
  4. Topologyのログを確認可能とする機能

これらの機能に対応するために、Twitterでは以下のコンポーネントを追加開発した。

  1. Heron Tracker

Heron TrackerはTopologyに関する様々な情報にアクセスするためのGatewayとして動作する。
具体的にはTopologyがメタデータを保存しているZookeeperとのインタフェースと、Topologyに関する追加情報を収集する。
TrackerはZookeeperの状態を監視し、Topologyの起動/終了や、物理実行計画の変更(例えば、コンテナが別ホストに移動する等)を追跡し続けている。
これらの情報に加えて、TrackerはTopology Masterを検出し、TMが保持している追加の関連メトリクスを取得することにも使用している。

Trackerは明確に定義されたRest APIを用いてこれらの情報を公開しており、追加のツールを用いてデータの取得を行うことも容易になっている。
APIはTopologyの論理実行計画/物理実行計画、ユーザ定義メトリクス/システムメトリクスも含む各種メトリクス、各HIのログに対するリンク、Aurora上のJobページのリンク等を提供する。
TrackerはAuroraのServiceとして実行され、複数インスタンス上で実行することで耐障害性を確保している。APIのリクエストはこれらのインスタンス間でバランシングされる。

  1. Heron UI
  2. Heron Viz

これらの追加コンポーネントの実システム上の配置は下図のようになる。
f:id:kimutansk:20150716052440j:plain

6.1 Heron Tracker

Heron TrackerはTopologyに関する様々な情報にアクセスするためのGatewayとして動作する。
具体的にはTopologyがメタデータを保存しているZookeeperとのインタフェースと、Topologyに関する追加情報を収集する。
TrackerはZookeeperの状態を監視し、Topologyの起動/終了や、物理実行計画の変更(例えば、コンテナが別ホストに移動する等)を追跡し続けている。
これらの情報に加えて、TrackerはTopology Masterを検出し、TMが保持している追加の関連メトリクスを取得することにも使用している。

Trackerは明確に定義されたRest APIを用いてこれらの情報を公開しており、追加のツールを用いてデータの取得を行うことも容易になっている。
APIはTopologyの論理実行計画/物理実行計画、ユーザ定義メトリクス/システムメトリクスも含む各種メトリクス、各HIのログに対するリンク、Aurora上のJobページのリンク等を提供する。
TrackerはAuroraのServiceとして実行され、複数インスタンス上で実行することで耐障害性を確保している。APIのリクエストはこれらのインスタンス間でバランシングされる。

6.2 Heron UI

HeronのユーザはビジュアライズされたUIを用いてTopologyの状態をインタラクティブに確認することが出来る。
Heron UIはHeron Tracker APIを使用し、Topologyの論理実行計画/物理実行計画を視覚的に表現し、表示する。
論理実行計画は一意に色分けされた各ノードと有向非巡回グラフが表示される。
物理実行計画はホストを表す内側の同心円、コンテナを描く中間の円、およびコンポーネントを示す外側の円として表示される。

ユーザはこれらのUIを用いてドリルダウン的にTupleの送信数/完了数/実行時遅延/Ack数/Fail数といったメトリクス情報を10分、1時間、3時間、起動からの総計といった時間単位で区切って確認することが可能。

これらの機能に加えて、Heron UIはインスタンスに関連付けられたログや例外を表示するためのアクセスリンクを提供し、デバッグ容易性を高めている。

下図に5段階のTopologyの可視化の一部を示す。
f:id:kimutansk:20150717060619j:plain

6.3 Heron Viz

Heron VizはMetrics Managerから収集したメトリクスを確認するダッシュボードを生成するサービスである。
Vizは定期的にTrackerにアクセスし、新規Topologyが存在するかを確認している。
新規のTopologyが存在した場合、Vizと呼ばれるグラフ生成のためのHTTP APIを使用し、Dashboardのグラフを生成する。
ダッシュボードを生成するために、VizはTopologyの論理実行計画を取得し、収集したメトリクスがどのコンポーネントマッピングされるかを特定する。(Soput/Boltの存在や、各コンポーネントがどれだけのインスタンスを保持しているかがわからないと詳細情報をマッピングできないため)

大きく分けるとVizのTopologyダッシュボードの表示するメトリクスは以下のメトリクスにカテゴライズ出来る。

  1. 健全性監視メトリクス
  2. リソース監視メトリクス
  3. コンポーネントメトリクス
  4. Stream Managerメトリクス

健全性監視メトリクスではTopology全体の遅延状況や、SpoutにおけるTuple処理失敗カウント、SMの生存状態といった内容が確認可能。

リソース監視メトリクスではCPUの割り当て量と実使用量、メモリの割り当て量と実使用量、GCに費やした時間といった内容が確認可能。

コンポーネントメトリクスでは各Spoutに対してTupleの送信数/Fail数/Ack数といった情報を含む。
また、TupleがSpoutから送信されてから最下流のBoltで処理完了するまでのEndtoEndのレイテンシも含んでいる。
併せて、各Boltに対してTupleの処理数/Ack数/送信数やBoltでの処理平均時間といった情報も確認可能になっている。

Stream Managerメトリクスでは各SMからメトリクスを収集し、HIからの受信Tuple数/送信Tuple数、他SMやHIと送受信する過程でDropしたTuple数、BackPressureが有効になった総時間といった内容が確認可能。

ダッシュボードの部分サンプルは下図の通り。
f:id:kimutansk:20150717062926j:plain

6.4 Heron@Twitter

Twitterでは既にStormは使用しておらず、Heronがストリーム処理の基本となっている。
ここ数カ月で既に数百のTopologyを複数のデータセンターで運用している。
これらのTopologyで何十TBのデータを処理し、何十億の出力を行っている。

Topologyは多様な構成となっており、Topologyの多くはSpout/Boltが3段以下(Spout>Boltの階層が3段階、ということと思われます)のものとなっている。
ただ、それ以上の階層を持つTopologyも存在しており、最長のものは8段に達する。

これらのTopologyの使用事例は多様であり、下記のようなものを含む。

  1. フィルタリング
  2. Twitter上の複数のストリームを統合(例えば、複数のストリームの総合値)
  3. 機械学習アルゴリズム(回帰、関連付け、クラスタリング

Twitterでは様々なグループがHeronを使用している。
これらのグループはユーザサービス、収益成長率、検索、コンテンツ発見といったチームで構成される。

また、これら全体をStormからHeronに移行した結果、インフラの利用効率が大幅に向上し、ストリーム処理に使用するハードを3分の1程に削減することが出来た。

======

と、こんな感じでHeronのアーキテクチャ部を読んでみました。
色々設計の検討過程も含めてわかるというのはやはり読んでいて面白いですし、参考になりますね。
Stormと同様で相変わらずググラビリティが最悪な状態は改善されていませんでしたが。

あとは、Topology(元々はStormのTopology)のSpout/Boltの段数が大部分は3以下、Twitter機械学習なども含めても最大8、というのは違う意味で参考になりました。
つまりは元々のStorm上でTopologyを作成する際もコンポーネントの段数は基本それくらいにおさえておくのがリソース効率的に優れている、ということなのだと思います。

これまで読んできましたが、今使っているStormをより効率よく使うための情報も多分に含まれていたため、現時点でもかなり有用な内容だったと思います。

あとは、Heronが実際に公開されるのを待つばかりですが・・
おそらく、TwitterのブログでもHeronの記事に「OSS Product」とタグ付けされていたため、公開される流れはあるように思われます。
それを楽しみに待つことにしましょうか。


それでは。