Grafana MimirでPrometheusの長期保存をスケールさせる：単一バイナリから1億時系列まで

Prometheusの長期保存が抱える三つの問題

Prometheusは優れた監視ツールですが、データの長期保存には向いていません。デフォルトのローカルストレージはノードのディスクに依存し、保持期間を延ばすと容量とコストが膨らみます。また、単一インスタンスではスケールに限界があり、複数インスタンスを運用すると、クエリを横断して集計するのが難しくなります。Grafana Mimirは、この三つの問題を一つのシステムで解決しようとするプロジェクトです。READMEには、水平スケーラブルなアーキテクチャで「1 billion active time series」を処理したという内部テストの結果が記載されています。ただし、これはあくまで内部テストの数字であり、実環境での性能は構成やデータ特性に依存します。

単一バイナリから始めるmonolithic mode

Grafana Mimirの特徴の一つは、導入の容易さです。READMEによると、monolithic modeを使えば「one binary and no additional dependencies」で起動できます。これは、分散構成で必要となるコンポーネントを単一プロセスにまとめたモードで、評価や小規模運用に適しています。一方で、本番環境では「best-practice dashboards, alerts, and runbooks」が同梱されており、これらを使ってシステムの健全性を監視できるとされています。ただし、monolithic modeがどの程度のスケールまで耐えるのかは明記されておらず、大規模な時系列数では分散構成を検討する必要があるでしょう。

オブジェクトストレージを基盤とした長期保存の仕組み

Grafana Mimirは、長期データの保存先としてオブジェクトストレージを利用します。対応しているのは、AWS S3、Google Cloud Storage、Azure Blob Storage、OpenStack Swift、そして任意のS3互換ストレージです。この設計により、コスト効率が高く耐久性のあるストレージを利用できるとREADMEは説明しています。具体的なデータフローはREADMEからは詳細が不明ですが、オブジェクトストレージを中心に、インジェスト、クエリ、コンパクションといった処理が行われると推測できます。ただし、オブジェクトストレージのレイテンシはローカルディスクより高いため、クエリ性能を維持するにはキャッシュやインデックスの設計が重要になるでしょう。その点はドキュメントを参照する必要があります。

マルチテナントと高可用性の実装

Grafana Mimirは「natively multi-tenant」であり、独立したチームやビジネスユニットのデータを分離し、同じクラスタを共有できます。これにより、複数のPrometheusインスタンスからのメトリクスを集約し、グローバルな視点でのクエリが可能です。また、高可用性については、受信メトリクスをレプリケーションし、マシン障害時でもデータ損失を防ぐとされています。さらに、水平スケーラブルなアーキテクチャにより、再起動やアップグレード、ダウングレードをゼロダウンタイムで行えるとしています。ただし、これらの主張は設計上のものであり、実際の可用性はネットワークやストレージの冗長性にも依存します。

導入の手順と移行パス

Grafana Mimirの導入は、公式の「Get started guide」に従うのが基本です。READMEでは、本番環境の前に「An overview of Grafana Mimir's architecture」「Configure Grafana Mimir」「Run Grafana Mimir in production」の3点を読むよう推奨しています。具体的なコマンドや設定ファイルの例はREADMEには記載されておらず、ドキュメントを参照する必要があります。移行については、ThanosやPrometheusからの移行、Cortexからの移行のための専用ドキュメントが用意されています。これは、既存のPrometheus長期保存ソリューションからの乗り換えを意識した設計と言えるでしょう。

ライセンスと運用コストの現実

Grafana MimirはAGPL-3.0-onlyで配布されています。これは、ネットワーク経由でサービスを提供する場合に、そのソースコードの開示義務が生じる可能性があるライセンスです。商用製品に組み込む場合や、サービスとして提供する場合は、法的な確認が必要です。運用コストについては、monolithic modeで始められるものの、本番環境では分散構成とオブジェクトストレージの管理が発生します。READMEにはベストプラクティスのダッシュボードやアラートが同梱されているとあり、運用監視の初期コストを下げられるでしょう。ただし、長期的なメンテナンスコストは、時系列の規模やクエリの複雑さに依存します。

ThanosやCortexとの比較で見えるGrafana Mimirの立ち位置

Grafana Mimirは、ThanosやCortexの後継として位置づけられています。READMEでは、これらのプロジェクトからの移行パスを明示しており、特にCortexはGrafana Mimirの直接の前身と言えます。ThanosはPrometheusのサイドカーとして動作し、オブジェクトストレージへのアーカイブを提供しますが、Mimirはより統合された分散アーキテクチャを持ちます。一方、CortexはMimirの基盤となったプロジェクトで、Mimirはその運用性とスケーラビリティを改善したものと言えるでしょう。選択肢を検討する際は、既存のインフラとの親和性と、必要なスケールを考慮する必要があります。

編集部の結論

Grafana Mimirは、複数Prometheusインスタンスのメトリクスを統合し、長期保存とマルチテナント共有を求める中規模以上のチームに適しています。一方、単一ノードで十分な小規模環境や、AGPL-3.0の条件を受け入れられない組織には不向きです。導入前に、オブジェクトストレージの互換性と、monolithic modeでの性能限界を実際のデータ量で検証してください。また、既存のThanosやCortexからの移行パスが提供されているため、移行計画は公式ドキュメントを参照するのが確実です。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes