このドキュメントは「MillWheel Fault-Tolerant Stream Processing at Internet Scale」を要約したものです。

1. MillWheel: Fault-Tolerant Stream
Processing at Internet Scale
Tyler 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

2. 1. MillWheelとは
2. MillWheelに要求されるもの
3. システム概要
4. 構成
5. API
6. フォルト・トレランス
7. 実装
8. 検証（ベンチマーク）
9. 関連研究
2
本ドキュメントの構成

3. 1.MillWheelとは
Googleで使っている、
低レイテンシなストリーム・データ処理
を行うためのフレームワーク。
3

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

5. 1.MillWheelとは
•フレームワークレベルのフォルト・トレランス
•状態の永続化
•スケーラビリティ
5
トポロジー上のどのノード／エッジがフェイルしても
正確性を損なわない
MillWheelのみ

6. 2.MillWheelに要求されるもの
GoogleのZeitgeist(≒Google Trends)を例に、
MillWheelのフィーチャ・セットでシステム要求を満
たせるか検証
6
Google Trends: https://www.google.com/trends/home/all/JP

7. 2.MillWheelに要求されるもの
Zeitgeist
• 検索クエリのヒストリカル・モデルを構築
• 検索トレンドの凹凸を可能な限り速く検出したい
• 基本トポロジーは下図
7

8. 2.MillWheelに要求されるもの
• 永続化ストレージ
!
• Low Watermarks(低水位標)
!
• 重複防止
8
Zeitgeistには数秒〜数ヶ月に渡る多様な期間のデータが存在。
これを保持できるストレージ。
Zeitgeistは分散システム上で、クエリが単純に遅延しているのか、
それとも別要因で遅延しているのか識別する必要がある。
low watermarkは全てのペンディング中のイベントを追跡する。
Zeitgeistにおける重複データは偽のスパイクをうみだす。
故にexactly-once保証が要求される。
MillWheelでは、ユーザコードでロールバックしたり失敗時のシナリオを
書かなくて良い。

9. 2.MillWheelに要求されるもの
その他ストリーム処理フレームワークとして
• データは発行されたらすぐに利用可能である
• 永続化状態(≒ステート)はユーザ・コードから参照・
更新可能で、一貫性のあるモデルに統合されている
• 厳密な順序は要求しない
• Low Watermarkの線形増加はシステム上で計算される
• スケールアウトしてもレイテンシーは変わらない
• Exactly-Onceなレコード配布
9

10. 3.システム概要
MillWheelは
inputに対してユーザ定義の変換を行い
outputを生成する高次元のグラフである
‣ この変換をcomputationと呼ぶ
10

11. 3.システム概要
MillWheelの計算グラフイメージ
• データフローのパイプライン構造
11
computationA
computationB
computationX
computationC
レコード レコード
レコード
※computationはユーザ・コード
生成物

12. 3.システム概要
inputとoutputは、(key, value, timestamp)の3要素
で表される。
• key: システム内の意味論的メタ・フィールド
• value: レコードに対応するbyte文字列
• timestamp: ユーザコードで付与される eg.イベン
ト発生からの経過時間
※ 次スライドでZeitgeistを例に詳細を解説します。
12

13. 3.システム概要
13
Zeitgeistの例
• key: 検索語
‣ eg.”cat video”
‣ クエリ毎に統計量を計算する
• value: 任意
• timestamp: 検索実行時刻
‣ eg.10:59:10

14. 3.システム概要
その他の特徴
• MillWheelのデータフローに新しくcomputationを追
加したり不要なcomputationを削除することができる
• システムの完全再起動は不要。
• MillWheelのフレームワークAPIはレコード処理にべ
き等性を保つ。
• MillWheelが供する状態や接続は失敗時の処理やリト
ライもMillWheelが隠蔽して行う。
※注意: MillWheelのexactly-onceは内部的一貫性で外部システムには適用されない。
14

15. 4.構成
MillWheelの基本的な構成要素
• Computations
• Keys
• Streams
• Persistent State
• Low Watermarks
• Timers
15

16. 4.構成
Computations: 計算グラフ
• MillWheelがユーザコードをカプセル化。
• コンテキスト内で状態(ステート)を利用可能。
MillWheel
コンテキスト/key
ユーザコード
トリガー:
外部システムからのアクセス、MillWheel内イベント、データ書き出し
コンテキスト/key
ユーザコード
run
run
各処理はシリアライズされるが、key単位では並列実行される
16

17. 4.構成
Keys: キー
• 集計と比較の基本概念。
17
レコード レコード
(key assigned)
key
key
key
key抽出コンシューマ
(ユーザ定義)
‣ 同一ストリームから別のコンシューマが別のkeyを抽出する例
• Zeitgeist : keyが検索語
• スパム検出器: keyがcookieフィンガープリント

18. 4.構成
Streams: ストリーム
• 異なる計算間の配信メカニズム。
18
ストリーム: A ストリーム: B
ストリーム: X ストリーム: Y ストリーム: Z
computationは複数のストリームから複数のストリームを生産する
computation

19. 4.構成
Persistent State: 永続化状態
• MillWheelでの永続化状態はkey単位で管理される。
19
永続化状態は、Window関数の中間結果やjoin時のバッファも含む
key: britney
key: carly
BigTable
or
Spanner
シリアライゼーション／デシリアライゼーション
(Protocol Buffer等)

20. 4.構成
Low Watermarks: 低水位標
• レコードの処理完了予定時刻を提供。
20
タイムラインの上方はペンディング中
のレコード。
タイムラインの下方は完了レコード。
新しいレコードはペンディングとして
配置される。
データの処理順序は決まっていない。
low watermarkはシステム中のすべての
ペンディング・タスクを反映する。
low watermark

21. 4.構成
Low Watermarks: 低水位標
Aのlow watermark
= Aの一番古いタスクのタイムスタンプ
➡ Aの一番古い未完了レコード
min( Aの最古タスク, Cのlow watermark :C は Aを生成 )
入力ストリームがないときは、
low watermark = 最古タスク
21

22. 4.構成
Timers: タイマー
• keyごとのプログラマティックなフック
• 経過時間やlow watermarkをトリガーとする
• タイマーが発火すると特定のユーザ・ファンクショ
ンを実行する
• タイマーはインプット・レコードに対して同等の
exactly-onceを保証する
• タイマーはオプション。
22

23. 5.API
• ユーザはcomputationのサブクラスを実装
!
• 自動実行
• key毎シリアライゼーション
• ロック
23
}フレームワークが
ハンドリング
➡ MillWheelの構成要素にフルアクセス

24. 5.API
Computation API
• ProcessRecord
• ProcessTimer
24
}2つのメイン・エントリポイント
• ProcessRecord: レコード到着がトリガー
• ProcessTimer: タイムアウトがトリガー
!
MillWheelがフェッチと状態操作を行うシス
テム関数を提供する

25. 5.API
Injector and Low Watermark API: Low Watermark
• システムレイヤーでは各computationがlow
watermarkを計算する
• low watermarkはシステムで更新される
‣ APIがタイマーに対して透過であることを保つため
• low watermarkはシステムで更新される
• ユーザコードからlow watermarkを使用することも
できる（ユースケースがあまりないが）
25

26. 5.API
Injector and Low Watermark API: Injectors
• Injectorsはinjector low watermarkを生成
• injectorは計算プロセスに分散配置される
‣ 分散配置されたlow wartermarkのトータルがinjector
low watermark
• injectorの仕組みはプロセスのフェイル・オーバー
やネットワーク停電検知に使われる
• Googleの共通なインプット(ログファイル、pubsub
フィードなど)でこのライブラリが使われている
26

27. 6.Fault Tolerance
Delivery Guarantees: 配信保証
• Exactly-Once Delivery
‣ レコード受信時のMillWheelの挙動
27
1.上流プロセスから配信されたレコードの重複チェック
→ 重複しているものは破棄
2.ユーザコードを実行
→ 可能なものは結果を出力。タイマー・状態・生成物は
変更をペンディング
3.ペンディング中の変更をストレージにコミット
4.送信者にACKを返す
5.ペンディング中の下流プロセスを開放
最適化されて一つの
checkpointに！

28. 6.Fault Tolerance
クラッシュ時リカバリの仕組み
28
sender
レコード
UniqueID
UniqueID receiver
リトライ
リトライ
ACK
ACKが返るまで
リトライ
永続化
クラッシュ
UniqueIDの
チェック
ストレージ
ジャーナル
同じレコードに対するアトミックな書
き込みかどうかをチェックする。
ジャーナルにIDがあればリトライを破
棄してACKを返す。
UniqueID

29. 6.Fault Tolerance
Strong Production
• 状態変更のようなアトミックな書き込み前にレコー
ドをチェック・ポイントすること。
• チェック・ポイントがないと・・・
→ Window関数の結果を保存する前にクラッシュ
→ 復旧後に別のレコードを受け取る
→ 結果が異なってしまう！
• Exactly-OnceとStrong Productionのコンビネーショ
ンがべき等を保つ。
• Exactly-OnceやStrong Productionを使わないという
選択も可能(注意が必要。次スライド)
29

30. 6.Fault Tolerance
Weak Productionとべき等
• Weak Productionの状態変更は、レコード配信前に
チェック・ポイントせず、楽観的にブロードキャス
トする。
• パイプライン上の次ステージまでの待ち時間は下流
のACKに依存するので、階層が深くなるほどレイテ
ンシが増大する。
• ペンディング中のstragglerをチェック・ポイント
することで改善
→ 次スライド。
30

31. 6.Fault Tolerance
Weak Productionとべき等
31
ComputationAがComputationBを生成
するとすぐにComputationCが生成さ
れる。
しかしComputationCのACKが遅いので
1秒後にComputationBはチェックポイ
ントする。
ゆえにComputationBはComputationA
にACKを返すことができ、
ComputationAはリソースを開放でき
る。
ComputationBを再実行し、チェック
ポイントからレコードをリカバリし
てComputationCをリトライする。

32. 6.Fault Tolerance
32
State Manipulation: 状態の操作
• 状態の操作は下記を保証する必要がある
‣ システムはデータを損失しない
‣ 状態の更新はExactly-Once文脈に従う
‣ すべての永続化データは与えられた任意の時点で一貫
している
‣ Low Watermarksはシステムの全てのペンディング状態
を反映したものである
‣ タイマーはkeyを与えられて発火する

33. 6.Fault Tolerance
33
State Manipulation: 状態操作の動作保証
• key毎の更新を単一のアトミックな操作にラップ
→ 対障害性
• 書き込み毎にシーケンサー・トークンを発行
→ 前のシーケンサーが残っていないかチェック
• computationは適切な粒度でチェック・ポイント
→ 素早くのシーケンサーが残っていないかチェック
• チェック・ポイントの非同期的スキャン

34. 7.実装
34
Architecture: アーキテクチャ
• デプロイ
→ 分散システムのダイナミックなホスト群にデプロイ
• ストリーム
→ RPCでストリームが分配される
• 分散とロードバランス
→ 冗長化されたマスターによって管理される
→ CPUとメモリの負荷状況によってタスクを再配置
• 永続化
→ BigTable or Spanner

35. 7.実装
35
Low Watermarks
• 一貫性保証のためLow Watermarkは、グローバルに
利用可能なサブシステムである必要がある
(速度＞精度 優先にすることも可能)
すべてのLow Watermak値をトラッキングする
中央集中型のシステムを実装
# computation interval
1 computation A 200ms
2 computation B 1,200ms
3 computation : 10ms
4 computation X 5mslow watermark
中央管理
computationとlow watermarkのインターバル・マップ

36. 8.検証(ベンチマーク)
outputのレイテンシ
• MillWheelはシステムがスケールしても低レイテン
シを保つ
• 計測対象:
‣ レコード配信のレイテンシ
• ユースケース:
‣ 数値ソートとバケットを行うパイプラインの単一
ステージ
36

37. outputのレイテンシ
8.検証(ベンチマーク)
37
実行環境:200CPU
Strong Productionとexactly-once使用せず
レコード遅延の中央値:3.6ms
95thパーセンタイル :30ms
Strong Productionとexactly-once使用
レコード遅延の中央値:33.7ms
95thパーセンタイル :93.8ms
実行環境:20CPU → 200CPU
• レイテンシの中央値は一定
• 99thパーセンタイルの値は悪い。
→ テイルのレイテンシはスケールに伴っ
て悪化する(からしようがない)

38. 8.検証(ベンチマーク)
Watermark Lag
• Low Watermarkの遅延は集計の鮮度に影響がある
• injectorから遠いステージほどラグが発生しそう
• 計測対象:
‣ 3ステージパイプライン
38

39. 8.検証(ベンチマーク)
Watermark Lag
39
• 1stステージ: 1.8s
• 2ndステージ: 1.9s
• 3rdステージ: 2.2s
!
線形に増加
Watermarkラグの削減は
絶賛開発中

40. 8.検証(ベンチマーク)
フレームワーク・レベルのキャッシュ
• writeよりreadコストが高いのでキャッシュを利用
• MillWheelプロセスのCPU使用率とストレージレイヤー
のCPU使用率の相関を計測
※ プライバシーポリシーによりCPU使用率は正規化
40

41. 8.検証(ベンチマーク)
フレームワーク・レベルのキャッシュ
41
MillWheelのキャッシュが
CPU使用率を減少させている

42. 8.検証(ベンチマーク)
実際のユースケース: Googleの様々な内部システム
• 広告(低レイテンシとビジュアライゼーション)
• 異常検知
• ネットワーク・スイッチ
• クラスタのヘルス・モニタリング
• 画像パノラマ生成
• Googleストリート・ビューの画像処理
42

43. 8.検証(ベンチマーク)
課題
• システムの安定性は動的負荷分散に依存するため、チェックポイントに抗うモノ
リシックな操作をcomputationに含めるのはあまりやらない方がよい。
• ロードバランサの操作中断時の振る舞いは下記の２通り。
• 強制再起動: オーバーロードのリスク
• 終了まで待機: リソースの無駄づかい
• 異なるkey間で並列化できないケースは効率的に実行されない。
• パイプラインのトラフィックの90％が単一のキーに割り当てられると、1台の
マシンがそのストリームに対するシステム負荷の90％を担うことになる。
• computationを実装する際には、二相集計を構築することを推奨。
• アプリケーションの遅延時間はバッファリング・データをフラッシュするlow
watermarkに依存するため、メモリ使用量はスキューに比例する。
• 増大するメモリ使用量を防ぐために効果的なのは、low watermarkが進むまで新規
レコードの注入をやめ、システムの総スキューを制限することである。
43

44. 9.関連研究
• 汎用的なストリーミング・システムとしての概念は
MapReduceに大変影響された。
• low watermark計算に見られるような順序なし実行
はOOPのアプローチに似ている。
• MillWheelはM.Stonebreakerの提唱するストリーミ
ングシステムをすべて満たす。
see: http://cs.brown.edu/~ugur/8rulesSigRec.pdf
44

45. 9.関連研究
既存のストリーミング・システムとの比較
45
# 内容 MillWheel Yahoo!S4 Sonora Storm Apache Spark
1 Exactly-Once ◯ ☓ ☓
△
※Trident
◯
2 fault-tolerantな永続化 ◯ ☓ ☓
△
※Trident
◯
3 ロールバック ◯ ☓
△
※限界あり ☓
△
※限界あり
MillWheelが影響を受けたプロダクト:
ストリーミング・データベース: TelegraphCQ, Aurora, STREAM
ロード・バランシング : Flux