Uberが独自の大規模メトリクスプラットフォームM3をオープンソースとして公開

Uberのエンジニアリングチームは、社内で数年にわたって運用してきたMetricsプラットフォームのM3を、オープンソースとしてリリースした。このプラットフォームは、Graphiteベースのシステムをリプレースするために開発されたもので、クラスタ管理、アグリゲーション、コレクション、ストレージ管理、分散時系列データベース(TSDB)に加えて、独自の問合せ言語であるM3QLを備えたクエリエンジンを提供する。

同社の従来のメトリクス収集および監視システムはGraphiteをベースとしたもので、アラート用のNagiosとダッシュボードであるGrafanaとともに共有Carbonクラスタ上で運用されていたが、レジリエンシとクラスタリング機能の不足、Carbonクラスタ拡張に伴う運用コストの高さ、レプリケーション機能の欠如によって各ノードが単一障害点となっていること、などの問題を抱えていた。新たなメトリクスシステムであるM3は、これらの問題から生まれたものだ。スケーラビリティ、データセンタ全体を対象とするグローバルで応答性の高いクエリに加えて、新たなシステムでは、メトリクスのタグ付けと、StatsDとGraphiteフォーマットでメトリクスを発行するサービスとの後方互換性の維持を目標とした。同社のスタッフソフトウェアエンジニアであるRob Skillington氏が先日の記事で、M3のアーキテクチャについて説明している。M3は現在、66億の時系列データを保有、毎秒5億件のメトリクスを集計、毎秒2,000万件のメトリクスを格納している。

初期バージョンのM3には、アグリゲーション用のstatsiteやストレージ用のCassandra、インデクス生成用のElasticsearchなど、オープンソースコンポーネントが使用されていたが、運用上のオーバーヘッドの増大や新機能への要求といった理由から、段階的に独自の実装に置き換えられた。Uber社内ではPrometheusが広範に使用されているため、リモートストレージのバックエンドとしてPrometheusを統合するように構築されている。

Prometheusとの統合はサイドカーコンポーネントを介して行う。サイドカーコンポーネントがローカルリージョンのM3DBインスタンスに書き込みを行い、“ローカルリージョンのM3DB(ストレージエンジン)インスタンスからの読み出しを調定するリージョナルコーディネータ群”にクエリを展開する。このモデルの動作方法は、Prometheusの拡張版で、クラスタ間フェデレーションや無制限のストレージ、クラスタを越えたグローバルクエリといった機能を提供するThanosに近い。UberチームがThanosを選択しなかった理由はいくつかあるが、最も大きなものは、ローカルに置かれていないメトリクスのレイテンシが大きいことだ。ThanosはAWS S3からデータを取得してキャッシュするため、それに関わるレイテンシとディスク消費量が理由で、Uberのレイテンシ要件と大量のデータには適用できなかった。

M3のクエリエンジンは、リージョン間のレプリケーションを使用せずに、すべてのメトリクスに対する単一のグローバルビューを提供する。メトリクスはローカルリージョンのM3DBインスタンスに記録され、レプリケーションはリージョンに対してローカルである。クエリはリージョン内のローカルインスタンスと合わせて、メトリクスの格納されているリモートリージョンのコーディネータにも送られる。結果の集約はローカルで行われるが、将来的には、リモートのコーディネータでクエリ集約を行うようにする計画である。

M3ではCarbonと同じように、ユーザがメトリクスごとに保存期間と粒度を指定することができる。M3のストレージエンジンは各メトリクスを、リージョン内で3つのレプリカに複製する。ディスク容量削減のため、データは独自の圧縮アルゴリズムを使って圧縮される。時系列データベースは通常、既存の小さなデータブロックをより大きなデータブロックに書き直し、再構築してクエリパフォーマンスを向上させるための圧縮機能を備えているが、M3DBは、可能であれば圧縮を避けて、ホストリソースの並列書き込みを活用することで、安定した書き込み/読み込みレイテンシを提供する。

Skillington氏は記事で、“M3DB自体はデータの埋め戻し(backfill)や、あるいは時間ウィンドウのインデックスファイルと組み合わせるのが適切な場合など、絶対的に必要な場合にのみ、時系列データの圧縮を行います”、と説明している。メトリクスのダウンサンプリングは入力時に、ストリーミングモデルを使用して行われる。

M3独自の問合せ言語であるM3QLは、PromQLでは使用できない機能のために、Uber社内で使用されている。処理可能なメトリクスのカーディナリティ(cardinality)には制限があるが、これはストレージよりもクエリ自体に起因するものだ。M3ストレージは、Bloomフィルタとメモリマップファイル内のインデクスを使用したアクセス時間の最適化も行う。Bloomフィルタは、対象がセット内に存在するかどうかを判断するために使用されるものだが、M3では、クエリ対象の連続体をディスクから取得する必要があるかどうかを判断するために用いている。チームは現在、M3をKubernetes上で運用するためのサポート追加に取り組んでいる。

M3はGo言語で記述されており、Githubで入手可能だ。