Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Cloud Monitoring を支える 分散グローバルデータストア「Monarch」
Etsuji Nakai
April 13, 2022
Technology
2
820
Cloud Monitoring を支える 分散グローバルデータストア「Monarch」
「GCPUG Shonan vol.74」で使用予定のスライドです。
https://gcpug-shonan.connpass.com/event/243711/
Etsuji Nakai
April 13, 2022
Tweet
Share
More Decks by Etsuji Nakai
See All by Etsuji Nakai
強化学習「理論」入門
enakai00
3
2.1k
DCGAN - How does it work?
enakai00
0
51
機械学習&ディープラーニング入門
enakai00
0
150
TensorFlow 2 : Keras 入門&最新(?)ライブラリー紹介
enakai00
3
830
60分で学ぶ「強化学習理論入門」
enakai00
0
670
ルベーグ測度の定義を整理する
enakai00
0
190
Reinforcement Learning Second edition - Notes on DQN
enakai00
0
58
量子力学入門(1)
enakai00
4
2.5k
機械学習入門 (in JSL)
enakai00
0
3.6k
Other Decks in Technology
See All in Technology
ZephyrRTOSのLongan Nanoへの移植
tokitahiroshi
0
110
Apa itu DevOps & Kenapa perlu belajar DevOps?
dicodingevent
0
120
The application of formal methods in Kafka reliability engineering
line_developers
PRO
1
210
データ分析で切り拓け! エンジニアとしてのデータ分析職キャリア戦略
ksnt
0
190
The Fractal Geometry of Software Design
vladikk
1
1.4k
Target SDK Versionを上げない Notification runtime permission対応
napplecomputer
0
150
誰が正解を知っているのか / Who knows the right answer
takaking22
1
250
さいきんのRaspberry Pi。 / osc22do-rpi
akkiesoft
6
5.4k
Retca Cloud
bau
0
580
QiitaConference2022
fuwasegu
0
210
DOM Invader - prototype pollution対応の衝撃 - / DOM Invader - prototype pollution
okuken
0
170
Meet passkeys
satotakeshi
1
130
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
32
11k
From Idea to $5000 a Month in 5 Months
shpigford
373
44k
Faster Mobile Websites
deanohume
294
28k
Learning to Love Humans: Emotional Interface Design
aarron
261
37k
Three Pipe Problems
jasonvnalue
89
8.7k
Ruby is Unlike a Banana
tanoku
91
9.2k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
37
3.3k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
224
49k
Pencils Down: Stop Designing & Start Developing
hursman
112
9.8k
Practical Orchestrator
shlominoach
178
8.6k
Build your cross-platform service in a week with App Engine
jlugia
219
17k
Streamline your AJAX requests with AmplifyJS and jQuery
dougneiner
127
8.5k
Transcript
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.