Cloud Monitoring を支える 分散グローバルデータストア「Monarch」

「GCPUG Shonan vol.74」で使用予定のスライドです。
https://gcpug-shonan.connpass.com/event/243711/

Transcript

1. Cloud Monitoring を支える 分散グローバルデータストア「Monarch」 中井 悦司 Google Cloud, Solutions Architect このスライドはコミュニティイベント「 GCPUG Shonan vol.74」での発表資料です
2. 中井悦司 / Etsuji Nakai Solutions Architect, Google Cloud $ who am i
3. Managed Service for Prometheus の発表 Blog 記事 3 https://cloud.google.com/blog/ja/products/operations/introducing-google-cloud-managed-service-for-prometheus
4. Monarch とは？ 4 https://research.google/pubs/pub50652/ • Google が独自開発したモニタリングシステム専用の分散型の時系列データストア • Google Cloud では、Cloud Monitoring のバックエンドとして使用 ◦ Google 社内使用の Monarch とは別システム • Google 社内では、YouTube、Gmail、Google Maps などのチームが共同で利用している • アーキテクチャーと Google 社内での利用方法を解説した論文が公開されている ◦ この後の内容（図表を含む）は、すべてこの論文の内容がベースになります。
5. Contents 5 • Monarch のアーキテクチャー概要 • データの書き込み処理 • データの検索処理 • 実環境における稼働状況（2019 年のデータ）
6. Monarch のアーキテクチャー概要
7. 前提知識 7 • Google 社内のアプリケーションは Borg の「ジョブ」として稼働する • ゾーンごとに複数の Borg クラスターがある • 1 つのジョブは、複数の「タスク」を起動してスケールアウトする • イメージとしてはこんな感じ ◦ Borg クラスター ＝ Kubernetes クラスター ◦ ジョブ ＝ ReplicaSet ◦ タスク ＝ Pod ◦ ビルドラベル ＝ コンテナイメージの「イメージ ID」
8. Monarch のアーキテクチャー 8 • 複数ゾーンに分散配置 • ゾーン内の複数の「Leaf」にデータを分散保存
9. Monarch のデータモデル 9 • データ全体は、「ターゲット」部分のフィールドと「メトリック」部分のフィールドで構成される ◦ 「ターゲット」＝「データ収集対象のコンポーネント」（例： Borg 上のタスク） ◦ 「メトリック」＝「収集するデータ項目」（例： API のコマンドごとのレイテンシー） • 「ターゲット + メトリック」を改めて「キー」と「バリュー」に分割する ◦ メトリックの最後のフィールド（時系列データ本体を含む部分）が「バリュー」 ◦ 残りのフィールド全体が「キー」：キーごとに対応する時系列データが蓄積されていく ターゲット メトリック キー バリュー 時系列データ 例：Borg で稼働するタスクの APIごとのレイテンシーデータ
10. Monarch のデータモデル 10 • ターゲットに含まれるロケーションフィールドでゾーンが決まる • ターゲット全体の値でゾーン内の Leaf が決まる ◦ ターゲット全体の辞書順のレンジでシャーディング ◦ 連続するターゲット値を対象とした検索は、 1 つの Leaf で処理が完結する ロケーション ターゲット メトリック
11. タイムスタンプ共有によるデータ圧縮 11 • 同じターゲットからのメトリックは、同じ Leaf に保存される • 同じターゲットからのメトリックは、タイムスタンプの並びが同じになることが多い ◦ 例：タスクが提供する API ごとのレイテンシー 　　→ タスクごとにレイテンシーを収集・送信するタイミングは同一になる • ターゲットごとにタイムスタンプを共有して、効率的なデータ圧縮ができる（処理速度を優先して、差分保存、 連長圧縮（RLE）など軽量な圧縮技術を利用） ターゲットごとに タイムスタンプを共有
12. バリューのデータ型 12 • boolean、int64、double、string、distribution、および、これらをまとめたタプル型 • distribution（分布）型 ◦ double 型の数値データをヒストグラムの形式でまとめたもので、値の範囲を区切ったバケットとそ れぞれのバケットに含まれるデータ数から構成される ◦ 例：「過去 1 分間のレイテンシーの分布」を 1 分ごとの時系列データとして保存 ※ クエリーを用いて「過去 1 時間のレイテンシーの分布」の 1 分ごとの時系列データに変換するこ とも可能 ヒストグラムの例
13. クエリーの例 13 • API レイテンシーのデータとビルドラベルのデータ を Join • 以下の条件でフィルタリング ◦ ジョブの実行ユーザーが「 monarch」 ◦ ジョブ名が「mixer」で始まる • ビルドラベルごとにレイテンシーの分布を集約 ◦ group_by [label], aggregate(latency) • 「過去 1 時間のレイテンシーの分布」を生成 ◦ delta (1h) ※「特定のビルドのレイテンシーが大きく変化している場合、該当 のビルドに問題があるかも？」という想定でのクエリー
14. データの書き込み処理
15. データの書き込みの流れ 15 • データ書き込みの流れ： クライアント → Ingestion Router → Leaf Router → Leaf • ターゲットの辞書順でのレンジによるシャーディング • 冗長化のために 3 つの Leaf に同じデータを保存 ロケーションフィールドで転送 先のゾーンを決定 ターゲットで 転送先の Leaf を決定
16. Leaf 上でのデータ書き込み 16 • Leaf 上のデータは、すべてオンメモリーに保存 ◦ 膨大なデータの高速な書き込みと検索に対応するため • 受け取ったデータの情報は、追記型のリカバリーログファイルにも書き込み • ただし、ログファイルへの書き込みは完全非同期で実施（書き込み完了を待たずに処理を継続） ◦ リカバリーログファイルの書き込み先は、 Colossus の分散ファイルシステム ◦ Colossus のモニタリングにも Monarch を使用している ◦ Colossus の障害で Monarch が止まると Colossus のモニタリングができないので、リカバリーログ ファイルが書けなくても、 Monarch は処理を継続するように設計されている
17. データの動的再配置（リシャーディング） 17 • Range Assigner は、各 Leaf が担当する（保存する）「ターゲットのレンジ」を割り当てる • Leaf の負荷状況に応じて、動的に割り当てを変更する • 例：Leaf A のターゲットを Leaf B に移動する場合 ◦ 該当ターゲットを（一時的に） Leaf A と Leaf B の両方に割り当てる ◦ Leaf B は（新規データを受け取りつつ）リカバリーログを用いて、過去のデータを復元する ◦ 復元が終わったら、Leaf A に対する割り当てを解除する Leaf A Leaf B 時間 再配置開始 並列に データ保存 リカバリーログ から復元 ターゲットの レンジを割り当て
18. 複数ターゲットのデータ集約 18 • たとえば、ディスク I/O の回数は、個々のディスク装置が 1 つのキーを持つが、ディスク装置個別のデータを 収集するのは（データ量の観点で）無駄が多い。「クラスターに含まれるディスク全体の I/O 総数」が分かれ ば十分 ◦ このような時は、複数ターゲットのデータ集約が設定できる ◦ 典型的には、30 個程度のターゲットを集約するが、数百万ターゲットを集約することもある • 個々のターゲットのクライアントは「一定期間（ T_D 秒間）の総数」を定期的に送信する ◦ たとえば、「T_D = 10 秒」 • データを受け取った Leaf は、同一のクラスターに属するデータを集約して保存する ◦ T_D より長い期間（T_B 秒間）でデータを足し上げて保存する ◦ たとえば、「T_D = 60 秒」
19. 複数ターゲットのデータ集約 19 • 「delta」が 1 回に送信されてくるデータ（ T_D 秒間の総数） • 「bucket」が集約する時間範囲（ T_B 秒間の総数） ◦ 「delta」の末尾の時刻によって、追加する「 bucket」を決定する • 極端に遅延して到着したデータは「 bucket」に追加せずに破棄する ◦ 「Admission Window」の範囲のデータを受け付ける ◦ 「Admission Window」は「T_W 秒前〜現在時刻」の範囲を示す 時刻同期には TrueTime APIを使用 時間 現在時刻 データ送信時刻 Admission Window を過ぎた データ（遅延データ）は破棄
20. データの検索処理
21. 検索処理の流れ 21 • 検索処理は 2 種類 ◦ アドホッククエリー：SRE やアナリストが対話的に検索文を入力 ◦ 継続クエリー：事前に定義したクエリーを定期的に実行して、結果をビューに保存 • 継続クエリーの目的 ◦ ダッシュボードに表示するデータ（ビュー）を作成 ◦ アラートを生成 • 継続クエリーは、Root Evaluator もしくは Zone Evaluator が 定期的に実行して、結果をビューに保存 ◦ 特定ゾーンのデータのみを検索することが分かってい る場合は、該当ゾーンの Zone Evaluator が担当 • 複数の Evaluator があり、検索文全体のハッシュ値で負荷 分 散する
22. 検索処理の流れ 22 • 検索処理の流れ：Root Evaluator → Root Mixer → Zone Mixer → Leaf • Root Mixer は、クエリーの最適化、セキュリティチェックなどを行い、各ゾーンの Zone Mixer に（該当ゾーン のデータに対する）検索処理を送信 • Zone Mixer は、Index Server を参照して、検索対象データを持つ Leaf を特定。該当のデータを持つ Leaf に検索処理を送信 • それぞれの Leaf は、担当する範囲のデータを取得 ◦ ローカルでできる範囲のフィルタリングやグルーピン グ（group_by）を実行することで、返信するデータ量 を削減 • Leaf → Zone Mixer → Root Mixer の順に返信データが 集約されて検索が完了する
23. Index Server の仕組み 23 • ターゲットに含まれる値から該当データを持つ Leaf の リストを高速に取得する必要がある ◦ シンプルなオンメモリのインデックスが必要 ターゲットに含まれる値で 検索対象を指定 • ターゲットに含まれる値（文字列）の「トリグラム」をキーとする辞書を利用する ◦ leaf_list["abc"] = 担当するターゲットが部分文字列 "abc" を含む Leaf のリスト ◦ 「（英数字・記号の個数） ^3 」個のリストにすべてのデータが格納できる（数 GBに収まる） • 正規表現 "mixer.*" にマッチするには、"^^m"、"^mi"、"mix"、"ixe"、"xer" のすべてに含まれる Leaf を取得 すればよい • Zone Mixer は取得した Leaf に、必要なデータを本当に持っているかを問い合わせた後、データの範囲ご とに検索を依頼する Leaf を決定する（複数の Leaf に重複保存されているので、 Leaf の稼働状態なども参 考にして最適な Leaf を選択する）
24. 検索処理の耐障害性を高める工夫 24 • Zone Mixer からの応答が極端に遅延するゾーンは、検索結果に含めない ◦ ユーザーには、特定ゾーンのデータが含まれていないことを示す警告が表示される • 特定の Leaf からの応答が極端に遅延する場合、 Zone Mixer は（同じデータを持つ）他の Leaf にも並列し て検索を依頼する
25. 実環境における稼働状況 （2019 年のデータ）
26. デプロイの規模（Google 社内利用の Monarch） 26 • 38 のゾーンを使用 ◦ Leaf が 100 未満のゾーン：5 ◦ Leaf が 100〜1,000 のゾーン：16 ◦ Leaf が 1,000〜10,000 のゾーン：11 ◦ Leaf が 10,000 以上のゾーン：6 各コンポーネントが稼働するタスク（コンテナ）数
27. デプロイの規模（Google 社内利用の Monarch） 27
28. 検索性能（レイテンシー） 28 • Root Mixer を用いた検索 ◦ 中央値：79ms ◦ 99.9%-ile：6s • ゾーンが大きい（検索対象の Leaf が多い）と検索は遅くなる ◦ Leaf が 1,000 以上のゾーン での 99.9%-ile：50s
29. Thank You.