インフラストラクチャ調査ガイド

概要

このガイドは、Google Cloud Platform、Kubernetes、PostgreSQL を使用したクラウドネイティブ環境でのインフラストラクチャ問題の診断と解決方法について説明します。サービス停止、パフォーマンス低下、接続問題、リソース制約、設定問題などのインフラ関連の異常を迅速に特定し、解決するための体系的なアプローチを提供します。

調査方法論

1. 初期評価

問題が発生した際の最初のステップ：

• 症状とエラーメッセージの収集

  • ユーザーから報告されたエラーメッセージ
  • アプリケーションログのエラー内容
  • 影響を受けているサービスの特定

• 影響範囲の確認

  • 影響を受けているサービスとその依存関係
  • 問題の深刻度と緊急度の評価
  • 最近の変更やデプロイメントの確認

2. 体系的な診断

高レベルのヘルスチェック

# GCPサービスの状態確認
gcloud compute instances list --filter="status:RUNNING"
gcloud container clusters describe [CLUSTER_NAME]
gcloud sql instances describe [INSTANCE_NAME]

# AlloyDBの状態確認
gcloud alloydb instances describe [INSTANCE_NAME] \
  --cluster=[CLUSTER_NAME] \
  --region=[REGION]

# エラーログの確認
gcloud logging read "severity>=ERROR" --limit=50 --format=json

Kubernetes クラスタの調査

# ノードとポッドの状態確認
kubectl get nodes -o wide
kubectl get pods --all-namespaces | grep -v Running
kubectl describe pod [POD_NAME] -n [NAMESPACE]

# リソース使用状況の確認
kubectl top nodes
kubectl top pods -n [NAMESPACE]

# 最新のイベント確認
kubectl get events --sort-by='.lastTimestamp' -n [NAMESPACE]

# ポッドのログ確認
kubectl logs [POD_NAME] -n [NAMESPACE] --tail=100

データベース層の調査

AlloyDB への接続方法

本番環境の AlloyDB に接続して直接診断を実行する場合：

# 外部IPアドレスの確認（AlloyDBのPublic IPエンドポイント）
gcloud alloydb instances describe [INSTANCE_NAME] \
  --cluster=[CLUSTER_NAME] \
  --region=[REGION] \
  --project=[PROJECT] \
  --format="value(publicIpAddress)"

# IAM認証を使用したpsql接続
PGPASSWORD=$(gcloud auth print-access-token) \
  psql -h [EXTERNAL_IP] -p 5432 -U "[USER_EMAIL]" -d [DATABASE]

# 例: uzu-prd環境への接続
PGPASSWORD=$(gcloud auth print-access-token) \
  psql -h 34.84.11.49 -p 5432 -U "chaya@sally-inc.jp" -d mdms_jp

注意事項:

• IAM 認証を使用するため、ユーザーメールアドレスをユーザー名として使用
• gcloud auth print-access-tokenで取得したトークンをパスワードとして使用
• 外部 IP アドレス経由での接続には適切なファイアウォールルールが必要

データベース診断クエリ

-- アクティブな接続数の確認
SELECT count(*) FROM pg_stat_activity;
SELECT state, count(*) FROM pg_stat_activity GROUP BY state;

-- 実行中のクエリの確認
SELECT query, state, wait_event_type, wait_event
FROM pg_stat_activity
WHERE state != 'idle';

-- ワーカープロセスの設定確認（重要）
SELECT
  current_setting('max_worker_processes') as max_workers,
  current_setting('autovacuum_max_workers') as autovacuum_workers,
  current_setting('max_parallel_workers') as parallel_workers;

-- バックグラウンドワーカーの使用状況
SELECT backend_type, count(*)
FROM pg_stat_activity
WHERE backend_type NOT IN ('client backend', 'background writer', 'checkpointer', 'walwriter')
GROUP BY backend_type;

-- デッドタプルの分析（vacuum問題の特定）
SELECT schemaname, tablename, n_dead_tup, n_live_tup,
       round(n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 2) as dead_ratio
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC LIMIT 10;

3. 根本原因分析

• 5 つのなぜ（5 Whys）テクニックを使用して根本原因を特定
• リソース使用状況の確認（CPU、メモリ、ディスク、ネットワーク）
• ワーカープロセス vs 実際の CPU 使用率の検証 - 高いワーカー数が必ずしも高い CPU 使用率を意味しない
• 設定ファイルと環境変数のレビュー
• ネットワーク接続と DNS 解決の確認
• AlloyDB/CloudSQL ログで「Failed to schedule job」エラーの確認

一般的な問題パターンと解決方法

パフォーマンス低下の問題

症状：

• API レスポンスタイムの増加
• データベースクエリの遅延

診断手順：

# ネットワークレイテンシーの確認
gcloud compute networks list
gcloud compute firewall-rules list

# データベースのスロークエリログ確認
gcloud logging read 'resource.type="cloudsql_database" AND
  textPayload=~"duration:"' --limit=50

-- 長時間実行されているクエリの特定
SELECT
  pid,
  now() - pg_stat_activity.query_start AS duration,
  query,
  state
FROM pg_stat_activity
WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes';

Kubernetes ポッドの再起動問題

症状：

• ポッドが頻繁に再起動する
• CrashLoopBackOff 状態

診断手順：

# ポッドの詳細情報確認
kubectl describe pod [POD_NAME] -n [NAMESPACE]

# 前回の終了理由確認
kubectl get pod [POD_NAME] -n [NAMESPACE] -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'

# リソース制限の確認
kubectl get pod [POD_NAME] -n [NAMESPACE] -o jsonpath='{.spec.containers[*].resources}'

クイック解決パス

よくある問題と即座の対処法

問題	診断コマンド	解決方法
ワーカー枯渇	SELECT current_setting('max_worker_processes')	max_worker_processes を 64 から 128 に増加
並列クエリ過負荷	SELECT current_setting('max_parallel_workers')	2 CPU システムで max_parallel_workers を 8 から 4 に減少
Vacuum ストーム	SELECT * FROM pg_stat_user_tables WHERE n_dead_tup > 10000	autovacuum_naptime と autovacuum_vacuum_cost_delay を調整
メモリ不足	kubectl top pods -n [NAMESPACE]	リソース制限を増加、またはメモリリークを調査
DNS 解決エラー	kubectl exec -it [POD] -- nslookup [SERVICE]	CoreDNS の設定を確認、必要に応じて再起動

解決策フレームワーク

1. 即座の緩和策

• サービス機能を復旧するための迅速な修正
• 最近の変更が疑われる場合のロールバック手順
• ユーザーへの影響を最小限にする一時的な回避策

2. 恒久的な解決

• 根本原因に対する持続可能な修正
• 正確なパラメーターを含む設定変更
• 実装のためのテスト済みコマンドシーケンス

3. 予防措置

• モニタリングの改善提案
• 再発を防ぐためのアーキテクチャ変更
• 一般的な問題に対する自動化

モニタリング推奨事項

重要なメトリクス

1. データベース層

   • アクティブ接続数
   • ワーカープロセス使用率
   • デッドタプル比率
   • クエリ実行時間

2. Kubernetes 層

   • ポッド再起動回数
   • リソース使用率（CPU、メモリ）
   • ネットワークレイテンシー
   • イベントログ

3. アプリケーション層

   • レスポンスタイム
   • エラー率
   • スループット

アラート設定例

# Prometheusアラートルール例
- alert: DatabaseConnectionExhausted
  expr: pg_stat_activity_count > 80
  for: 5m
  annotations:
    summary: "Database connection pool is nearly exhausted"

- alert: WorkerProcessExhaustion
  expr: pg_settings_max_worker_processes - pg_stat_activity_backend_count < 10
  for: 5m
  annotations:
    summary: "Database worker processes are nearly exhausted"

重要な原則

1. 安全第一: 特に本番環境では、コマンド実行前に必ず影響を確認
2. データ整合性: 明示的な確認なしに破壊的なコマンドを実行しない
3. 明確なコミュニケーション: 技術的な発見を関係者が理解できる形で説明
4. 文書化: 将来のインシデントに備えてコマンドをランブックとして保存
5. 効率性: システムへの影響を最小限に抑えながら最大の診断価値を提供
6. 仮定を疑う: 高い CPU 使用率が常に問題とは限らない - ワーカー制限と設定を確認

学習と知識の蓄積

新しい問題パターンの発見時

新しい障害モードや解決方法を発見した場合は、以下の形式で文書化：

### [問題タイプ] (発見日: YYYY-MM-DD)

**症状**: ユーザーから報告された内容
**初期仮説**: 最初に疑った原因  
**実際の原因**: 判明した真の原因
**診断キーコマンド**: `問題を特定したコマンド`
**解決方法**: 具体的な値を含む修正内容
**教訓**: 次回同様の問題で疑うべきポイント

継続的改善

• 予期しない根本原因を文書化
• 効果的な診断コマンドシーケンスを保存
• 問題を解決した具体的なパラメータ値を記録
• 誤解を招きやすい症状をメモ
• 時間節約のショートカットを文書化

参考リンク

• Google Cloud ログの確認
• Kubernetes トラブルシューティング
• PostgreSQL パフォーマンスチューニング
• AlloyDB ドキュメント