Prometheusの「重いクエリ」を葬り去る：Recording Rules極限活用術
大規模なシステムを運用していると、必ずぶち当たる壁がある。「Grafanaのダッシュボードを開くたびに、PrometheusのCPUが跳ね上がり、レスポンスが返ってこない」という悲劇だ。
結論から言おう。「ダッシュボードで複雑なクエリを叩く」のは、オブザーバビリティにおける最大のアンチパターンだ。
今日は、PrometheusのRecording Rulesを駆使して、クエリコストを恒久的に削減し、Grafanaの描画速度を10倍以上に引き上げる「アーキテクトの作法」を伝授する。
—
1. なぜ「その場計算」は滅びるのか：Recording Rulesの真価
PrometheusはPull型アーキテクチャであり、強力なPromQLを有している。しかし、数百万の時系列データを抱えた状態で、ダッシュボードを開くたびに `rate()` や `sum()` をネストさせて計算させれば、Prometheusのヘッドノードは悲鳴を上げる。
Recording Rules（録画ルール）は、この計算を「評価時」ではなく「定常的なバックグラウンド処理」へと移行させる技術だ。
- 動的クエリ（Ad-hoc）: 閲覧のたびに計算。遅い。リソースを食う。
- Recording Rules: 指定間隔（`evaluation_interval`）で計算し、結果を新しい時系列として保存する。一度計算すれば、読み取りは一瞬。
—
2. 実践：コストを劇的に下げる設計パターン
パターンA：高頻度な分母・分子の事前計算
成功率（Success Rate）を算出する際、毎回 `sum(rate(http_requests_total{status=~”2..”}[5m])) / sum(rate(http_requests_total[5m]))` を計算してはいけない。
groups:
- name: service_availability
rules:
# 分子を事前計算して保存（これだけで計算コストは1/2以下になる）
- record: job:http_requests_success:rate5m
expr: sum(rate(http_requests_total{status=~”2..”}[5m])) by (job)
# 分母も同様に保存
- record: job:http_requests:rate5m
expr: sum(rate(http_requests_total[5m])) by (job)
パターンB：階層的集計（Hierarchical Aggregation）
「全コンテナ → 全ポッド → 全サービス」という階層で集計を行う場合、下位の計算結果を次のルールの入力にする。これにより、計算量は指数関数的に削減される。
—
3. 命名規則とディレクトリ構成：チームの混乱を防ぐ
Recording Rulesが数100個を超えると、管理不能に陥る。「誰が作ったか不明な謎のメトリクス」を生まないための規約を敷く。
命名規則：`階層:指標:演算子[期間]`
- `job:http_requests_total:rate5m` : job単位の5分間レート
- `namespace:memory_usage:percent` : namespace単位のメモリ使用率（％）
推奨ディレクトリ構成
YAMLを巨大な1ファイルに押し込めるのは今日でやめよう。
prometheus/
├── rules/
│ ├── infrastructure.rules.yml # ノード・K8s系
│ ├── application.rules.yml # ビジネスメトリクス
│ └── aggregate.rules.yml # 高コストな集計系（Recording Rules用）
—
4. プロの現場で差がつく「隠れたテクニック」
1. Prometheusの「神」キーボードショートカット
Prometheus UI（`/graph`）を日常的に使うなら、以下のショートカットは必須だ。
- `Ctrl + Enter`: クエリ実行
- `Shift + Enter`: 改行
- `Alt + Up/Down`: 過去のクエリ履歴を辿る
2. 絶対入れるべき神プラグイン：`PromLens`
PromQLが複雑になりすぎて解読不能になった時、[PromLens](https://promlens.com/) を使え。クエリの実行計画を可視化し、「どこで重い処理が発生しているか」がひと目で分かる。
3. 設定共有化のベストプラクティス
チームで設定を同期する際は、`prometheus-operator` を使い、`PrometheusRule` カスタムリソースとして定義せよ。これにより、GitOps（ArgoCDなど）でRecording Rulesのデプロイを自動化し、レビューを通すことが可能になる。
—
5. 最後に：アーキテクトとしての助言
Recording Rulesは「諸刃の剣」でもある。過剰な事前計算はストレージ容量を圧迫し、PrometheusのTSDBのインデックスを肥大化させる。
「本当にそのクエリは頻繁に監視されるのか？」
「ダッシュボードを更新する頻度は？」
この自問自答を忘れないでほしい。計算の粒度は、ビジネスの意思決定速度に合わせて最適化するものだ。
明日、あなたのPrometheusが軽快に動き出し、チームの誰もが「Grafana、速くなった？」と驚く姿を想像してほしい。それが、エンジニアリングにおける「技術による生産性の解放」だ。
—
「計測できないものは改善できない」と言ったのは誰か。だが、計測しすぎてシステムを止めてしまっては本末転倒だ。常に賢く、シンプルに。