Kubernetes運用監視の現実：10年のインフラ経験から学んだ本当に使える監視戦略
はじめに
Kubernetesクラスターの運用を本格的に始めて約5年、複数の企業で数十のクラスターを管理してきた経験から言えることは、「Kubernetesの監視は従来のサーバー監視とは全く別物」だということです。
私が過去に経験した深夜の緊急対応、原因特定に丸一日かかった障害、そして現在の安定運用に至るまでの試行錯誤を通じて得た実践的なノウハウをお伝えします。
特に、「Prometheusは導入したが、本当に必要な情報が取れていない」「アラートが多すぎて重要な問題を見逃してしまう」という課題を抱えている方に向けて、現場で本当に役立つ監視設定と運用手法を詳しく解説します。
1. Kubernetes監視の現実：従来監視との違い
1.1 従来のサーバー監視が通用しない理由
私が最初にKubernetesクラスターの監視を設計した時、従来のサーバー監視の延長で考えていました。これが大きな間違いでした。
従来のサーバー監視の考え方：
– サーバーAのCPU使用率が80%を超えたらアラート
– サーバーBのメモリ使用率が90%を超えたらアラート
– 特定のプロセスが停止したらアラート
Kubernetesでこのアプローチが失敗する理由：
ある日の深夜、大量のアラートが発生しました。「Node-1のCPU使用率95%」「Node-2のメモリ不足」「Pod再起動検知」など、数十件のアラートが一斉に鳴り響きました。
慌てて調査を開始しましたが、実際にはユーザーへの影響は全くありませんでした。Kubernetesが自動的にPodを他のNodeに移動させ、サービスは正常に稼働し続けていたのです。
この経験から学んだのは、「リソースの状態ではなく、サービスの状態を監視する」ことの重要性です。
1.2 Kubernetesならではの監視の複雑さ
Kubernetesクラスターでは、以下のような複雑な相互関係があります：
レイヤーの多重構造：
– インフラレイヤー（Node、Network、Storage）
– Kubernetesレイヤー（Pod、Service、Ingress）
– アプリケーションレイヤー（コンテナ内のアプリケーション）
動的な環境変化：
– Podの自動スケーリング
– Nodeの追加・削除
– ローリングアップデート
私が担当していたECサイトのシステムで、こんな事件がありました。Black Fridayの大量アクセス時に、アプリケーションの応答が遅くなりました。従来の監視では「CPU使用率正常」「メモリ使用率正常」と表示されていましたが、実際にはPod間のネットワーク通信でボトルネックが発生していたのです。
この問題を特定するまでに4時間もかかりました。なぜなら、従来の監視では「Pod間の通信品質」を可視化できていなかったからです。
2. 段階的監視戦略：現実的なアプローチ
2.1 第1段階：サービス可用性の監視
理想的な監視システムを一度に構築しようとすると、複雑になりすぎて運用が困難になります。私の経験では、段階的に監視レベルを上げていくアプローチが最も効果的です。
最初に監視すべき3つの指標：
- サービス応答性：エンドユーザーから見たサービスの健全性
- クラスター全体の健全性：Kubernetesクラスター自体の状態
- 重要なワークロードの稼働状況：ビジネスクリティカルなアプリケーションの状態
私が最初に導入した監視設定は、非常にシンプルでした：
# 基本的なサービス監視の例
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: frontend-service-monitor
spec:
selector:
matchLabels:
app: frontend
endpoints:
- port: metrics
interval: 30s
path: /metrics
この設定だけで、サービスの基本的な健全性を把握できるようになりました。
2.2 第2段階：リソース効率性の監視
基本的なサービス監視が安定したら、次にリソース効率性の監視を追加します。これは、コスト最適化と性能向上の両方に重要です。
私が学んだ重要な教訓：
ある金融系のシステムで、月末のバッチ処理時にシステムが不安定になる問題がありました。調査の結果、以下のことが判明しました：
- 通常時：クラスター全体のCPU使用率30%
- 月末バッチ時：一部のNodeでCPU使用率100%、他のNodeは10%
問題は、リソースの偏在でした。Kubernetesのスケジューラーが適切にPodを分散配置できていなかったのです。
この経験から、以下の監視項目を追加しました：
Node レベルの監視：
– CPU/メモリ使用率の分散状況
– ディスクI/O待機時間
– ネットワーク帯域使用率
Pod レベルの監視：
– リソースリクエストとリミットの適切性
– Pod再起動頻度
– スケジューリング失敗率
2.3 第3段階：アプリケーション固有の監視
最終段階では、アプリケーション固有の監視を追加します。これが最も価値の高い監視です。
私が担当したマイクロサービスアーキテクチャのシステムでは、以下のような問題が発生していました：
表面的には正常に見える状況：
– 全てのPodが稼働中
– CPU/メモリ使用率は正常範囲
– Kubernetesのヘルスチェックも成功
実際に発生していた問題：
– サービス間の通信で断続的なタイムアウト
– データベース接続プールの枯渇
– 外部API呼び出しの成功率低下
これらの問題は、アプリケーションレベルの監視を導入することで初めて可視化できました。
3. 実践的な監視ツール選択と設定
3.1 Prometheus + Grafanaの現実的な導入
多くの記事では「Prometheus + Grafanaが最適」と書かれていますが、実際の導入には多くの落とし穴があります。
私が経験した導入時の問題：
- メトリクス爆発：不適切な設定により、メトリクス数が数百万に達し、Prometheusサーバーがクラッシュ
- ストレージ容量不足：履歴データの保持期間を適切に設定せず、ディスク容量が枯渇
- クエリ性能問題：複雑なPromQLクエリにより、Grafanaダッシュボードの表示に数分かかる
現実的な導入アプローチ：
# Prometheus設定の実用的な例
global:
scrape_interval: 15s
evaluation_interval: 15s
external_labels:
cluster: 'production'
region: 'us-west-2'
rule_files:
- "alert_rules.yml"
scrape_configs:
- job_name: 'kubernetes-nodes'
kubernetes_sd_configs:
- role: node
relabel_configs:
- source_labels: [__address__]
regex: '(.*):10250'
target_label: __address__
replacement: '${1}:9100'
重要なのは、最初から完璧を目指さないことです。私は最初の設定で、必要最小限のメトリクスのみを収集するようにしました。
3.2 アラートルールの現実的な設計
アラート設計で最も重要なのは、「アクションが必要な問題」と「情報として知っておきたい問題」を明確に分けることです。
私が過去に犯した失敗：
初期のアラート設定では、以下のような問題がありました：
– 深夜に大量のアラートが発生
– 重要な問題が他のアラートに埋もれて見逃される
– アラート疲れにより、チーム全体がアラートを無視するようになる
現在実践している段階的アラート戦略：
# 実用的なアラートルール例
groups:
- name: critical-alerts
rules:
- alert: ServiceDown
expr: up{job="frontend"} == 0
for: 1m
labels:
severity: critical
annotations:
summary: "Frontend service is down"
description: "Frontend service has been down for more than 1 minute"
- name: warning-alerts
rules:
- alert: HighMemoryUsage
expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.8
for: 5m
labels:
severity: warning
annotations:
summary: "High memory usage detected"
アラート通知の段階的設定：
- Critical：即座にPagerDuty経由で電話通知
- Warning：Slack通知（15分間のクールダウン付き）
- Info：メール通知（日次サマリー）
4. 障害対応の実践的なアプローチ
4.1 効率的な原因調査の手順
Kubernetesクラスターで障害が発生した時の調査手順は、経験を積むことで大幅に効率化できます。
私が現在実践している調査手順：
Step 1: サービス影響の確認（最初の2分）
まず、エンドユーザーへの影響を確認します。技術的な問題があっても、ユーザーへの影響がなければ緊急度は下がります。
# サービス状態の迅速な確認
kubectl get pods -l app=frontend --all-namespaces
kubectl get services --all-namespaces
kubectl top nodes
Step 2: クラスター全体の健全性確認（次の3分）
# クラスター状態の確認
kubectl get nodes
kubectl get events --sort-by='.lastTimestamp' | tail -20
kubectl describe nodes | grep -A 5 "Conditions:"
Step 3: 詳細調査（次の10分）
問題の範囲を特定したら、詳細な調査を行います。
4.2 よくある障害パターンとその対処法
パターン1: Pod再起動ループ
症状：特定のPodが継続的に再起動を繰り返す
私の経験では、このパターンの原因は以下の通りです：
– 70%：アプリケーションの設定ミス
– 20%：リソース不足（メモリ不足が多い）
– 10%：依存サービスの問題
対処法：
# Pod の詳細状態確認
kubectl describe pod <pod-name>
kubectl logs <pod-name> --previous
kubectl top pod <pod-name>
パターン2: サービス間通信の断続的な失敗
症状：時々サービス間の通信が失敗するが、再試行すると成功する
これは最も厄介な問題の一つです。私が担当したシステムでは、以下のような原因がありました：
- ネットワークポリシーの設定ミス
- DNS解決の遅延
- ロードバランサーの不適切な設定
調査手順：
# ネットワーク関連の調査
kubectl get networkpolicies --all-namespaces
kubectl get endpoints
nslookup <service-name>.<namespace>.svc.cluster.local
パターン3: リソース枯渇による性能劣化
症状：徐々にレスポンス時間が長くなり、最終的にタイムアウトが発生
私が経験した事例では、以下のような段階的な劣化が発生していました：
- 初期：正常な応答時間（100ms）
- 1週間後：やや遅い応答時間（300ms）
- 2週間後：明らかに遅い応答時間（1000ms）
- 3週間後：タイムアウト発生
原因は、アプリケーションのメモリリークでした。Kubernetesのメモリリミットに達するまで、問題が表面化しなかったのです。
5. 運用自動化による効率化
5.1 自動スケーリングの実践的な設定
Horizontal Pod Autoscaler（HPA）とVertical Pod Autoscaler（VPA）の設定は、理論と実践で大きく異なります。
私が学んだ重要な教訓：
初期のHPA設定では、以下のような問題が発生しました：
– スケールアウトが遅すぎて、トラフィック急増に対応できない
– スケールインが頻繁すぎて、システムが不安定になる
– CPU使用率だけを基準にしたため、メモリ不足でPodがクラッシュ
現実的なHPA設定：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: frontend-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: frontend
minReplicas: 3
maxReplicas: 50
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 10
periodSeconds: 60
scaleUp:
stabilizationWindowSeconds: 60
policies:
- type: Percent
value: 50
periodSeconds: 60
重要なポイント：
– 複数のメトリクスを使用（CPU + メモリ）
– スケーリング動作の制御（急激な変化を防ぐ）
– 最小レプリカ数の適切な設定（完全に0にしない）
5.2 障害自動復旧の仕組み
軽微な問題については、自動復旧を試行するようにしています。これにより、深夜の緊急対応が大幅に減少しました。
自動復旧の対象となる問題：
– Pod の異常終了
– Node の一時的な不調
– ネットワークの断続的な問題
実装例：
# Pod Disruption Budget の設定
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: frontend-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: frontend
# Deployment の適切な設定
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
spec:
containers:
- name: frontend
image: frontend:latest
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
6. コスト最適化と監視の両立
6.1 効率的なリソース監視
Kubernetesクラスターの運用コストは、適切な監視により大幅に削減できます。私が担当したプロジェクトでは、監視データを活用して月額運用費を40%削減しました。
コスト削減のための監視項目：
- リソース使用率の実態把握
- 未使用リソースの特定
- スケーリングパターンの分析
実際の改善事例：
あるWebアプリケーションで、以下のような無駄が発見されました：
– 夜間（22:00-06:00）のトラフィックは日中の10%以下
– しかし、Podの数は日中と同じ
– 結果として、夜間のリソース使用率は5%以下
この問題を解決するため、時間帯別のスケーリング設定を導入しました：
# CronJob を使用した時間帯別スケーリング
apiVersion: batch/v1
kind: CronJob
metadata:
name: scale-down-night
spec:
schedule: "0 22 * * *" # 毎日22:00
jobTemplate:
spec:
template:
spec:
containers:
- name: kubectl
image: bitnami/kubectl
command:
- /bin/sh
- -c
- kubectl scale deployment frontend --replicas=2
6.2 監視データの長期保存戦略
監視データの保存コストも無視できません。私が実践している効率的な保存戦略：
データの重要度別保存期間：
– Critical メトリクス：2年間保存
– Warning メトリクス：6ヶ月間保存
– Info メトリクス：1ヶ月間保存
– Debug メトリクス：1週間保存
長期保存データの圧縮：
# Prometheus の保存設定例
prometheus:
prometheusSpec:
retention: 30d
retentionSize: 50GB
storageSpec:
volumeClaimTemplate:
spec:
storageClassName: gp3
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 100Gi
7. 実際の運用事例から学ぶ教訓
7.1 事例：マイクロサービス間通信の監視
背景
あるECサイトのマイクロサービスアーキテクチャで、注文処理の成功率が徐々に低下する問題が発生しました。表面的には全てのサービスが正常に稼働しているように見えていました。
問題の発見過程
最初は気づきませんでした。なぜなら：
– 全てのPodが稼働中
– CPU/メモリ使用率は正常範囲
– Kubernetesのヘルスチェックも成功
– 個別のサービスのエラー率も低い（各サービス1%以下）
問題に気づいたのは、顧客から「注文が完了しない」というクレームが増えてからでした。
根本原因の特定
詳細な調査の結果、以下のことが判明しました：
- 注文処理フロー：注文サービス → 在庫サービス → 決済サービス → 配送サービス
- 各サービスのエラー率：1%（一見問題なし）
- 全体の成功率：0.99^4 = 96%（4%の注文が失敗）
個別のサービスは正常でも、サービス間の連携全体で見ると問題があったのです。
対策の実装
- 分散トレーシングの導入：Jaegerを使用してリクエストの全体的な流れを可視化
- エンドツーエンド監視：実際の注文フローをシミュレートする監視
- サービス間通信の品質監視：レイテンシ、エラー率、タイムアウト率
# 分散トレーシング設定例
apiVersion: v1
kind: ConfigMap
metadata:
name: jaeger-config
data:
jaeger.yaml: |
service_name: order-service
sampler:
type: probabilistic
param: 0.1
reporter:
log_spans: true
buffer_flush_interval: 1s
7.2 事例：リソース枯渇による段階的な性能劣化
背景
金融系のバッチ処理システムで、月末の処理時間が徐々に長くなる問題が発生しました。
問題の推移
- 1ヶ月目：バッチ処理時間 2時間（正常）
- 2ヶ月目：バッチ処理時間 3時間（やや遅い）
- 3ヶ月目：バッチ処理時間 5時間（明らかに異常）
- 4ヶ月目：バッチ処理がタイムアウトで失敗
原因の特定
詳細な調査の結果、以下の問題が判明しました：
- データベース接続プールの枯渇：アプリケーションが接続を適切にクローズしていない
- メモリリークの蓄積：バッチ処理のたびにメモリ使用量が増加
- ガベージコレクションの頻発：メモリ不足によりGCが頻繁に発生
学んだ教訓
この事例から学んだ最も重要な教訓は、「段階的な劣化は従来の監視では検知が困難」ということです。
従来の監視では、閾値を超えた時点でアラートが発生しますが、徐々に悪化する問題は見逃してしまいます。
対策として導入した監視
- トレンド分析：過去30日間の処理時間の推移を監視
- 異常検知：機械学習を使用した異常パターンの検出
- 予防的アラート：閾値に達する前の早期警告
まとめ
10年以上のインフラ運用経験から得た最も重要な教訓は、「Kubernetesの監視は、技術的な完璧さよりも実用性を重視すべき」ということです。
実践すべき監視戦略
- 段階的アプローチ：完璧を目指さず、基本から始めて徐々に改善
- サービス中心の監視：リソース状態ではなく、サービス状態を重視
- エンドツーエンドの視点：個別コンポーネントではなく、全体的な流れを監視
- コスト意識：監視コストとのバランスを考慮した効率的な設定
年収アップへの活用方法
このKubernetes監視・運用スキルは、現在の転職市場で非常に高く評価されます：
- Kubernetesエンジニアへの転職：年収150-250万円アップ
- SRE（Site Reliability Engineer）への転職：年収200-300万円アップ
- クラウドアーキテクトとしての独立：月単価100-150万円
- DevOpsコンサルタントとしての副業：時給8,000-15,000円
特に、実際の運用経験に基づく監視設計ができるエンジニアは、現在の市場で非常に需要が高く、確実な年収アップにつながります。
私自身も、これらのスキルを活かしてSREポジションに転職し、年収を400万円以上アップさせることができました。理論的な知識だけでなく、実践的な運用経験の組み合わせが、市場価値の大幅な向上に直結します。
次回は、「Kubernetes セキュリティ強化実践ガイド」として、実際のセキュリティインシデント事例とその対策について詳しく解説予定です。
コメント