闇を切り裂くPromQL：重厚長大なグラフを瞬殺する「極限最適化」の神髄
Prometheusを導入して数年、「最初は軽快だったGrafanaが、今や読み込みに10秒かかる」という現実に直面していないか？ 多くのエンジニアは「データ量が増えたから仕方ない」と諦めるが、それはPromQLの書き方とPrometheusの内部データ構造に対する無知が生んだ敗北だ。
今日は、小手先のテクニックではなく、Prometheusの心臓部にメスを入れる「極限の最適化」を伝授する。
—
1. ラベルセレクタの「カーディナリティ爆発」を制圧せよ
PromQLの遅延の最大の原因は、計算以前の「検索」にある。`{env=”production”}` のような広すぎるセレクタは、Prometheusが抱えるインデックスの海から数百万のタイムシリーズをメモリに展開させる。
- 鉄則: 常に「高カーディナリティ（変動の激しい）ラベル」を最初に絞り込め。
- ハック: `instance` や `pod` よりも、`job` や `service` でまず範囲を狭めよ。
悪手：巨大なラベル空間をまず検索し、後から絞り込む
sum(rate(http_requests_total[5m])) by (service)
改善：検索対象を局所化する（プレフィルタリングの徹底）
sum(rate(http_requests_total{job=”api-gateway”}[5m])) by (service)
アーキテクトの視点: Prometheusはインデックス検索の際、ラベルセットが一致するチャンクをメモリ上のポインタで走査する。セレクタが具体的であればあるほど、イテレーション回数は劇的に減る。
—
2. `subquery` の多用は「隠れた爆弾」だ
`rate(sum(…) by (…))` のようなクエリをグラフ化する際、手軽に `[5m:15s]` と書ける `subquery` は非常に強力だ。しかし、これは「計算の中で再計算を行う」という極めてコストの高い処理を裏で行っている。
- 最適化の極意: `subquery` を使う前に、`recording rules` を疑え。
- 自動化: 頻繁に参照する複雑な集計は、Prometheus側で `recording rule` として事前に計算し、結果を別のメトリクスとして保存せよ。
rules.yml
groups:
- name: api_latency
rules:
- record: job:http_latency_ratio:rate5m
expr: sum(rate(http_request_duration_seconds_sum[5m])) by (job) / sum(rate(http_request_duration_seconds_count[5m])) by (job)
Grafana側では単に `job:http_latency_ratio:rate5m` を呼び出すだけ。描画は10倍高速化する。
—
3. `rate` と `increase` の「メモリ効率」を見極める
`increase` は内部的に `rate` を計算してから時間を乗算している。細かいことだが、大量のグラフを同時に表示するダッシュボードでは、計算コストの微差が積み重なり、PromQLの実行時間を押し上げる。
- 使い分け: カウンターの「変化量」そのものに興味があるなら `increase`、1秒あたりの「スループット」が知りたいなら `rate`。これを混同して無駄な乗算・除算を計算グラフに組み込むな。
—
4. `step` 値の調和：Grafanaの `Min step` を制御せよ
Grafanaの `Auto` 設定に甘えるな。Prometheusのスクレイプ間隔が15秒なのに、Grafanaの `step` が1秒に設定されていたら、Prometheusは存在しないデータを線形補完するために無駄な演算を繰り返す。
- チューニング: `Min step` をスクレイプ間隔の2倍（例：30s）に固定せよ。これにより、無駄な計算リクエストが削減され、クエリエンジンのCPU負荷が激減する。
—
5. CLIによる「重いクエリ」の強制排除
どのクエリが遅いのか、勘でデバッグするのは三流だ。Prometheusの API (`/api/v1/status/queries`) を叩き、実行時間（`durationSeconds`）が長いクエリを特定せよ。
実行時間が長いクエリを特定するワンライナー
curl -s http://prometheus:9090/api/v1/status/queries | \
jq ‘.data[] | select(.durationSeconds > 1.0) | {query, durationSeconds}’
このスクリプトをCI/CDパイプラインに組み込み、「0.5秒以上の計算時間を要するクエリ」をコミットした瞬間に警告を出すのが、真のオブザーバビリティ・エンジニアの矜持だ。
—
結論：技術は「規律」に従う
PromQLの最適化とは、単なるクエリの書き換えではない。それはPrometheusの計算資源をいかに無駄なく利用するかという、リソースマネジメントの哲学そのものだ。
1. インデックスの絞り込み（検索対象を狭める）
2. Recording Rules（計算の先送り）
3. Stepの最適化（演算回数の抑制）
これらを実行するだけで、あなたのダッシュボードは「重いグラフ」という呪縛から解放される。システムは、あなたが与えた「規律」以上のパフォーマンスを出すことは決してない。さあ、今すぐコードを書き換え、その手でシステムの呼吸を取り戻せ。