こんにちは。オブザーバビリティの世界へようこそ。
現場で「なぜかメトリクスが取れない」「バッチが動くたびに監視設定を書き換えるのが辛い」と絶望したことはありませんか？ 今日は、そんな苦行からあなたを解放する、PrometheusとKEDAを組み合わせた「動的監視アーキテクチャ」の真髄を伝授します。
これは単なるツール紹介ではありません。「システムが自律的に自身の状態を観測し、最適化する」という、モダンなエンジニアリングの核心に迫る話です。
—
1. なぜ「動的」である必要があるのか？
大規模なバッチ処理やイベント駆動型のアーキテクチャにおいて、ワーカー（処理を行うPod）は負荷に応じて増減します。もし、監視対象を静的なリストで管理していたら？
- 課題: スケールアウトした瞬間に監視対象から漏れ、エラーの予兆を見逃す。
- 悲劇: スケールインした瞬間に「死んだはずのPod」が監視対象に残り、アラートが鳴り止まない（ゾンビ・メトリクスの恐怖）。
Prometheusのデフォルト設定（static_config）は、この動的な世界にはあまりに無力です。ここで登場するのが、Kubernetesの「イベント駆動の魔術師」であるKEDAです。
—
2. アーキテクチャの神髄：KEDA × Prometheusの連携
KEDAの本来の役割はオートスケーリングですが、今回は「Prometheusに動的な対象を教えるハブ」として使います。
- Prometheus: `ServiceDiscovery` を使い、Kubernetes API経由でPodの存在を常に監視。
- KEDA: 負荷に応じてPodを増減させる司令塔。
- Kubernetes Service: Podの羅列を一つのエンドポイントに抽象化するクッション。
この構成なら、Prometheus側は「このラベルを持つPodを全部スクレイプせよ」と一度設定するだけで、あとはKEDAがPodを増やそうが減らそうが、自動的に追従してくれます。
—
3. 実践：KEDAでバッチを制御し、Prometheusで捉える
まずは、最も重要な設定から見ていきましょう。
ステップ1：Podを識別するためのService定義
Podを個別に追うのではなく、ラベルでグルーピングします。
apiVersion: v1
kind: Service
metadata:
name: worker-service
labels:
app: batch-worker # Prometheusはこのラベルを目印にする
spec:
selector:
app: batch-worker
ports:
- port: 8080
ステップ2：KEDAで負荷に応じてオートスケール
キューの深さやCPU負荷をトリガーに、ワーカーを動的に増減させます。
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: worker-scaler
spec:
scaleTargetRef:
name: batch-worker-deployment # 対象のデプロイメント
minReplicaCount: 1
maxReplicaCount: 10
triggers:
- type: prometheus # Prometheusのメトリクスをトリガーにする
metadata:
serverAddress: http://prometheus-server.monitoring.svc.cluster.local
metricName: worker_queue_depth # キューの長さ
threshold: ’50’ # 50を超えたらスケールアウト
ステップ3：Prometheusの自動発見（ServiceMonitor）
Prometheus Operatorを使っているなら、これが最もスマートです。
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: worker-monitor
labels:
release: prometheus # Prometheusインスタンスと紐付けるラベル
spec:
selector:
matchLabels:
app: batch-worker # ここで先ほどのServiceを自動発見する
endpoints:
- port: metrics # メトリクス公開用ポート
interval: 15s # 15秒おきにスクレイプ
—
4. 運用上の「震えるほど役立つ」注意点
この仕組みを導入する際、現場で必ずハマるポイントがあります。これを押さえておくだけで、あなたの信頼度は跳ね上がります。
1. メトリクスのカーディナリティ（高次元化）に注意:
Podが動的に増減すると、メトリクスに `pod_name` などのラベルが大量に付与されます。PrometheusのTSDBがパンクしないよう、不要なラベルは `relabel_configs` で削ぎ落とすのがプロの技です。
2. スクレイプ間隔の調整:
オートスケールする速度よりも、スクレイプ間隔が長すぎると、急激な負荷変動時に「Podが死んでいるのにメトリクスが残る」現象が起きます。`15s` 程度が妥当ですが、システムの重要度に応じて最適化してください。
3. Pod Readiness Probeの徹底:
Prometheusは `Ready` 状態のPodしかスクレイプしません。ワーカーが起動して準備が整う前にスクレイプしようとするとエラーログで埋め尽くされます。必ず `readinessProbe` を正しく設定しましょう。
—
最後に：あなたへのアドバイス
「監視」とは、単にグラフを見ることではありません。「システムが今、どういう状態で生きているのか」を正確に把握するための対話です。
KEDAでスケーリングを自動化し、Prometheusでその変動を完璧にキャプチャする。この構成を組めれば、あなたは深夜の呼び出しから解放され、より創造的な開発に時間を割けるようになります。
まずは、小さなワーカーを1つ動かして、`ServiceMonitor` がそれを掴む様子を観察してみてください。そのグラフに線が描かれた瞬間、きっとエンジニアとしての新しい視界が開けるはずです。
何か詰まったら、いつでも聞いてくださいね。応援しています！