巨大時系列の墓場を超えて：Grafana Mimirで数百万シリーズを支配する極限アーキテクチャ論
Prometheusの単体運用に限界を感じ、「ストレージが溢れた」「クエリがタイムアウトする」「再起動のたびにインデックス再構築で数時間溶ける」といった悪夢にうなされているのであれば、あなたは正しい道に立っている。
Grafana Mimirは、単なるPrometheusのバックエンドではない。これは、「高基数（High Cardinality）の暴力」を、分散アーキテクチャという理屈でねじ伏せるための兵器だ。本稿では、数百万アクティブシリーズを常時飲み込み、S3をバックエンドに据えてコストを最適化するための、現場の血が通った設計指針を授ける。
—
1. Mimirの解剖：なぜ「バラバラにする」ことが正義なのか
Mimirは、Prometheusが抱える「計算・保存・クエリ」の三位一体構造を、マイクロサービスとして完全に分解した。大規模環境において、これらを分離するのは単なる流行ではない。「ボトルネックがどこにあるかを完全に制御するため」だ。
- Distributor: フロントエンドの門番。受信したサンプルをバリデーションし、ハッシュリングに基づいてIngesterへルーティングする。ここが詰まるならPodの横スケールではなく、ネットワーク帯域と同時接続数（`gRPC`のストリーム多重化）を疑え。
- Ingester: メモリ上の書き込みバッファ。ここが「今、何が起きているか」の最前線だ。長期保存の要は、こいつのメモリをいかに効率的に利用し、素早くBlocksとして吐き出させるかにある。
- Store Gateway: オブジェクトストレージ上のBlocksをオンデマンドで読み取る。キャッシュ層（LRUキャッシュ）のサイズ設計が、ダッシュボードの表示速度を左右する。
- Compactor: 散らばった小さなBlocksをマージし、ダウンサンプリングを行う掃除屋。こいつのチューニングを怠ると、ストレージコストは雪だるま式に膨れ上がる。
—
2. 数百万シリーズを叩き込む：Remote Writeの極意
数百万もの時系列データを扱う場合、ネットワークのオーバーヘッドが無視できない。Prometheusの設定において、単に`remote_write`を書くだけではアマチュアだ。以下の設定で、スループットの限界を引き上げろ。
prometheus.yml の最適化設定
remote_write:
- url: “http://mimir-distributor.monitoring.svc.cluster.local:8080/api/v1/push”
# 巨大なバッチを一度に送るとDistributorが死ぬ。並列度とキューサイズで制御する
remote_timeout: 30s
queue_config:
capacity: 2500 # キューに溜め込むサンプル数。メモリと相談
max_shards: 200 # 並列送信数。CPUコア数に比例させる
max_samples_per_send: 5000 # 1リクエストあたりのサンプル数。ネットワークとCPUの均衡点を探れ
batch_send_deadline: 5s # リアルタイム性を犠牲にしてもスループットを稼ぐ設定
エキスパートの助言: `max_shards`を上げすぎると、Distributorへの同時コネクションが溢れ、OOM（Out of Memory）を誘発する。必ず`mimir-distributor`側の`concurrency`制限とセットで調整せよ。
—
3. ストレージコスト最適化：Compactorを「調教」する
S3/GCSへの保存は安価だが、無計画に突っ込めば「無駄なインデックス」でクエリが遅くなる。Compactorの設定で、長期保存のコストを劇的に下げる。
Mimir Compactor 設定の神髄
compactor:
data_dir: /data/compactor
# チャンクの重複排除とマージを最適化
compaction_interval: 1h
# 7日以上前のデータは30分刻みでダウンサンプリング
downsampling_enabled: true
# 巨大すぎるブロックを分割して並列処理を促す
max_block_samples: 1000000
# ストレージコスト削減のため、古いデータのフラグメンテーションを許容しない
consistency_delay: 30m
特に重要なのが`consistency_delay`だ。これが短すぎると、Ingesterが書き込み中のブロックをCompactorが触りにいき、読み取りエラーやデータ不整合を招く。クラウドストレージの最終整合性を信じすぎず、余裕を持って設定せよ。
—
4. 自動化ハック：APIによる動的スケーリング
手動で設定ファイルを書き換えるのは、すでに過去の遺物だ。Mimirの各コンポーネントはAPI経由で状態を監視できる。以下は、Ingesterのメモリ使用率が閾値を超えた際に、自動的にスケールアウトをトリガーするシェルスクリプトの断片だ。
!/bin/bash
Ingesterのメモリ消費を監視し、スケーリング閾値を判定する
MIMIR_INGESTER_URL=”http://mimir-ingester-querier:8080/metrics”
MEM_USAGE=$(curl -s $MIMIR_INGESTER_URL | grep ‘container_memory_usage_bytes’ | awk ‘{sum+=$2} END {print sum/1024/1024/1024}’)
if (( $(echo “$MEM_USAGE > 64” | bc -l) )); then
echo “Ingester pressure critical: ${MEM_USAGE}GB. Triggering horizontal pod autoscaler…”
kubectl scale deployment/mimir-ingester –replicas=10
fi
※ 本番運用では、必ず`HorizontalPodAutoscaler`のカスタムメトリクス（Prometheus Adapter経由）を利用し、`mimir_ingester_memory_utilization`をターゲットにするのが定石である。
—
5. アーキテクトの最後の忠告
大規模監視において、最大の敵は「高すぎる基数（High Cardinality）」だ。どのラベルに何が隠れているのかを可視化しない限り、どんなに強力なインフラもいずれ破綻する。
1. ラベルの正規化: `uid`や`request_id`のようなユニークな値をラベルにするのは死を意味する。それはログの仕事だ。
2. クエリの監視: `mimir_query_stats`を見て、遅いクエリを特定し、`Recording Rules`で事前計算させろ。
3. キャッシュの神髄: Store GatewayのキャッシュはSSDを積め。メモリキャッシュ（Memcached/Redis）と併用し、二段構えで構築するのが、爆速ダッシュボードへの唯一の近道だ。
Mimirは、あなたの監視基盤を「管理対象」から「信頼できる真実の源（Single Source of Truth）」へと昇華させる。道具が最高峰であるならば、使い手の設計思想もまた、最高峰であれ。健闘を祈る。