MillWheel: Fault-Tolerant Stream Processing at Internet ScaleTyler Akidau, Alex Balikov, Kaya Bekiroglu, Slava Chernyak, Josh Haberman,

Reuven Lax, Sam McVeety, Daniel Mills, Paul Nordstrom, Sam Whittle Google

このドキュメントは「MillWheel:インターネットスケールにおけるフォルト・トレラントなストリーム処理」を要約したものです

原文: http://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/41378.pdf

1. MillWheelとは

2. MillWheelに要求されるもの

3. システム概要

4. 構成

5. API

6. フォルト・トレランス

7. 実装

8. 検証（ベンチマーク）

9. 関連研究

2

本ドキュメントの構成

1.MillWheelとは

Googleで使っている、

低レイテンシなストリーム・データ処理

を行うためのフレームワーク。

3

1.MillWheelとは

YAPC Asia 2015「Google Cloud Platformの謎テクノロジーを掘り下げる」のまとめ から引用させて頂きました。 http://qiita.com/kazunori279/items/3ce0ba40e83c8cc6e580

これ

4

1.MillWheelとは•フレームワークレベルのフォルト・トレランス

•状態の永続化

•スケーラビリティ

5

トポロジー上のどのノード／エッジがフェイルしても正確性を損なわない

MillWheelのみ

2.MillWheelに要求されるものGoogleのZeitgeist(≒Google Trends)を例に、MillWheelのフィーチャ・セットでシステム要求を満たせるか検証

6

Google Trends: https://www.google.com/trends/home/all/JP

2.MillWheelに要求されるものZeitgeist

• 検索クエリのヒストリカル・モデルを構築

• 検索トレンドの凹凸を可能な限り速く検出したい

• 基本トポロジーは下図

7

2.MillWheelに要求されるもの• 永続化ストレージ

!

• Low Watermarks(低水位標)

!

• 重複防止

8

Zeitgeistには数秒〜数ヶ月に渡る多様な期間のデータが存在。 これを保持できるストレージ。

Zeitgeistは分散システム上で、クエリが単純に遅延しているのか、 それとも別要因で遅延しているのか識別する必要がある。 low watermarkは全てのペンディング中のイベントを追跡する。

Zeitgeistにおける重複データは偽のスパイクをうみだす。 故にexactly-once保証が要求される。 MillWheelでは、ユーザコードでロールバックしたり失敗時のシナリオを 書かなくて良い。

2.MillWheelに要求されるものその他ストリーム処理フレームワークとして

• データは発行されたらすぐに利用可能である

• 永続化状態(≒ステート)はユーザ・コードから参照・更新可能で、一貫性のあるモデルに統合されている

• 厳密な順序は要求しない

• Low Watermarkの線形増加はシステム上で計算される

• スケールアウトしてもレイテンシーは変わらない

• Exactly-Onceなレコード配布

9

3.システム概要

MillWheelは

inputに対してユーザ定義の変換を行い

outputを生成する高次元のグラフである

‣ この変換をcomputationと呼ぶ

10

3.システム概要MillWheelの計算グラフイメージ

• データフローのパイプライン構造

11

computationA

computationB

computationX

computationC

レコード レコード

レコード

※computationはユーザ・コード

生成物

3.システム概要

inputとoutputは、(key, value, timestamp)の3要素で表される。

• key: システム内の意味論的メタ・フィールド

• value: レコードに対応するbyte文字列

• timestamp: ユーザコードで付与される eg.イベント発生からの経過時間

※ 次スライドでZeitgeistを例に詳細を解説します。

12

3.システム概要

13

Zeitgeistの例

• key: 検索語 ‣ eg.”cat video” ‣ クエリ毎に統計量を計算する

• value: 任意

• timestamp: 検索実行時刻 ‣ eg.10:59:10

3.システム概要その他の特徴

• MillWheelのデータフローに新しくcomputationを追加したり不要なcomputationを削除することができる

• システムの完全再起動は不要。

• MillWheelのフレームワークAPIはレコード処理にべき等性を保つ。

• MillWheelが供する状態や接続は失敗時の処理やリトライもMillWheelが隠蔽して行う。

※注意: MillWheelのexactly-onceは内部的一貫性で外部システムには適用されない。

14

4.構成MillWheelの基本的な構成要素

• Computations

• Keys

• Streams

• Persistent State

• Low Watermarks

• Timers

15

4.構成Computations: 計算グラフ

• MillWheelがユーザコードをカプセル化。 • コンテキスト内で状態(ステート)を利用可能。

MillWheel

コンテキスト/key

ユーザコード

トリガー: 外部システムからのアクセス、MillWheel内イベント、データ書き出し

コンテキスト/key

ユーザコード

run

run

各処理はシリアライズされるが、key単位では並列実行される

16

4.構成Keys: キー

• 集計と比較の基本概念。

17

レコード レコード (key assigned)

keykeykey

key抽出コンシューマ(ユーザ定義)

‣ 同一ストリームから別のコンシューマが別のkeyを抽出する例

• Zeitgeist : keyが検索語 • スパム検出器: keyがcookieフィンガープリント

4.構成Streams: ストリーム

• 異なる計算間の配信メカニズム。

18

ストリーム: A ストリーム: B

ストリーム: X ストリーム: Y ストリーム: Z

computationは複数のストリームから複数のストリームを生産する

computation

4.構成Persistent State: 永続化状態

• MillWheelでの永続化状態はkey単位で管理される。

19

永続化状態は、Window関数の中間結果やjoin時のバッファも含む

key: britney

key: carly

BigTable or

Spanner

シリアライゼーション／デシリアライゼーション (Protocol Buffer等)

4.構成Low Watermarks: 低水位標

• レコードの処理完了予定時刻を提供。

20

タイムラインの上方はペンディング中のレコード。

タイムラインの下方は完了レコード。

新しいレコードはペンディングとして配置される。

データの処理順序は決まっていない。

low watermarkはシステム中のすべてのペンディング・タスクを反映する。

low watermark

4.構成Low Watermarks: 低水位標

Aのlow watermark = Aの一番古いタスクのタイムスタンプ

➡ Aの一番古い未完了レコード

min( Aの最古タスク, Cのlow watermark :C は Aを生成 )

入力ストリームがないときは、

low watermark = 最古タスク

21

4.構成Timers: タイマー

• keyごとのプログラマティックなフック

• 経過時間やlow watermarkをトリガーとする

• タイマーが発火すると特定のユーザ・ファンクションを実行する

• タイマーはインプット・レコードに対して同等のexactly-onceを保証する

• タイマーはオプション。

22

5.API• ユーザはcomputationのサブクラスを実装

!

• 自動実行

• key毎シリアライゼーション

• ロック

23

} フレームワークが ハンドリング

➡ MillWheelの構成要素にフルアクセス

5.APIComputation API

• ProcessRecord

• ProcessTimer

24

} 2つのメイン・エントリポイント

• ProcessRecord: レコード到着がトリガー • ProcessTimer: タイムアウトがトリガー !MillWheelがフェッチと状態操作を行うシステム関数を提供する

5.APIInjector and Low Watermark API: Low Watermark

• システムレイヤーでは各computationがlow watermarkを計算する

• low watermarkはシステムで更新される ‣ APIがタイマーに対して透過であることを保つため

• low watermarkはシステムで更新される

• ユーザコードからlow watermarkを使用することもできる（ユースケースがあまりないが）

25

5.APIInjector and Low Watermark API: Injectors

• Injectorsはinjector low watermarkを生成

• injectorは計算プロセスに分散配置される ‣ 分散配置されたlow wartermarkのトータルがinjector

low watermark

• injectorの仕組みはプロセスのフェイル・オーバーやネットワーク停電検知に使われる

• Googleの共通なインプット(ログファイル、pubsubフィードなど)でこのライブラリが使われている

26

6.Fault ToleranceDelivery Guarantees: 配信保証

• Exactly-Once Delivery ‣ レコード受信時のMillWheelの挙動

27

1.上流プロセスから配信されたレコードの重複チェック → 重複しているものは破棄

2.ユーザコードを実行 → 可能なものは結果を出力。タイマー・状態・生成物は

変更をペンディング

3.ペンディング中の変更をストレージにコミット

4.送信者にACKを返す

5.ペンディング中の下流プロセスを開放最適化されて一つのcheckpointに！

6.Fault Toleranceクラッシュ時リカバリの仕組み

28

senderレコード

UniqueIDUniqueID receiver

リトライ

リトライ

ACK

ACKが返るまでリトライ

永続化

クラッシュ

UniqueIDのチェック

ストレージ

ジャーナル

同じレコードに対するアトミックな書き込みかどうかをチェックする。 ジャーナルにIDがあればリトライを破棄してACKを返す。

UniqueID

6.Fault ToleranceStrong Production

• 状態変更のようなアトミックな書き込み前にレコードをチェック・ポイントすること。

• チェック・ポイントがないと・・・ → Window関数の結果を保存する前にクラッシュ

→ 復旧後に別のレコードを受け取る → 結果が異なってしまう！

• Exactly-OnceとStrong Productionのコンビネーションがべき等を保つ。

• Exactly-OnceやStrong Productionを使わないという選択も可能(注意が必要。次スライド)

29

6.Fault ToleranceWeak Productionとべき等

• Weak Productionの状態変更は、レコード配信前にチェック・ポイントせず、楽観的にブロードキャストする。

• パイプライン上の次ステージまでの待ち時間は下流のACKに依存するので、階層が深くなるほどレイテンシが増大する。

• ペンディング中のstragglerをチェック・ポイントすることで改善 → 次スライド。

30

6.Fault ToleranceWeak Productionとべき等

31

ComputationAがComputationBを生成するとすぐにComputationCが生成される。

しかしComputationCのACKが遅いので1秒後にComputationBはチェックポイントする。

ゆえにComputationBはComputationAにACKを返すことができ、ComputationAはリソースを開放できる。

ComputationBを再実行し、チェックポイントからレコードをリカバリしてComputationCをリトライする。

6.Fault Tolerance

32

State Manipulation: 状態の操作

• 状態の操作は下記を保証する必要がある

‣ システムはデータを損失しない

‣ 状態の更新はExactly-Once文脈に従う

‣ すべての永続化データは与えられた任意の時点で一貫している

‣ Low Watermarksはシステムの全てのペンディング状態を反映したものである

‣ タイマーはkeyを与えられて発火する

6.Fault Tolerance

33

State Manipulation: 状態操作の動作保証

• key毎の更新を単一のアトミックな操作にラップ → 対障害性

• 書き込み毎にシーケンサー・トークンを発行 → 前のシーケンサーが残っていないかチェック

• computationは適切な粒度でチェック・ポイント → 素早くのシーケンサーが残っていないかチェック

• チェック・ポイントの非同期的スキャン

7.実装

34

Architecture: アーキテクチャ

• デプロイ → 分散システムのダイナミックなホスト群にデプロイ

• ストリーム → RPCでストリームが分配される

• 分散とロードバランス → 冗長化されたマスターによって管理される

→ CPUとメモリの負荷状況によってタスクを再配置

• 永続化 → BigTable or Spanner

7.実装

35

Low Watermarks

• 一貫性保証のためLow Watermarkは、グローバルに利用可能なサブシステムである必要がある

(速度＞精度 優先にすることも可能)

すべてのLow Watermak値をトラッキングする 中央集中型のシステムを実装

# computation interval1 computation A 200ms2 computation B 1,200ms3 computation : 10ms4 computation X 5mslow watermark

中央管理computationとlow watermarkのインターバル・マップ

8.検証(ベンチマーク)outputのレイテンシ

• MillWheelはシステムがスケールしても低レイテンシを保つ

• 計測対象: ‣ レコード配信のレイテンシ

• ユースケース: ‣ 数値ソートとバケットを行うパイプラインの単一ステージ

36

outputのレイテンシ

8.検証(ベンチマーク)

37

実行環境:200CPU

Strong Productionとexactly-once使用せず レコード遅延の中央値:3.6ms 95thパーセンタイル :30ms

Strong Productionとexactly-once使用 レコード遅延の中央値:33.7ms 95thパーセンタイル :93.8ms

実行環境:20CPU → 200CPU

• レイテンシの中央値は一定 • 99thパーセンタイルの値は悪い。

→ テイルのレイテンシはスケールに伴って悪化する(からしようがない)

8.検証(ベンチマーク)Watermark Lag

• Low Watermarkの遅延は集計の鮮度に影響がある

• injectorから遠いステージほどラグが発生しそう

• 計測対象: ‣ 3ステージパイプライン

38

8.検証(ベンチマーク)Watermark Lag

39

• 1stステージ: 1.8s • 2ndステージ: 1.9s • 3rdステージ: 2.2s !

線形に増加

Watermarkラグの削減は 絶賛開発中

8.検証(ベンチマーク)フレームワーク・レベルのキャッシュ

• writeよりreadコストが高いのでキャッシュを利用

• MillWheelプロセスのCPU使用率とストレージレイヤーのCPU使用率の相関を計測

※ プライバシーポリシーによりCPU使用率は正規化

40

8.検証(ベンチマーク)フレームワーク・レベルのキャッシュ

41

MillWheelのキャッシュが CPU使用率を減少させている

8.検証(ベンチマーク)実際のユースケース: Googleの様々な内部システム

• 広告(低レイテンシとビジュアライゼーション)

• 異常検知

• ネットワーク・スイッチ

• クラスタのヘルス・モニタリング

• 画像パノラマ生成

• Googleストリート・ビューの画像処理

42

8.検証(ベンチマーク)課題

• システムの安定性は動的負荷分散に依存するため、チェックポイントに抗うモノリシックな操作をcomputationに含めるのはあまりやらない方がよい。

• ロードバランサの操作中断時の振る舞いは下記の２通り。 • 強制再起動: オーバーロードのリスク • 終了まで待機: リソースの無駄づかい

• 異なるkey間で並列化できないケースは効率的に実行されない。 • パイプラインのトラフィックの90％が単一のキーに割り当てられると、1台のマシンがそのストリームに対するシステム負荷の90％を担うことになる。

• computationを実装する際には、二相集計を構築することを推奨。

• アプリケーションの遅延時間はバッファリング・データをフラッシュするlow watermarkに依存するため、メモリ使用量はスキューに比例する。

• 増大するメモリ使用量を防ぐために効果的なのは、low watermarkが進むまで新規レコードの注入をやめ、システムの総スキューを制限することである。

43

9.関連研究

• 汎用的なストリーミング・システムとしての概念はMapReduceに大変影響された。

• low watermark計算に見られるような順序なし実行はOOPのアプローチに似ている。

• MillWheelはM.Stonebreakerの提唱するストリーミングシステムをすべて満たす。 see: http://cs.brown.edu/~ugur/8rulesSigRec.pdf

44

9.関連研究既存のストリーミング・システムとの比較

45

# 内容 MillWheel Yahoo!S4 Sonora Storm Apache Spark

1 Exactly-Once ◯ ☓ ☓ △ ※Trident ◯

2 fault-tolerantな永続化 ◯ ☓ ☓ △ ※Trident ◯

3 ロールバック ◯ ☓ △ ※限界あり ☓ △

※限界あり

MillWheelが影響を受けたプロダクト:

ストリーミング・データベース: TelegraphCQ, Aurora, STREAM

ロード・バランシング : Flux