# Flipkart Scales Prometheus to 80 Million Time Series with Hierarchical Federation **InfoQ, 2025-10-18**(著者: Craig Risi) | [[Flipkart]] エンジニアによる[事例記事](https://kapillamba4.medium.com/hierarchical-federation-in-prometheus-managing-millions-of-metrics-cleanly-8d8bac940ff3)を InfoQ がまとめた記事。API Gateway 層で発生した8000万時系列規模の [[Prometheus]] 監視を、**階層フェデレーション(hierarchical federation)**で捌いた事例と、代替アーキテクチャとの比較を扱う。 ## 課題 Flipkart の API Gateway 層は約2,000インスタンス × 各インスタンス約4万メトリクスで、合計約8000万時系列が同時に発生していた。当初使っていた StatsD は長時間クエリでストレージを詰まらせ、履歴分析が実用に耐えなかった。高次元クエリと Kubernetes・exporter エコシステムとの親和性から Prometheus へ移行した。 ## 階層フェデレーションの構造 1. **ローカル層**: 個々の Prometheus サーバーがサービスのメトリクスを ingest し、recording rule を適用して不安定な高カーディナリティ次元(instance ラベル等)を落とす。 2. **集約**: recording rule で instance のような不安定な次元を除去しつつ、クラスタレベルのデータは保持する。 3. **フェデレーション層**: ローカルサーバーが `/federate` エンドポイントで集約済みメトリクスを公開し、上位(フェデレーション)サーバーがそれをスクレイプする。 4. **中央ストレージ**: 集約済みデータが長期ストレージとダッシュボードに供給される。 追加の削減策として、service/cluster のような安定次元では instance ラベルを落とし、p95/p99 のようなインスタンス単位パーセンタイルの代わりに平均・最大・最小の要約統計を公開した。結果として8000万の生系列が数万のクラスタレベルメトリクスへ圧縮された。 ## トレードオフ 階層フェデレーションは大規模デプロイに向く一方、クラスタ横断でインスタンス単位の異常を特定したい場合には不向きになる。記事は生メトリクスをそのまま上位にミラーすることを戒め、フィルタリングと選択的フェデレーションを推奨している。 ## 代替アーキテクチャとの比較 | アーキテクチャ | 特徴 | Flipkart 方式との対比 | |---|---|---| | Thanos | 各 Prometheus にサイドカーを付与しオブジェクトストレージ(S3/GCS)へアップロード、中央 Querier がラベル削除なしにクラスタ横断クエリを提供 | グローバルな可視性は強いが追加コンポーネント・運用負荷が大きい | | Cortex / Grafana Mimir | distributor/ingester/querier のマイクロサービスで構成されたマルチテナント分散TSDB。consistent hashing とオブジェクトストアで自動シャーディング | 手動設定は少ないが分散システムの専門知識が必要 | | VictoriaMetrics | Prometheus remote write/read API 互換。単一バイナリで数千万メトリクス規模まで運用可能 | 中間的選択肢。デプロイの容易さと長期保持効率を優先するチーム向け | Flipkart が階層フェデレーションを選んだ理由は、Prometheus をほぼステートレスに保てること、オブジェクトストレージ等の外部依存を避けられること、ネイティブなクエリセマンティクスを維持できることにある。記事は、今後さらにスケールする場合はフェデレーションと長期バックエンド(Thanos や VictoriaMetrics)を併用するハイブリッド構成が保持期間・クラスタ横断クエリ・耐障害性をさらに向上させうると付言している。 ## 関連 - エンティティ: [[Flipkart]] / [[Prometheus]] - コンセプト: [[カーディナリティ]] / [[時系列データベース]]