Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Da467feb3ca0106d571915faedb714f2?s=128

Etsuji Nakai

April 13, 2022
Tweet

More Decks by Etsuji Nakai

Other Decks in Technology

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.