Cloud Monitoring を支える 分散グローバルデータストア「Monarch」 中井 悦司 Google Cloud, Solutions Architect このスライドはコミュニティイベント「 GCPUG Shonan vol.74」での発表資料です

中井悦司 / Etsuji Nakai Solutions Architect, Google Cloud $ who am i

Managed Service for Prometheus の発表 Blog 記事 3 https://cloud.google.com/blog/ja/products/operations/introducing-google-cloud-managed-service-for-prometheus

Monarch とは？ 4 https://research.google/pubs/pub50652/ ● Google が独自開発したモニタリングシステム専用の分散型の時系列データストア ● Google Cloud では、Cloud Monitoring のバックエンドとして使用 ○ Google 社内使用の Monarch とは別システム ● Google 社内では、YouTube、Gmail、Google Maps などのチームが共同で利用している ● アーキテクチャーと Google 社内での利用方法を解説した論文が公開されている ○ この後の内容（図表を含む）は、すべてこの論文の内容がベースになります。

Contents 5 ● Monarch のアーキテクチャー概要 ● データの書き込み処理 ● データの検索処理 ● 実環境における稼働状況（2019 年のデータ）

Monarch のアーキテクチャー概要

前提知識 7 ● Google 社内のアプリケーションは Borg の「ジョブ」として稼働する ● ゾーンごとに複数の Borg クラスターがある ● 1 つのジョブは、複数の「タスク」を起動してスケールアウトする ● イメージとしてはこんな感じ ○ Borg クラスター ＝ Kubernetes クラスター ○ ジョブ ＝ ReplicaSet ○ タスク ＝ Pod ○ ビルドラベル ＝ コンテナイメージの「イメージ ID」

Monarch のアーキテクチャー 8 ● 複数ゾーンに分散配置 ● ゾーン内の複数の「Leaf」にデータを分散保存

Monarch のデータモデル 9 ● データ全体は、「ターゲット」部分のフィールドと「メトリック」部分のフィールドで構成される ○ 「ターゲット」＝「データ収集対象のコンポーネント」（例： Borg 上のタスク） ○ 「メトリック」＝「収集するデータ項目」（例： API のコマンドごとのレイテンシー） ● 「ターゲット + メトリック」を改めて「キー」と「バリュー」に分割する ○ メトリックの最後のフィールド（時系列データ本体を含む部分）が「バリュー」 ○ 残りのフィールド全体が「キー」：キーごとに対応する時系列データが蓄積されていく ターゲット メトリック キー バリュー 時系列データ 例：Borg で稼働するタスクの APIごとのレイテンシーデータ

Monarch のデータモデル 10 ● ターゲットに含まれるロケーションフィールドでゾーンが決まる ● ターゲット全体の値でゾーン内の Leaf が決まる ○ ターゲット全体の辞書順のレンジでシャーディング ○ 連続するターゲット値を対象とした検索は、 1 つの Leaf で処理が完結する ロケーション ターゲット メトリック

タイムスタンプ共有によるデータ圧縮 11 ● 同じターゲットからのメトリックは、同じ Leaf に保存される ● 同じターゲットからのメトリックは、タイムスタンプの並びが同じになることが多い ○ 例：タスクが提供する API ごとのレイテンシー 　　→ タスクごとにレイテンシーを収集・送信するタイミングは同一になる ● ターゲットごとにタイムスタンプを共有して、効率的なデータ圧縮ができる（処理速度を優先して、差分保存、 連長圧縮（RLE）など軽量な圧縮技術を利用） ターゲットごとに タイムスタンプを共有

バリューのデータ型 12 ● boolean、int64、double、string、distribution、および、これらをまとめたタプル型 ● distribution（分布）型 ○ double 型の数値データをヒストグラムの形式でまとめたもので、値の範囲を区切ったバケットとそ れぞれのバケットに含まれるデータ数から構成される ○ 例：「過去 1 分間のレイテンシーの分布」を 1 分ごとの時系列データとして保存 ※ クエリーを用いて「過去 1 時間のレイテンシーの分布」の 1 分ごとの時系列データに変換するこ とも可能 ヒストグラムの例

クエリーの例 13 ● API レイテンシーのデータとビルドラベルのデータ を Join ● 以下の条件でフィルタリング ○ ジョブの実行ユーザーが「 monarch」 ○ ジョブ名が「mixer」で始まる ● ビルドラベルごとにレイテンシーの分布を集約 ○ group_by [label], aggregate(latency) ● 「過去 1 時間のレイテンシーの分布」を生成 ○ delta (1h) ※「特定のビルドのレイテンシーが大きく変化している場合、該当 のビルドに問題があるかも？」という想定でのクエリー

データの書き込み処理

データの書き込みの流れ 15 ● データ書き込みの流れ： クライアント → Ingestion Router → Leaf Router → Leaf ● ターゲットの辞書順でのレンジによるシャーディング ● 冗長化のために 3 つの Leaf に同じデータを保存 ロケーションフィールドで転送 先のゾーンを決定 ターゲットで 転送先の Leaf を決定

Leaf 上でのデータ書き込み 16 ● Leaf 上のデータは、すべてオンメモリーに保存 ○ 膨大なデータの高速な書き込みと検索に対応するため ● 受け取ったデータの情報は、追記型のリカバリーログファイルにも書き込み ● ただし、ログファイルへの書き込みは完全非同期で実施（書き込み完了を待たずに処理を継続） ○ リカバリーログファイルの書き込み先は、 Colossus の分散ファイルシステム ○ Colossus のモニタリングにも Monarch を使用している ○ Colossus の障害で Monarch が止まると Colossus のモニタリングができないので、リカバリーログ ファイルが書けなくても、 Monarch は処理を継続するように設計されている

データの動的再配置（リシャーディング） 17 ● Range Assigner は、各 Leaf が担当する（保存する）「ターゲットのレンジ」を割り当てる ● Leaf の負荷状況に応じて、動的に割り当てを変更する ● 例：Leaf A のターゲットを Leaf B に移動する場合 ○ 該当ターゲットを（一時的に） Leaf A と Leaf B の両方に割り当てる ○ Leaf B は（新規データを受け取りつつ）リカバリーログを用いて、過去のデータを復元する ○ 復元が終わったら、Leaf A に対する割り当てを解除する Leaf A Leaf B 時間 再配置開始 並列に データ保存 リカバリーログ から復元 ターゲットの レンジを割り当て

複数ターゲットのデータ集約 18 ● たとえば、ディスク I/O の回数は、個々のディスク装置が 1 つのキーを持つが、ディスク装置個別のデータを 収集するのは（データ量の観点で）無駄が多い。「クラスターに含まれるディスク全体の I/O 総数」が分かれ ば十分 ○ このような時は、複数ターゲットのデータ集約が設定できる ○ 典型的には、30 個程度のターゲットを集約するが、数百万ターゲットを集約することもある ● 個々のターゲットのクライアントは「一定期間（ T_D 秒間）の総数」を定期的に送信する ○ たとえば、「T_D = 10 秒」 ● データを受け取った Leaf は、同一のクラスターに属するデータを集約して保存する ○ T_D より長い期間（T_B 秒間）でデータを足し上げて保存する ○ たとえば、「T_D = 60 秒」

複数ターゲットのデータ集約 19 ● 「delta」が 1 回に送信されてくるデータ（ T_D 秒間の総数） ● 「bucket」が集約する時間範囲（ T_B 秒間の総数） ○ 「delta」の末尾の時刻によって、追加する「 bucket」を決定する ● 極端に遅延して到着したデータは「 bucket」に追加せずに破棄する ○ 「Admission Window」の範囲のデータを受け付ける ○ 「Admission Window」は「T_W 秒前〜現在時刻」の範囲を示す 時刻同期には TrueTime APIを使用 時間 現在時刻 データ送信時刻 Admission Window を過ぎた データ（遅延データ）は破棄

データの検索処理

検索処理の流れ 21 ● 検索処理は 2 種類 ○ アドホッククエリー：SRE やアナリストが対話的に検索文を入力 ○ 継続クエリー：事前に定義したクエリーを定期的に実行して、結果をビューに保存 ● 継続クエリーの目的 ○ ダッシュボードに表示するデータ（ビュー）を作成 ○ アラートを生成 ● 継続クエリーは、Root Evaluator もしくは Zone Evaluator が 定期的に実行して、結果をビューに保存 ○ 特定ゾーンのデータのみを検索することが分かってい る場合は、該当ゾーンの Zone Evaluator が担当 ● 複数の Evaluator があり、検索文全体のハッシュ値で負荷 分 散する

検索処理の流れ 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 の順に返信データが 集約されて検索が完了する

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 ● Zone Mixer からの応答が極端に遅延するゾーンは、検索結果に含めない ○ ユーザーには、特定ゾーンのデータが含まれていないことを示す警告が表示される ● 特定の Leaf からの応答が極端に遅延する場合、 Zone Mixer は（同じデータを持つ）他の Leaf にも並列し て検索を依頼する

実環境における稼働状況 （2019 年のデータ）

デプロイの規模（Google 社内利用の Monarch） 26 ● 38 のゾーンを使用 ○ Leaf が 100 未満のゾーン：5 ○ Leaf が 100〜1,000 のゾーン：16 ○ Leaf が 1,000〜10,000 のゾーン：11 ○ Leaf が 10,000 以上のゾーン：6 各コンポーネントが稼働するタスク（コンテナ）数

デプロイの規模（Google 社内利用の Monarch） 27

検索性能（レイテンシー） 28 ● Root Mixer を用いた検索 ○ 中央値：79ms ○ 99.9%-ile：6s ● ゾーンが大きい（検索対象の Leaf が多い）と検索は遅くなる ○ Leaf が 1,000 以上のゾーン での 99.9%-ile：50s

Thank You.