Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MillWheel Fault-Tolerant Stream Processing at Internet Scaleの意訳

1,088 views

Published on

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

Published in: Engineering
  • Be the first to comment

MillWheel Fault-Tolerant Stream Processing at Internet Scaleの意訳

  1. 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. 2. 1. MillWheelとは 2. MillWheelに要求されるもの 3. システム概要 4. 構成 5. API 6. フォルト・トレランス 7. 実装 8. 検証(ベンチマーク) 9. 関連研究 2 本ドキュメントの構成
  3. 3. 1.MillWheelとは Googleで使っている、 低レイテンシなストリーム・データ処理 を行うためのフレームワーク。 3
  4. 4. 1.MillWheelとは YAPC Asia 2015「Google Cloud Platformの謎テクノロジーを掘り下げる」のまとめ から引用させて頂きました。 http://qiita.com/kazunori279/items/3ce0ba40e83c8cc6e580 これ 4
  5. 5. 1.MillWheelとは •フレームワークレベルのフォルト・トレランス •状態の永続化 •スケーラビリティ 5 トポロジー上のどのノード/エッジがフェイルしても 正確性を損なわない MillWheelのみ
  6. 6. 2.MillWheelに要求されるもの GoogleのZeitgeist(≒Google Trends)を例に、 MillWheelのフィーチャ・セットでシステム要求を満 たせるか検証 6 Google Trends: https://www.google.com/trends/home/all/JP
  7. 7. 2.MillWheelに要求されるもの Zeitgeist • 検索クエリのヒストリカル・モデルを構築 • 検索トレンドの凹凸を可能な限り速く検出したい • 基本トポロジーは下図 7
  8. 8. 2.MillWheelに要求されるもの • 永続化ストレージ ! • Low Watermarks(低水位標) ! • 重複防止 8 Zeitgeistには数秒〜数ヶ月に渡る多様な期間のデータが存在。 これを保持できるストレージ。 Zeitgeistは分散システム上で、クエリが単純に遅延しているのか、 それとも別要因で遅延しているのか識別する必要がある。 low watermarkは全てのペンディング中のイベントを追跡する。 Zeitgeistにおける重複データは偽のスパイクをうみだす。 故にexactly-once保証が要求される。 MillWheelでは、ユーザコードでロールバックしたり失敗時のシナリオを 書かなくて良い。
  9. 9. 2.MillWheelに要求されるもの その他ストリーム処理フレームワークとして • データは発行されたらすぐに利用可能である • 永続化状態(≒ステート)はユーザ・コードから参照・ 更新可能で、一貫性のあるモデルに統合されている • 厳密な順序は要求しない • Low Watermarkの線形増加はシステム上で計算される • スケールアウトしてもレイテンシーは変わらない • Exactly-Onceなレコード配布 9
  10. 10. 3.システム概要 MillWheelは inputに対してユーザ定義の変換を行い outputを生成する高次元のグラフである ‣ この変換をcomputationと呼ぶ 10
  11. 11. 3.システム概要 MillWheelの計算グラフイメージ • データフローのパイプライン構造 11 computationA computationB computationX computationC レコード レコード レコード ※computationはユーザ・コード 生成物
  12. 12. 3.システム概要 inputとoutputは、(key, value, timestamp)の3要素 で表される。 • key: システム内の意味論的メタ・フィールド • value: レコードに対応するbyte文字列 • timestamp: ユーザコードで付与される eg.イベン ト発生からの経過時間 ※ 次スライドでZeitgeistを例に詳細を解説します。 12
  13. 13. 3.システム概要 13 Zeitgeistの例 • key: 検索語 ‣ eg.”cat video” ‣ クエリ毎に統計量を計算する • value: 任意 • timestamp: 検索実行時刻 ‣ eg.10:59:10
  14. 14. 3.システム概要 その他の特徴 • MillWheelのデータフローに新しくcomputationを追 加したり不要なcomputationを削除することができる • システムの完全再起動は不要。 • MillWheelのフレームワークAPIはレコード処理にべ き等性を保つ。 • MillWheelが供する状態や接続は失敗時の処理やリト ライもMillWheelが隠蔽して行う。 ※注意: MillWheelのexactly-onceは内部的一貫性で外部システムには適用されない。 14
  15. 15. 4.構成 MillWheelの基本的な構成要素 • Computations • Keys • Streams • Persistent State • Low Watermarks • Timers 15
  16. 16. 4.構成 Computations: 計算グラフ • MillWheelがユーザコードをカプセル化。 • コンテキスト内で状態(ステート)を利用可能。 MillWheel コンテキスト/key ユーザコード トリガー: 外部システムからのアクセス、MillWheel内イベント、データ書き出し コンテキスト/key ユーザコード run run 各処理はシリアライズされるが、key単位では並列実行される 16
  17. 17. 4.構成 Keys: キー • 集計と比較の基本概念。 17 レコード レコード (key assigned) key key key key抽出コンシューマ (ユーザ定義) ‣ 同一ストリームから別のコンシューマが別のkeyを抽出する例 • Zeitgeist : keyが検索語 • スパム検出器: keyがcookieフィンガープリント
  18. 18. 4.構成 Streams: ストリーム • 異なる計算間の配信メカニズム。 18 ストリーム: A ストリーム: B ストリーム: X ストリーム: Y ストリーム: Z computationは複数のストリームから複数のストリームを生産する computation
  19. 19. 4.構成 Persistent State: 永続化状態 • MillWheelでの永続化状態はkey単位で管理される。 19 永続化状態は、Window関数の中間結果やjoin時のバッファも含む key: britney key: carly BigTable or Spanner シリアライゼーション/デシリアライゼーション (Protocol Buffer等)
  20. 20. 4.構成 Low Watermarks: 低水位標 • レコードの処理完了予定時刻を提供。 20 タイムラインの上方はペンディング中 のレコード。 タイムラインの下方は完了レコード。 新しいレコードはペンディングとして 配置される。 データの処理順序は決まっていない。 low watermarkはシステム中のすべての ペンディング・タスクを反映する。 low watermark
  21. 21. 4.構成 Low Watermarks: 低水位標 Aのlow watermark = Aの一番古いタスクのタイムスタンプ ➡ Aの一番古い未完了レコード min( Aの最古タスク, Cのlow watermark :C は Aを生成 ) 入力ストリームがないときは、 low watermark = 最古タスク 21
  22. 22. 4.構成 Timers: タイマー • keyごとのプログラマティックなフック • 経過時間やlow watermarkをトリガーとする • タイマーが発火すると特定のユーザ・ファンクショ ンを実行する • タイマーはインプット・レコードに対して同等の exactly-onceを保証する • タイマーはオプション。 22
  23. 23. 5.API • ユーザはcomputationのサブクラスを実装 ! • 自動実行 • key毎シリアライゼーション • ロック 23 }フレームワークが ハンドリング ➡ MillWheelの構成要素にフルアクセス
  24. 24. 5.API Computation API • ProcessRecord • ProcessTimer 24 }2つのメイン・エントリポイント • ProcessRecord: レコード到着がトリガー • ProcessTimer: タイムアウトがトリガー ! MillWheelがフェッチと状態操作を行うシス テム関数を提供する
  25. 25. 5.API Injector and Low Watermark API: Low Watermark • システムレイヤーでは各computationがlow watermarkを計算する • low watermarkはシステムで更新される ‣ APIがタイマーに対して透過であることを保つため • low watermarkはシステムで更新される • ユーザコードからlow watermarkを使用することも できる(ユースケースがあまりないが) 25
  26. 26. 5.API Injector and Low Watermark API: Injectors • Injectorsはinjector low watermarkを生成 • injectorは計算プロセスに分散配置される ‣ 分散配置されたlow wartermarkのトータルがinjector low watermark • injectorの仕組みはプロセスのフェイル・オーバー やネットワーク停電検知に使われる • Googleの共通なインプット(ログファイル、pubsub フィードなど)でこのライブラリが使われている 26
  27. 27. 6.Fault Tolerance Delivery Guarantees: 配信保証 • Exactly-Once Delivery ‣ レコード受信時のMillWheelの挙動 27 1.上流プロセスから配信されたレコードの重複チェック → 重複しているものは破棄 2.ユーザコードを実行 → 可能なものは結果を出力。タイマー・状態・生成物は 変更をペンディング 3.ペンディング中の変更をストレージにコミット 4.送信者にACKを返す 5.ペンディング中の下流プロセスを開放 最適化されて一つの checkpointに!
  28. 28. 6.Fault Tolerance クラッシュ時リカバリの仕組み 28 sender レコード UniqueID UniqueID receiver リトライ リトライ ACK ACKが返るまで リトライ 永続化 クラッシュ UniqueIDの チェック ストレージ ジャーナル 同じレコードに対するアトミックな書 き込みかどうかをチェックする。 ジャーナルにIDがあればリトライを破 棄してACKを返す。 UniqueID
  29. 29. 6.Fault Tolerance Strong Production • 状態変更のようなアトミックな書き込み前にレコー ドをチェック・ポイントすること。 • チェック・ポイントがないと・・・ → Window関数の結果を保存する前にクラッシュ → 復旧後に別のレコードを受け取る → 結果が異なってしまう! • Exactly-OnceとStrong Productionのコンビネーショ ンがべき等を保つ。 • Exactly-OnceやStrong Productionを使わないという 選択も可能(注意が必要。次スライド) 29
  30. 30. 6.Fault Tolerance Weak Productionとべき等 • Weak Productionの状態変更は、レコード配信前に チェック・ポイントせず、楽観的にブロードキャス トする。 • パイプライン上の次ステージまでの待ち時間は下流 のACKに依存するので、階層が深くなるほどレイテ ンシが増大する。 • ペンディング中のstragglerをチェック・ポイント することで改善 → 次スライド。 30
  31. 31. 6.Fault Tolerance Weak Productionとべき等 31 ComputationAがComputationBを生成 するとすぐにComputationCが生成さ れる。 しかしComputationCのACKが遅いので 1秒後にComputationBはチェックポイ ントする。 ゆえにComputationBはComputationA にACKを返すことができ、 ComputationAはリソースを開放でき る。 ComputationBを再実行し、チェック ポイントからレコードをリカバリし てComputationCをリトライする。
  32. 32. 6.Fault Tolerance 32 State Manipulation: 状態の操作 • 状態の操作は下記を保証する必要がある ‣ システムはデータを損失しない ‣ 状態の更新はExactly-Once文脈に従う ‣ すべての永続化データは与えられた任意の時点で一貫 している ‣ Low Watermarksはシステムの全てのペンディング状態 を反映したものである ‣ タイマーはkeyを与えられて発火する
  33. 33. 6.Fault Tolerance 33 State Manipulation: 状態操作の動作保証 • key毎の更新を単一のアトミックな操作にラップ → 対障害性 • 書き込み毎にシーケンサー・トークンを発行 → 前のシーケンサーが残っていないかチェック • computationは適切な粒度でチェック・ポイント → 素早くのシーケンサーが残っていないかチェック • チェック・ポイントの非同期的スキャン
  34. 34. 7.実装 34 Architecture: アーキテクチャ • デプロイ → 分散システムのダイナミックなホスト群にデプロイ • ストリーム → RPCでストリームが分配される • 分散とロードバランス → 冗長化されたマスターによって管理される → CPUとメモリの負荷状況によってタスクを再配置 • 永続化 → BigTable or Spanner
  35. 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. 36. 8.検証(ベンチマーク) outputのレイテンシ • MillWheelはシステムがスケールしても低レイテン シを保つ • 計測対象: ‣ レコード配信のレイテンシ • ユースケース: ‣ 数値ソートとバケットを行うパイプラインの単一 ステージ 36
  37. 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. 38. 8.検証(ベンチマーク) Watermark Lag • Low Watermarkの遅延は集計の鮮度に影響がある • injectorから遠いステージほどラグが発生しそう • 計測対象: ‣ 3ステージパイプライン 38
  39. 39. 8.検証(ベンチマーク) Watermark Lag 39 • 1stステージ: 1.8s • 2ndステージ: 1.9s • 3rdステージ: 2.2s ! 線形に増加 Watermarkラグの削減は 絶賛開発中
  40. 40. 8.検証(ベンチマーク) フレームワーク・レベルのキャッシュ • writeよりreadコストが高いのでキャッシュを利用 • MillWheelプロセスのCPU使用率とストレージレイヤー のCPU使用率の相関を計測 ※ プライバシーポリシーによりCPU使用率は正規化 40
  41. 41. 8.検証(ベンチマーク) フレームワーク・レベルのキャッシュ 41 MillWheelのキャッシュが CPU使用率を減少させている
  42. 42. 8.検証(ベンチマーク) 実際のユースケース: Googleの様々な内部システム • 広告(低レイテンシとビジュアライゼーション) • 異常検知 • ネットワーク・スイッチ • クラスタのヘルス・モニタリング • 画像パノラマ生成 • Googleストリート・ビューの画像処理 42
  43. 43. 8.検証(ベンチマーク) 課題 • システムの安定性は動的負荷分散に依存するため、チェックポイントに抗うモノ リシックな操作をcomputationに含めるのはあまりやらない方がよい。 • ロードバランサの操作中断時の振る舞いは下記の2通り。 • 強制再起動: オーバーロードのリスク • 終了まで待機: リソースの無駄づかい • 異なるkey間で並列化できないケースは効率的に実行されない。 • パイプラインのトラフィックの90%が単一のキーに割り当てられると、1台の マシンがそのストリームに対するシステム負荷の90%を担うことになる。 • computationを実装する際には、二相集計を構築することを推奨。 • アプリケーションの遅延時間はバッファリング・データをフラッシュするlow watermarkに依存するため、メモリ使用量はスキューに比例する。 • 増大するメモリ使用量を防ぐために効果的なのは、low watermarkが進むまで新規 レコードの注入をやめ、システムの総スキューを制限することである。 43
  44. 44. 9.関連研究 • 汎用的なストリーミング・システムとしての概念は MapReduceに大変影響された。 • low watermark計算に見られるような順序なし実行 はOOPのアプローチに似ている。 • MillWheelはM.Stonebreakerの提唱するストリーミ ングシステムをすべて満たす。 see: http://cs.brown.edu/~ugur/8rulesSigRec.pdf 44
  45. 45. 9.関連研究 既存のストリーミング・システムとの比較 45 # 内容 MillWheel Yahoo!S4 Sonora Storm Apache Spark 1 Exactly-Once ◯ ☓ ☓ △ ※Trident ◯ 2 fault-tolerantな永続化 ◯ ☓ ☓ △ ※Trident ◯ 3 ロールバック ◯ ☓ △ ※限界あり ☓ △ ※限界あり MillWheelが影響を受けたプロダクト: ストリーミング・データベース: TelegraphCQ, Aurora, STREAM ロード・バランシング : Flux

×