Monarch

Transcript

1. Monarch 2021.11.26@a2ito
2. 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
3. 参考 • Bigtable(2006) ◦ 被引用数: 7,472 • Chubby(2006) ◦ 被引用数: 1,492 • Megastore(2011) ◦ 被引用数: 981 • Dynamo(2007) ◦ 被引用数: 5,873 • Bitcoin(2008) ◦ 被引用数: 17,326 • Percolator(2010) ◦ 被引用数: 616
4. Overview GCP勉強会資料より 2021/11/9分
5. Overview • Google 社内のモニタリングのためのインメモリ時系列データベースシステム Monarch • テラバイト級の時系列データ、数百万のクエリを毎秒処理している • 既に10年間運用中
6. Overview • 社内のインフラ・アプリケーション監視のために、Borgmon を開発・利用していた ◦ 2004年-2014年にかけて急速に利用が拡大 • 利用拡大時に顕在化した Borgmon の課題 ◦ 各チームがインスタンスを設定・運用する設計 ▪ 運用上のオーバヘッドが発生 ▪ アプリケーションとインフラの境界を超えたクエリが書けない ◦ スキーマ化されていないため、クエリの表現力に制限あり ◦ 高度な統計分析がサポートされない ▪ 例：99パーセンタイルのレイテンシ ◦ 手動でシャード • これらの課題を解決するため、次世代監視システム Monarch を開発
7. System Design
8. System Overview • Monarch は主に監視とアラートのワークロードとして利用される ◦ ロックにより可用性やレイテンシが劣化することは許容できない ◦ 一貫性を犠牲にした AP システム • アラートへのクリティカルパスにおける依存性を最小化するためにメモリにデー タを保存 ◦ Bigtable, Colossus, Spanner, Blobstore, F1 などGoogleのストレージシステムのほとんどは Monarch に依存している ◦ Monarch 自身が Spanner や Colossus を利用しているため、アラートパスにおいて循環依存し ないようにする必要がある
9. Architecture (blue) persist state ⇒ステート永続化部 (green) execute queries ⇒クエリ実行部 (red) ingest data ⇒データ取り込み部
10. (blue) persist state • Leaves ◦ モニタリングデータをインメモリストアに保存 • Recovery logs ◦ Leaves と同じデータをディスク上に保存 • A global configuration server and its zonal mirrors ◦ 設定情報を Spanner に保存
11. (green) execute queries • Mixers ◦ クエリをサブクエリに分割し、 Leaves にルーティングして実行、結果をマージ • Index servers ◦ データのインデックスを管理 • Evaluators ◦ Mixer に対して定期的に Standing query を発行し、その結果を Leaves に書き込む
12. (red) ingest data • Ingestion routers ◦ データを適切な Leaf router にルーティング • Leaf routers ◦ Leaves に転送 • Range assigners ◦ Leaf 間の負荷をバランシングするために、 Leaves へのデータ割当を管理
13. Data Model • 時系列データをスキーマ化されたテーブルとして扱う • 各テーブルは複数の key/value をもつ ◦ Target Schema と Metrics Schema ◦ 同じターゲットの時系列を同じ Leaf に格納 • データが生成された場所の近くにデータを保存 ◦ location フィールドによって決定 • Metrics Schema ◦ distribution 型を選択可能 ▪ double 値の集合をバケットと呼ばれるサブセットで分割
14. ex) Data model • Target Schema: ComputeTask 4つの key カラムをもつ • Metric Schema: /rpc/server/latency 2つの key カラム、1つの value カラムを もつ
15. ex) Data model • ComputeTask ◦ Borg上のタスクを示す ◦ location フィールドは cluster
16. ex) Data model • ComputeTask::sql-dba::db.server::aa::0876 はデータベースサーバの特定の タスクを示す ◦ Leaves のシャーディングやロードバランスで使用
17. Metrics • /rpc/servers/latency の例 • バケットサイズ: 10ms
18. Data collection overview データ収集の4ステップ 1. クライアントは Ingestion Routers にデータを送信（ライブラリを使用） 2. Ingestion Routers は location フィールドに従ってゾーニング 3. Leaf Routers は Range Assigner に従って Leaves 全体にデータを分配する 4. 各 Leaf はインメモリストアとリカバリログにデータを書き込む（高度な最適化を 含む）
19. Data collection overview • 基本的には Colossus にリカバリログを書き込み、冗長性を担保する • 一方で、リカバリログ書き込みは ack を待たない ◦ ログ書き込みはベストエフォート ◦ 全ての Colossus インスタンスが利用できない場合でもシステムを継続する必要がある ◦ 3つのクラスタ間で非同期で複製
20. Intra-zone Load Balancing • Target schema のキーカラムのみを使用 ◦ 同一キーは同一Leafに格納される • Leaf にかかるCPU・メモリ負荷によってレンジ割当を動的に変更する ◦ 変更の間も、リカバリログを利用してシームレスにデータは収集される
21. Collection Aggregation • ユーザの書き込み通りにデータを保存するのは非常にコストが高い ◦ データの取り込み時にデータを集約する • デルタ時系列 ◦ ディスクIOPなどのメトリクスは、欠損に強い累積時系列を使用することをクライアントに推奨している • バケット（右上図） ◦ 期間 Ts で区切られたデータバケット ◦ Ts はユーザで設定可能 • アドミッションウィンドウ ◦ 入力を受付可能な枠 ◦ この枠よりも古いデータが到着しても拒否する ◦ Clock Skew 回避のため TrueTimeを利用
22. Scalable Queries • 0個以上の時系列テーブルを入力として、1個のテーブルを出力 • 例 ◦ バイナリバージョン毎に分類された一覧のタスクの RPCレイテンシ分布 ◦ RPCレイテンシ増を引き起こすリリースを検出
23. Scalable Queries • latency について user == “monarch” でフィルタされたデータを抽出 ◦ align によって、同じ開始時刻から一定の間隔でタイムスタンプを持つテーブルが生成される • ビルドラベルについて “monarch” と “mixer.*” でフィルタされたデータを抽出 • latency でポイント毎に集計
24. Scalable Queries • 2種類のクエリ ◦ ad hoc queries ▪ システム外ユーザから送られる ◦ standing queries ▪ マテビュー ▪ Monarchに保存される ▪ データの圧縮やアラート生成に利用される
25. Standing Queries • クエリの評価は、Global Evaluator または Zone Evaluator によって行われる ◦ 多くは Zone Evaluator によって評価される ◦ クエリの同一コピーを Zone Mixer に送信 ◦ 出力を自分のゾーンに書き込む
26. Query Pushdown • テーブル操作の評価を極力データソースに近い位置で行う ◦ 同時実行性向上、負荷分散 ◦ データ量の削減 • Pushdown to zone ◦ 同一 location フィールドの出力は、単一ゾーンの入力だけで処理が完結する • Pushdown to leaf ◦ leaf で完結するものは極力 leaf で実行
27. Field Hints Index • FHI: Field Hints Index を利用して、child へのクエリを送信する際に無関係な child への検索をスキップする • False positive(誤検出) が起こり得るが、結果の正しさに影響しない ◦ この child はその key 持ってるよ！⇒探してみたけど実はもってなかった。。。 • ストリーミングRPCによって継続的にインデックス情報を更新
28. Configuration • 分散型マルチテナントサービスとして、集中型の構成管理システムが必要 • 設定情報はグローバルな Spanner に保存される • 設定値は各ゾーンの設定ミラーに複製される ◦ ミラーから各コンポーネント上のメモリへ設定値をキャッシュ ◦ ミラーが使えなくなった場合は古い configuration でも動作するが、SREが監視している
29. Configuration • スキーマ ◦ 事前定義スキーマ ▪ ComputeTask や /rpc/server/latency など ▪ 一般的なワークロードのデータは自動収集可能 ◦ カスタムメトリクスももちろん可能 • サンプリング頻度、保存する期間、記録媒体、レプリカ数など細かく設定できる ◦ ストレージコスト削減 • Standing Query の設定 ◦ アラートの設定（しきい値、通知方法含む）も可能
30. Evaluation
31. System scale • Monarch の社内利用ユーザは 30,000人以上 • 38のゾーン、5リージョン • 40万タスク（重要なタスクのみ表に記載） ◦ ルートタスクの数はゾーンタスクよりも少ない（できるだけゾーンに寄せている）
32. System scale • Figure 8,9: Monarchの内部デプロイ数と消費バイト数 • Figure 10: クエリ数 • 2019年7月時点で、9,500億個の時系列データと750TBのデータを保持
33. System scale • Monarch へのデータ書き込み量/s • Monarchの社内展開において、2019-07時点で 2TB/s • 2018-07⇒2019-01 でほぼ2倍に成長 ◦ Collection Aggregation による
34. Scalable Queries • クエリのレイテンシ • ルートクエリは50%ile 79ms、99.9%ile 6s • ゾーンが小さいほどクエリのレイテンシが低い • 多くのユーザは高コストなクエリを投げがちなので、これらのメトリクスに自動ス タンディングクエリを設定 ◦ 「全タスクの latency を集計！」
35. Scalable Queries • クエリ最適化のパフォーマンス影響 • Query Pushdown と FHI を有効にすると、6.73s で実行可能
36. Lessons Learned • 辞書式順序シャーディング ◦ Monarch ゾーンを数万のリーフに拡張 • プッシュ型のデータ収集 ◦ 堅牢性を高めると同時にアーキテクチャを簡素化する • スキーマ化されたデータモデル ◦ 堅牢性を高めパフォーマンスを向上 ◦ クエリを検証・最適化できる • 継続的なスケーリング ◦ Index Server や Collection Aggregation は初期設計後に追加導入 • マルチテナント型 ◦ 異なるワークロードが共存することはチャレンジング ◦ isolation や throttling などの機能が必要 ◦ 継続的に改善し続けている
37. まとめ • Planet-scale のマルチテナント型インメモリ時系列データベース Monarch ◦ 多くのリージョン・ゾーンに配置されている ◦ グローバルな configuration 、クエリプレーン ◦ 様々な最適化技術を適用 • 10億ユーザ規模のGoogle内システムを支える不可欠な存在
38. Thank you!