Prometheus × KEDA：動的ワーカーの「監視の死角」を消し去るアーキテクチャ
システムが「生き物」のようにスケールする現代において、静的なPrometheusの設定ファイル (`prometheus.yml`) はもはや遺物だ。特に、大規模バッチ処理で数千のPodが数分間だけ出現して消えるような環境では、従来の `static_configs` は無力である。
今回は、KEDAを用いてワーカーのライフサイクルを制御しつつ、Prometheusにその「存在」をリアルタイムで教え込み、監視の死角をゼロにする究極の運用術を伝授する。
—
1. なぜ「動的スケーリング」で監視が壊れるのか？
多くのエンジニアが陥る罠は、「オートスケーリングの速度に監視のサービスディスカバリが追いつかない」ことだ。
KEDAでワーカーを増やしても、PrometheusがそのPodをスクレイピング対象として認識するまでのタイムラグ（`scrape_interval` + `relabel_config` の評価時間）の間、メトリクスは欠落する。この「監視の空白期間」こそが、障害検知を遅らせる最大の要因だ。
2. KEDA × Prometheus 連携のアーキテクチャ
静的な設定を捨て、Kubernetesの Service Discovery (SD) を使い倒せ。
- アーキテクチャの核心: Prometheusの `kubernetes_sd_configs` を使い、`role: pod` でラベルセレクタを絞り込む。
- KEDAの役割: メトリクスベース（例：RabbitMQのキュー長やKafkaのラグ）でDeploymentをスケールさせ、Podに一意の `app: worker` や `batch-id` ラベルを付与する。
- Prometheusの役割: `relabel_configs` を駆使し、特定のラベルを持つPodのみを動的にターゲットとして抽出する。
3. 実践：YAMLで構築する「死角のない」オートスケーリング
KEDA ScaledObject: メトリクス駆動のトリガー
まずは、負荷に応じてワーカーを爆速で立ち上げる設定だ。
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: worker-scaler
spec:
scaleTargetRef:
name: batch-worker-deployment
minReplicaCount: 0
maxReplicaCount: 100
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus-operated.monitoring.svc.cluster.local
metricName: queue_length
threshold: ’50’
query: sum(queue_length_metric)
Prometheus ServiceMonitor: 動的ターゲットの自動抽出
次に、PrometheusがこのPodを自動で見つけるための `ServiceMonitor` だ。
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: worker-monitor
labels:
release: prometheus # Prometheusのサービスディスカバリ対象にするための重要ラベル
spec:
selector:
matchLabels:
app: worker # KEDAで生成されたPodのラベルを捕捉
endpoints:
- port: metrics
interval: 15s # スケールが激しい場合は10s〜15sに設定
relabelings:
- sourceLabels: [__meta_kubernetes_pod_name]
targetLabel: pod_name
—
4. プロの現場で差がつく「隠れたテクニック」
1. Prometheusの「高負荷」を避けるスクレイピングのコツ
数千のPodが同時に立ち上がると、Prometheusのターゲット更新処理がCPUを食いつぶす。
- 解決策: `relabel_configs` で不要なメタデータを捨てろ。`keep` アクションで必要なラベル以外はインデックスさせないだけで、メモリ消費は劇的に下がる。
2. チーム開発で役立つ「設定共有ルール」
- DRY原則: `ServiceMonitor` をHelm Chartの共通ライブラリ化し、アプリ開発者は `values.yaml` でポートとパスを指定するだけで監視が有効になるように設計せよ。
- 絶対に入れるべき神プラグイン: VS Codeの `Prometheus Metrics Explorer`。クエリを書く前にメトリクス名が補完されるだけで、開発効率は3倍になる。
3. デバッグのショートカット
Prometheusのターゲット状態を確認する際、管理画面（`/-/targets`）をブラウザで開くのは遅い。
kubectl経由で直接確認するコマンドをaliasに登録せよ
alias p-targets=’kubectl exec -it prometheus-0 -n monitoring — curl -s http://localhost:9090/api/v1/targets | jq .data.activeTargets[].discoveredLabels.job’
—
結論：監視は「受動」から「連動」へ
KEDAとPrometheusを連携させることは、単なる設定変更ではない。「インフラの伸縮」と「観測の同期」を合わせるという、オブザーバビリティの高度な実践だ。
「メトリクスが取れていない」という報告をチームメンバーから受ける時代は終わらせよう。KEDAでPodが増えたその瞬間に、Prometheusが「見つけている」状態こそが、エンジニアリングの理想形だ。
さあ、今すぐ `relabel_configs` を見直し、ボトルネックを排除してくれ。君たちのシステムがより「可視化された」状態になることを期待している。