PromQLの深淵：正規表現という名の「CPUの墓場」を解体し、パフォーマンスを極限まで引き出す
オブザーバビリティの世界において、Prometheusはもはや心臓部だ。だが、多くのエンジニアが「便利だから」という理由で無自覚に叩き込んでいるクエリが、実は監視基盤全体のパフォーマンスを蝕む「毒」になっていることを知っているか？
特に、`=~` や `!~` を用いた正規表現マッチングは、扱いを間違えればPrometheusのメモリを食いつぶし、クエリ実行のレイテンシを指数関数的に増大させる。本稿では、正規表現を駆使する際のパフォーマンスのメカニズムを解剖し、高負荷な環境下でも一瞬で結果を返すための「極限の最適化」を伝授する。
—
1. なぜ正規表現は「重い」のか：内部アーキテクチャの真実
Prometheusのラベル検索は、基本的にインデックス（Inverted Index）を引くことで高速化されている。しかし、正規表現 `(=~)` が混じった瞬間、Prometheusは以下の処理を強制される。
1. 全ラベル値の走査: インデックスのルックアップが効かないケースが多発する。
2. マッチングの計算コスト: 検索対象となる時系列データのラベルに対し、その都度正規表現エンジン（Goの `regexp` パッケージ）を走らせる。
3. CPUの飽和: ラベルのカーディナリティ（種類数）が多い場合、リクエストのたびにCPUコアが正規表現のコンパイルと実行に専念し、他のクエリをブロックする。
特に `.` で囲むような甘い正規表現は、バックトラック（再帰的な探索）を誘発し、処理時間を爆発的に増大させる。これが、ダッシュボードを開いた瞬間にPrometheusが悲鳴を上げる主因だ。
—
2. 禁断のアンチパターン：現場で遭遇する「遅延製造機」
アンチパターンA：無駄なワイルドカード
悪例: 全てのサービス名を正規表現で検索
http_requests_total{service=~”.api.”}
このクエリは、`api`という文字列を含む全てのラベルを走査する。もし `service` ラベルの数が数万規模であれば、Prometheusは死ぬ。
アンチパターンB：否定正規表現の多用
悪例: 特定のインスタンスを除外するために正規表現を使用
node_cpu_seconds_total{instance!~”node-0[1-3]”}
否定マッチングは、インデックスを逆引きできない場合が多く、対象範囲が広がるほど計算コストが跳ね上がる。
—
3. 高速化の鉄則：リファクタリング手法
テクニック1：完全一致（Equality Matcher）への置換
可能な限り `=` を使う。これが最も速い。もし列挙できる値が固定的なら、正規表現ではなく `|`（OR）を使うべきだ。
改善前: 正規表現によるORマッチ
http_requests_total{instance=~”prod-web-01|prod-web-02|prod-web-03″}
改善後: 完全一致のベクトル化（可能ならこちらがベター）
ただしPromQLの仕様上、OR演算子を使う方がクエリが分離され、最適化が効きやすい
http_requests_total{instance=”prod-web-01″}
or http_requests_total{instance=”prod-web-02″}
or http_requests_total{instance=”prod-web-03″}
※ `or` 演算子は、ベクトル同士の和集合をとるため、インデックスをフル活用できる。
テクニック2：前方一致の活用
正規表現を書くなら、必ず「アンカー」を意識せよ。`^` を付けるだけで、正規表現エンジンは検索範囲を劇的に絞り込める。
悪例: どこにでもマッチする
{service=~”.auth.”}
最適化: 先頭一致のみに限定
{service=~”^auth.”}
—
4. エンジニアのための「最適化自動化スクリプト」
手動でクエリを最適化するのは限界がある。PrometheusのAPIを叩き、実行時間が長いクエリや正規表現を多用しているクエリをCLIで抽出するスクリプトを書こう。
!/bin/bash
slow_query_detector.sh
現在のPrometheusのクエリログや、API経由で実行中の重いクエリを監視する
PROM_URL=”http://prometheus.local”
実行時間が長いクエリをAPI経由で抽出（JSON解析）
curl -s “${PROM_URL}/api/v1/status/queries” | jq ‘.data[] | select(.durationSeconds > 1.0)’
このスクリプトをCI/CDパイプラインに組み込み、「正規表現を多用したクエリをマージ時にリジェクトする」という品質ゲートを設けることこそ、真のDevOpsだ。
—
5. アーキテクトの最終提言：監視の美学
優れたオブザーバビリティとは、「監視のためにシステムを壊さない」ことだ。
正規表現は強力なツールだが、それは「外科手術のメス」であって「日常の道具」ではない。
1. ラベルのカーディナリティを抑える: 正規表現に頼らざるを得ない設計自体が、データモデルの敗北である。
2. Recording Rulesの活用: 重い正規表現クエリは、Recording Rulesで事前に集約し、時系列データとして永続化せよ。クエリ時に計算させるな。
3. Explainの確認: Prometheusの `/api/v1/query` を叩く際、`explain` オプション（最新版）を使用して、実行プランを確認する習慣をつけよ。
PromQLを操ることは、インフラの神経系を直接チューニングすることと同義だ。正規表現の罠を理解し、クエリの裏側で何が起きているかを想像できるようになった時、君は初めて「監視のアーキテクト」と名乗れるようになる。
さあ、そのクエリを見直せ。計算資源を解放し、真のオブザーバビリティを手にしろ。