Monarch - Speaker Deck

Slide 1

Slide 1 text

Monarch 2021.11.26@a2ito

Slide 2

Slide 2 text

Publication Monarch: Google’s Planet-Scale In-Memory Time Series Database Colin Adams, Luis Alonso, Benjamin Atkin, John Banning, Sumeer Bhola, Rick Buskens, Ming Chen, Xi Chen, Yoo Chung, Qin Jia, Nick Sakharov, George Talbot, Adam Tart, Nick Taylor International Conference on Very Large Data Bases, VLDB (2020) 被引用数: 2

Slide 3

Slide 3 text

参考 ● Bigtable(2006) ○ 被引用数: 7,472 ● Chubby(2006) ○ 被引用数: 1,492 ● Megastore(2011) ○ 被引用数: 981 ● Dynamo(2007) ○ 被引用数: 5,873 ● Bitcoin(2008) ○ 被引用数: 17,326 ● Percolator(2010) ○ 被引用数: 616

Slide 4

Slide 4 text

Overview GCP勉強会資料より 2021/11/9分

Slide 5

Slide 5 text

Overview ● Google 社内のモニタリングのためのインメモリ時系列データベースシステム Monarch ● テラバイト級の時系列データ、数百万のクエリを毎秒処理している ● 既に10年間運用中

Slide 6

Slide 6 text

Overview ● 社内のインフラ・アプリケーション監視のために、Borgmon を開発・利用していた ○ 2004年-2014年にかけて急速に利用が拡大 ● 利用拡大時に顕在化した Borgmon の課題 ○ 各チームがインスタンスを設定・運用する設計 ■ 運用上のオーバヘッドが発生 ■ アプリケーションとインフラの境界を超えたクエリが書けない ○ スキーマ化されていないため、クエリの表現力に制限あり ○ 高度な統計分析がサポートされない ■ 例：99パーセンタイルのレイテンシ ○ 手動でシャード ● これらの課題を解決するため、次世代監視システム Monarch を開発

Slide 7

Slide 7 text

System Design

Slide 8

Slide 8 text

System Overview ● Monarch は主に監視とアラートのワークロードとして利用される ○ ロックにより可用性やレイテンシが劣化することは許容できない ○ 一貫性を犠牲にした AP システム ● アラートへのクリティカルパスにおける依存性を最小化するためにメモリにデータを保存 ○ Bigtable, Colossus, Spanner, Blobstore, F1 などGoogleのストレージシステムのほとんどは Monarch に依存している ○ Monarch 自身が Spanner や Colossus を利用しているため、アラートパスにおいて循環依存しないようにする必要がある

Slide 9

Slide 9 text

Architecture (blue) persist state ⇒ステート永続化部 (green) execute queries ⇒クエリ実行部 (red) ingest data ⇒データ取り込み部

Slide 10

Slide 10 text

(blue) persist state ● Leaves ○ モニタリングデータをインメモリストアに保存 ● Recovery logs ○ Leaves と同じデータをディスク上に保存 ● A global conﬁguration server and its zonal mirrors ○ 設定情報を Spanner に保存

Slide 11

Slide 11 text

(green) execute queries ● Mixers ○ クエリをサブクエリに分割し、 Leaves にルーティングして実行、結果をマージ ● Index servers ○ データのインデックスを管理 ● Evaluators ○ Mixer に対して定期的に Standing query を発行し、その結果を Leaves に書き込む

Slide 12

Slide 12 text

(red) ingest data ● Ingestion routers ○ データを適切な Leaf router にルーティング ● Leaf routers ○ Leaves に転送 ● Range assigners ○ Leaf 間の負荷をバランシングするために、 Leaves へのデータ割当を管理

Slide 13

Slide 13 text

Data Model ● 時系列データをスキーマ化されたテーブルとして扱う ● 各テーブルは複数の key/value をもつ ○ Target Schema と Metrics Schema ○ 同じターゲットの時系列を同じ Leaf に格納 ● データが生成された場所の近くにデータを保存 ○ location フィールドによって決定 ● Metrics Schema ○ distribution 型を選択可能 ■ double 値の集合をバケットと呼ばれるサブセットで分割

Slide 14

Slide 14 text

ex) Data model ● Target Schema: ComputeTask 4つの key カラムをもつ ● Metric Schema: /rpc/server/latency 2つの key カラム、1つの value カラムをもつ

Slide 15

Slide 15 text

ex) Data model ● ComputeTask ○ Borg上のタスクを示す ○ location フィールドは cluster

Slide 16

Slide 16 text

ex) Data model ● ComputeTask::sql-dba::db.server::aa::0876 はデータベースサーバの特定のタスクを示す ○ Leaves のシャーディングやロードバランスで使用

Slide 17

Slide 17 text

Metrics ● /rpc/servers/latency の例 ● バケットサイズ: 10ms

Slide 18

Slide 18 text

Data collection overview データ収集の4ステップ 1. クライアントは Ingestion Routers にデータを送信（ライブラリを使用） 2. Ingestion Routers は location フィールドに従ってゾーニング 3. Leaf Routers は Range Assigner に従って Leaves 全体にデータを分配する 4. 各 Leaf はインメモリストアとリカバリログにデータを書き込む（高度な最適化を含む）

Slide 19

Slide 19 text

Data collection overview ● 基本的には Colossus にリカバリログを書き込み、冗長性を担保する ● 一方で、リカバリログ書き込みは ack を待たない ○ ログ書き込みはベストエフォート ○ 全ての Colossus インスタンスが利用できない場合でもシステムを継続する必要がある ○ 3つのクラスタ間で非同期で複製

Slide 20

Slide 20 text

Intra-zone Load Balancing ● Target schema のキーカラムのみを使用 ○ 同一キーは同一Leafに格納される ● Leaf にかかるCPU・メモリ負荷によってレンジ割当を動的に変更する ○ 変更の間も、リカバリログを利用してシームレスにデータは収集される

Slide 21

Slide 21 text

Collection Aggregation ● ユーザの書き込み通りにデータを保存するのは非常にコストが高い ○ データの取り込み時にデータを集約する ● デルタ時系列 ○ ディスクIOPなどのメトリクスは、欠損に強い累積時系列を使用することをクライアントに推奨している ● バケット（右上図） ○ 期間 Ts で区切られたデータバケット ○ Ts はユーザで設定可能 ● アドミッションウィンドウ ○ 入力を受付可能な枠 ○ この枠よりも古いデータが到着しても拒否する ○ Clock Skew 回避のため TrueTimeを利用

Slide 22

Slide 22 text

Scalable Queries ● 0個以上の時系列テーブルを入力として、1個のテーブルを出力 ● 例 ○ バイナリバージョン毎に分類された一覧のタスクの RPCレイテンシ分布 ○ RPCレイテンシ増を引き起こすリリースを検出

Slide 23

Slide 23 text

Scalable Queries ● latency について user == “monarch” でフィルタされたデータを抽出 ○ align によって、同じ開始時刻から一定の間隔でタイムスタンプを持つテーブルが生成される ● ビルドラベルについて “monarch” と “mixer.*” でフィルタされたデータを抽出 ● latency でポイント毎に集計

Slide 24

Slide 24 text

Scalable Queries ● 2種類のクエリ ○ ad hoc queries ■ システム外ユーザから送られる ○ standing queries ■ マテビュー ■ Monarchに保存される ■ データの圧縮やアラート生成に利用される

Slide 25

Slide 25 text

Standing Queries ● クエリの評価は、Global Evaluator または Zone Evaluator によって行われる ○ 多くは Zone Evaluator によって評価される ○ クエリの同一コピーを Zone Mixer に送信 ○ 出力を自分のゾーンに書き込む

Slide 26

Slide 26 text

Query Pushdown ● テーブル操作の評価を極力データソースに近い位置で行う ○ 同時実行性向上、負荷分散 ○ データ量の削減 ● Pushdown to zone ○ 同一 location フィールドの出力は、単一ゾーンの入力だけで処理が完結する ● Pushdown to leaf ○ leaf で完結するものは極力 leaf で実行

Slide 27

Slide 27 text

Field Hints Index ● FHI: Field Hints Index を利用して、child へのクエリを送信する際に無関係な child への検索をスキップする ● False positive(誤検出) が起こり得るが、結果の正しさに影響しない ○ この child はその key 持ってるよ！⇒探してみたけど実はもってなかった。。。 ● ストリーミングRPCによって継続的にインデックス情報を更新

Slide 28

Slide 28 text

Conﬁguration ● 分散型マルチテナントサービスとして、集中型の構成管理システムが必要 ● 設定情報はグローバルな Spanner に保存される ● 設定値は各ゾーンの設定ミラーに複製される ○ ミラーから各コンポーネント上のメモリへ設定値をキャッシュ ○ ミラーが使えなくなった場合は古い conﬁguration でも動作するが、SREが監視している

Slide 29

Slide 29 text

Conﬁguration ● スキーマ ○ 事前定義スキーマ ■ ComputeTask や /rpc/server/latency など ■ 一般的なワークロードのデータは自動収集可能 ○ カスタムメトリクスももちろん可能 ● サンプリング頻度、保存する期間、記録媒体、レプリカ数など細かく設定できる ○ ストレージコスト削減 ● Standing Query の設定 ○ アラートの設定（しきい値、通知方法含む）も可能

Slide 30

Slide 30 text

Evaluation

Slide 31

Slide 31 text

System scale ● Monarch の社内利用ユーザは 30,000人以上 ● 38のゾーン、5リージョン ● 40万タスク（重要なタスクのみ表に記載） ○ ルートタスクの数はゾーンタスクよりも少ない（できるだけゾーンに寄せている）

Slide 32

Slide 32 text

System scale ● Figure 8,9: Monarchの内部デプロイ数と消費バイト数 ● Figure 10: クエリ数 ● 2019年7月時点で、9,500億個の時系列データと750TBのデータを保持

Slide 33

Slide 33 text

System scale ● Monarch へのデータ書き込み量/s ● Monarchの社内展開において、2019-07時点で 2TB/s ● 2018-07⇒2019-01 でほぼ2倍に成長 ○ Collection Aggregation による

Slide 34

Slide 34 text

Scalable Queries ● クエリのレイテンシ ● ルートクエリは50%ile 79ms、99.9%ile 6s ● ゾーンが小さいほどクエリのレイテンシが低い ● 多くのユーザは高コストなクエリを投げがちなので、これらのメトリクスに自動スタンディングクエリを設定 ○ 「全タスクの latency を集計！」

Slide 35

Slide 35 text

Scalable Queries ● クエリ最適化のパフォーマンス影響 ● Query Pushdown と FHI を有効にすると、6.73s で実行可能

Slide 36

Slide 36 text

Lessons Learned ● 辞書式順序シャーディング ○ Monarch ゾーンを数万のリーフに拡張 ● プッシュ型のデータ収集 ○ 堅牢性を高めると同時にアーキテクチャを簡素化する ● スキーマ化されたデータモデル ○ 堅牢性を高めパフォーマンスを向上 ○ クエリを検証・最適化できる ● 継続的なスケーリング ○ Index Server や Collection Aggregation は初期設計後に追加導入 ● マルチテナント型 ○ 異なるワークロードが共存することはチャレンジング ○ isolation や throttling などの機能が必要 ○ 継続的に改善し続けている

Slide 37

Slide 37 text

まとめ ● Planet-scale のマルチテナント型インメモリ時系列データベース Monarch ○ 多くのリージョン・ゾーンに配置されている ○ グローバルな conﬁguration 、クエリプレーン ○ 様々な最適化技術を適用 ● 10億ユーザ規模のGoogle内システムを支える不可欠な存在

Slide 38

Slide 38 text

Thank you!