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に含めるのはあまりやらない方がよい。
• ロードバランサの操作中断時の振る舞いは下記の2通り。 • 強制再起動: オーバーロードのリスク • 終了まで待機: リソースの無駄づかい
• 異なる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
Top Related