## Memo - 解説スライド： [Cloud Monitoring を支える 分散グローバルデータストア「Monarch」 - Speaker Deck](https://speakerdeck.com/enakai00/cloud-monitoring-wozhi-eru-fen-san-kuroharutetasutoa-monarch) - Googleの[[Time Series DataBase|TSDB]] ## ABSTRACT > Monarch is a globally-distributed in-memory time series database system in Google. Monarch runs as a multi-tenant service and is used mostly to monitor the availability, correct- ness, performance, load, and other aspects of billion-user- scale applications and systems at Google. Every second, the system ingests terabytes of time series data into memory and serves millions of queries. Monarch has a regionalized architecture for reliability and scalability, and global query and configuration planes that integrate the regions into a unified system. On top of its distributed architecture, Monarch has flexible configuration, an expressive relational data model, and powerful queries. This paper describes the structure of the system and the novel mechanisms that achieve a reliable and flexible unified system on a regionalized distributed architecture. We also share important lessons learned from a decade’s experience of developing and running Monarch as a service in Google. > （以下，DeepL翻訳） Monarchは、Googleのグローバルに分散されたインメモリ時系列データベースシステムです。Monarchはマルチテナントサービスとして動作し、主にGoogleの10億ユーザー規模のアプリケーションやシステムの可用性、正確性、パフォーマンス、負荷、その他の側面を監視するために使用されます。毎秒、システムはテラバイトの時系列データをメモリに取り込み、何百万ものクエリに対応しています。Monarchは、信頼性とスケーラビリティのために地域化されたアーキテクチャを持ち、地域を統合して統一されたシステムに統合するグローバルなクエリと構成プレーンを持っています。分散アーキテクチャの上に、Monarchは柔軟な構成、表現力豊かなリレーショナルデータモデル、そして強力なクエリを備えています。本論文では、システムの構造と、地域化された分散アーキテクチャ上で信頼性と柔軟性のある統一システムを実現するための斬新なメカニズムについて説明する。また、GoogleのサービスとしてMonarchを開発・運用してきた10年の経験から得られた重要な教訓を共有する。 ## 1. INTRODUCTION Google は大規模なコンピュータシステムの監視を必要としています。何千ものチームがグローバルなユーザー向けサービス（YouTube、GMail、Google Maps など）を実行していたり、そのようなサービスのためにハードウェアとソフトウェアのインフラストラクチャを提供しています（Spanner [13]、Borg [46]、F1 [40] など）。これらのチームは、世界中に分散している数十億という数の異種エンティティ（デバイス、仮想マシン、コンテナなど）の集合体を継続的に成長させ、変化させていくことを監視する必要があります。これらのエンティティのそれぞれからメトリクスを収集し、時系列で保存し、以下のようなユースケースをサポートするために照会する必要があります。(1) 単一のサービスが正常に動作していない場合の検出と警告 (2) サービスの状態と健全性を示すグラフのダッシュボードの表示 (3) 問題の特定とパフォーマンスとリソースの使用状況の調査のためのアドホックなクエリを実行する。 [[Borgmon]] [47] は、内部のアプリケーションやインフラストラクチャの動作を監視するための Google の初期のシステムでした。Borgmon は、メトリックな時系列の収集を第一級の機能とし、ユーザーが自分のニーズに合わせて監視データの分析をカスタマイズできるように、豊富なクエリ言語を提供することで、監視とアラートの考え方に革命をもたらしました。2004年から2014年の間に、監視トラフィックの増加に伴い、Borgmonのデプロイメントは大幅にスケールアップしましたが、その結果、以下のような制限がありました。 - Borgmonのアーキテクチャは、各チームがそれぞれのBorgmonインスタンスをセットアップして管理するという分散型の運用モデルを推奨しています。しかし、このため、Borgmonを確実に実行するために必要な専門知識やスタッフを持っていないチームが多く、運用上のオーバーヘッドが大きくなっていました。さらに、ユーザーは問題のトラブルシューティングのために、アプリケーションやインフラストラクチャの境界を越えてモニタリングデータを調べたり、相関付けたりする必要がありますが、これは多くの孤立したBorgmonインスタンスが存在する世界では難しいか、不可能です。 - Borgmonには測定値やメトリック値のスケマティック化(schematization)がないため、クエリのセマンティックな曖昧さが生じ、データ分析時のクエリ言語の表現力が制限されています。 - Borgmonは、高度な統計分析を可能にする強力なデータ構造である分布(ヒストグラムなど)の値の型をあまりサポートしていません(例えば、多くのサーバでのリクエスト遅延の99パーセンタイルを計算するなど)。 - Borgmonでは、複数のBorgmonインスタンスにまたがるグローバルサービスの大量の監視対象エンティティをユーザーが手動でシャードし、クエリ評価ツリーを設定する必要がありました。 これらの教訓を踏まえて、Monarch は Google の次世代の大規模監視システムとして誕生しました。Monarchは、トラフィックの継続的な成長に合わせて拡張できるように設計されており、拡大し続けるユースケースをサポートしています。すべてのチームに単一の統一されたサービスとしてマルチテナント監視を提供し、運用上の手間を最小限に抑えます。また、スキーマ化されたデータモデルにより、洗練されたクエリを容易にし、分布型の時系列を包括的にサポートします。Monarchは2010年から継続的に運用されており、世界規模での急速な成長に伴い、大量の時系列データの収集、整理、保存、クエリを行っています。現在、1ペタバイトに近い圧縮時系列データをメモリに保存し、毎秒テラバイトのデータを取り込み、毎秒数百万のクエリを提供しています。 本論文では、以下のような貢献をしている。 - マルチテナント型の惑星規模のインメモリ時系列データベースであるMonarchのアーキテクチャを紹介します。Monarchは多くの地域に展開されており、Googleのアプリケーションとインフラストラクチャの監視とアラートのニーズをサポートしています。Monarchは、より高い信頼性とスケーラビリティのために、モニタリング時系列データを地域ごとにインジェストして保存し、地理的に分散されたデータのグローバルなビューを提示するために、グローバルなクエリ・フェデレーション・レイヤーを装備し、統一された制御のためにグローバルな設定プレーンを提供します。Monarchはメモリにデータを格納し、永続記憶層での障害からデータを分離して可用性を向上させています（耐久性のためにログファイルによってもバックアップされており、長期的なリポジトリとなっています）。 - 我々は、時系列分析のためのMonarchの表現力豊かなクエリ言語の基礎となる、新しい、型が豊富なリレーショナルデータモデルを説明します。これにより、静的なクエリ分析と最適化を可能にしながら、リッチなデータ分析のための多様な操作を実行できるようになります。データモデルは、強力な統計データ分析のための分布のような洗練されたメトリック値タイプをサポートしています。我々の知る限りでは、Monarchは、1秒間に何百万ものクエリを提供しながら、ペタバイトのインメモリデータストレージという非常に大規模なスケールでデータを監視するためのリレーショナル時系列データモデルをサポートした初の惑星スケールのインメモリ時系列データベースです。 - 我々は、Monarchの(1)ロバストで低レイテンシのデータインジェスト、au-tomaticなロードバランシング、および大幅な効率化のためのコレクションアグリゲーションを提供するスケーラブルなコレクションパイプライン、(2)表現力豊かなクエリ言語、効率的な分散クエリ実行エンジン、パフォーマンスとスケーラビリティを大幅に向上させるコンパクトなインデックスサブシステムを使用する強力なクエリサブシステム、(3)ユーザーが時系列データの多くの側面を細かく制御できるグローバルなコンフィギュレーションプレーンについて概説している。 - 我々はMonarchのスケールを提示し、Monarchのスケーラビリティに対する重要な設計上の決定の影響を説明します。また、大規模なモニタリングシステムを構築・運用している読者の方々に興味を持っていただければと思い、Monarchの開発・運用・進化の中で得た教訓を共有しています。 本稿の残りの部分は以下のように構成されています。セクション２では、Monarch のシステムアーキテクチャと主要なコンポーネントについて説明します。セクション３では、データモデルについて説明します。第4節ではMonarchのデータ収集について、第5節ではクエリ言語、実行エンジン、インデックスを含むクエリサブシステムについて、第6節ではグローバル構成システムについて説明します。セクション7では、実験的にMonarchを評価します。第8節では、Monarchを関連する研究と比較します。第9節ではMonarchの開発と運用から得られた教訓を共有し、第10節で本稿を締めくくります。 ![[Pasted image 20220103180318.png]] ## 2.SYSTEM OVERVIEW Monarchの設計は、監視とアラートのための主な用途によって決定されます。第一に、Monarchは高い可用性とパーティション耐性[21, 8, 9]のために一貫性を容易に取引します。Spanner [13] のような一貫性の高いデータベースへの書き込みや読み込みは、長時間ブロックされる可能性があります。アラートを迅速に配信するために、Monarchは最新のデータをタイムリーに提供しなければなりません。ネットワークが分割された場合でも、Monarchはユーザーのモニタリングとアラートのニーズをサポートし続け、基礎となるデータが完全でないか、または矛盾している可能性があることを示すメカニズムを備えています。第二に、Monarchはアラートのクリティカルパスの依存性を低くしなければなりません。冗長性を最小限に抑えるために、Monarchは高いコストにもかかわらず、監視データをメモリに保存します。Bigtable [10]、Colossus ([36]、GFS [20]の後継である)、Spanner [13]、Blobstore [18]、F1 [40]など、Googleのストレージシステムのほとんどは、信頼性の高いモニタリングのためにMonarchに依存しています。その結果、グローバルな時系列データベースとしてMonarchを使用する非モニタリングアプリケーション（例：クォータサービス）は、一貫性の低下を受け入れざるを得なくなります。 図1に示されているように、モナークの主要な構成原理は、地域ゾーンでのローカルモニタリングとグローバルな管理とクエリの組み合わせです。ローカルモニタリングにより、Monarchはデータが収集された場所の近くにデータを保持することができ、伝送コスト、遅延、信頼性の問題を軽減し、ゾーン外のコンポーネントとは無関係にゾーン内でのモニタリングを可能にします。グローバル管理とクエリは、システム全体の統一されたビューを提示することで、グローバルシステムの監視をサポートします。 各Monarchゾーンは自律的で、ネットワークに強く接続された地域にあるクラスタの集合体、つまり独立した障害ドメインで構成されています。ゾーン内のコンポーネントは、信頼性のためにクラスタ間で複製されます。Monarchはデータをメモリに保存し、ハード依存性を回避することで、各ゾーンが他のゾーン、グローバルコンポーネント、および基礎となるストレージシステムの過渡的な停止時にも継続的に動作できるようにしています。Monarchのグローバルコンポーネントは地理的に複製され、最も近いレプリカを使用してゾーンコンポーネントと相互作用し、局所性を利用します。 Monarchのコンポーネントは、状態を保持するコンポーネント、データの取り込みに関与するコンポーネント、クエリの実行に関与するコンポーネントの3つのカテゴリに機能別に分けることができます。 状態を保持するコンポーネントは以下の通りです。 - Leaves: モニタリングデータをインメモリ時系列ストアに保存します。 - Recovery Logsは、リーフと同じモニタリングデータをディスク上に保存します。このデータは最終的に長期的な時系列リポジトリに書き換えられます(スペースの制約のため説明しません)。 - グローバル設定サーバとそのゾーンミラーは、Spanner [13]データベースに設定データを保持します。 データ取り込みコンポーネントは以下の通りです。 - Ingestion Routerは時系列キーの情報を使用してルーティングを決定し、適切なMonarchゾーンのLeaf Routerにデータをルーティングする。 - Leaf routers ゾーンに格納されるデータを受け入れ、格納のためにリーフにルーティングする。 - Range assignersはリーフへのデータの割り当てを管理し、ゾーン内のリーフ間で負荷のバランスをとる。 クエリの実行に関与するコンポーネントは以下の通りです。 - ミキサ： クエリをサブクエリに分割し、リーフにルーティングされて実行されるサブクエリに分割し、サブクエリの結果をマージします。クエリはルートレベル(ルートミキサによる)で発行される場合と、ゾーンレベル(ゾーンミキサによる)で発行される場合があります。ルートレベルのクエリには、ルートミキサとゾーンミキサの両方が関与します。 - インデックスサーバ 各ゾーンとリーフのデータをインデックス化し、分散クエリの実行をガイドするインデックスサーバ。 - ミキサーに定期的にスタンディングクエリ(セクション5.2参照)を発行し、その結果をリーフに書き戻す評価者。 リーフは3つの機能をすべてサポートしている点でユニークであることに注意してください。また、クエリ実行はゾーンレベルとグローバルレベルの両方で動作します。 ## 3. DATA MODEL 概念的には、Monarch は、モニタリングデータを時系列として、スケマティック化されたテーブルに格納します。各テーブルは、時系列のキーを形成する複数のキーカラムと、時系列のポイントの履歴を表す値カラムで構成されています。例として図2を参照してください。キー・カラムは、フィールドとも呼ばれ、次のように定義されているターゲットとメトリクスの 2 つのソースを持っています。 ### 3.1 Targets Monarchはターゲットを使用して、時系列を生成するプロセスやVMなどのソースエンティティ（または監視対象のエンティティ）と各時系列を関連付けます。各ターゲットは監視対象のエンティティを表し、ターゲットフィールド名と関連するフィールドタイプの順序づけられたセットを定義するtar-getスキーマに準拠しています。図2は、ComputeTaskという名前の一般的なターゲットスキーマを示している。各ComputeTaskターゲットは、4つのフィールド（user、job、cluster、および task num）を持つBorg [46]クラスタ内の実行中のタスクを識別している。 ローカリティのために、Monarchはデータが生成された場所の近くにデータを格納する。各ターゲットスキーマは、locationとしてアノテーションされた1つのフィールドを持つ。例えば、ComputeTaskのlocationフィールドはclusterである。各Borgクラスタは、1つの(通常は最も近い)Monarchゾーンにマップされる。セクション5.3で説明したように、ロケーションフィールドはクエリの実行を最適化するためにも使用される。 各ゾーン内では、Monarchは同じターゲットの時系列を同じリーフにまとめて格納します。これは、同じエンティティに由来しており、結合で一緒にクエリされる可能性が高いからです。Monarchはまた、[Sstart,Send]の形式でターゲットを不連続なターゲット範囲にグループ化し、SstartとSendはターゲットの開始と終了の文字列です。ターゲット文字列は、ターゲットスキーマ名とフィールド値を順番に連結してターゲットを表します。例えば、図2では、ComputeTask::sql-dba::db.server::aa::0876というターゲット文字列は、データベースサーバのBorgタスクを表しています。ターゲット範囲は辞書的なシャーディングとリーフ間の負荷分散のために使用されます(セクション4.2参照)。 ## 8. RELATED WORK 時系列データの爆発的な増加に伴い、その収集[35]、クラスタリング[34, 2]、圧縮[11, 33, 6]、モデリング[44, 23]、マイニング[17]、クエリ[4, 43]、検索[32, 38]、ストレージ[3]、および可視化[31]に関する研究が盛んに行われている[29, 5, 48]。最近の研究の多くは、ワイヤレスセンサーネットワーク[11, 33]やモノのインターネット[24]の制約のあるハードウェアでの時系列管理に焦点を当てていますが、リアルタイムでデータを保存したり問い合わせたりするクラウドスケールの時系列管理システム[37, 30]に関する研究はほとんどありません。 多くのオープンソース時系列データベース [5] があり、Graphite [16]、InfluxDB [27]、[[OpenTSDB]] [12]、[[Prometheus]] [39]、TSDB [15] が人気のあるデータベースである。これらは、データをセカンダリストレージ(ローカルまたはHBase [19, 27, 12]のような分散型)に格納するが、セカンダリストレージを使用することで、クリティカルな監視にはあまり適していない。これらは、Monarchゾーンと同様に水平方向にスケーリングすることで分散展開をサポートしますが、Monarchが提供するグローバルな構成管理やクエリの集約機能はありません。 Gorilla [37, 25]はFacebookのインメモリ時系列データベースです。Gorillaの時系列は、Monarchの構造化データモデルとは対照的に、文字列キーによって識別されます。Gorillaには表現力のあるクエリ言語がありません。Gorillaはディザスタリカバリのために地域をまたいでデータを複製し、ネットワーク・パーティションの間の可用性を制限しています。対照的にMonarchは、データの局所性のために近くのデータセンターにデータを複製します。Gorillaはまた、Monarchの惑星規模のクエリエンジンに相当するものや、フィールドヒントインデックスに基づいたクエリ実行のローカライズ、クエリのプッシュダウンなどの最適化機能を持っていません。Gorillaに欠けている他のMonarchの機能には、以下のようなものがあります。(1)例示的な分布などのリッチなデータ型、(2)辞書的シャーディングやコレクションアグリゲーションなどのコレクション最適化、(3)保持ポリシーのためのきめ細かな設定、(4)スタンディングクエリやアラートクエリなどです。 Monarchのコレクションアグリゲーション(セクション4.3)は、蓄積されたメトリクスがインジェストされている時系列をアグリゲーションすることで、 蓄積されたメトリクスのストレージコストを削減するもので、無線センサーネットワークで使用されているネットワーク内のアグリゲーション[42]に似ています。 ## 10. CONCLUSION Monarchは、何兆もの時系列を管理する、惑星規模のマルチテナント型インメモリ時系列データベースです。このデータベースは、多くの異なる地理的地域のデータセンターに分散して配置されています。Monarchは、自律的な地域監視サブシステムのアーキテクチャにより、この規模でも効率的かつ信頼性の高い運用が可能です。それは、リッチなデータ分析のための表現力豊かなクエリ言語のパワーを発揮しながら、効率的でスケーラブルなデータ保存を可能にする、新しい、型が豊富なリレーショナル時系列データモデルを採用しています。この大規模なスケールに対応するために、Monarchはデータ収集とクエリ実行の両方に様々な最適化技術を採用しています。データ収集については、信頼性と効率性を向上させるために、ゾーン内のロードバランシングとコレクションのアグリゲーションを実行します。クエリ実行では、各クエリを分散した階層的な方法で実行し、パフォーマンスとスループットを向上させるために積極的なフィルタリングと集約のプッシュダウンを実行し、コンパクトでありながら強力な分散インデックスを利用して効率的なデータの刈り込みを行います。 本番環境に最初に導入されて以来、Monarchは何年にもわたって急速に利用が拡大しています。現在、1秒間にテラバイトのデータを取り込み、1ペタバイト近くの高圧縮時系列データをメモリに保存し、1秒間に何百万ものクエリを処理しています。Monarchは、10億ユーザー規模のGoogleのモニタリングとアラートのニーズに対応する上で重要な役割を果たしています。また、アラートのための異常検知、継続的な統合と導入のためのカナリア分析、Googleクラスタ上でのリソース最適化のための自動タスクサイジングなど、多くのユースケースを実現する基盤となるインフラストラクチャレイヤーでもあります。