AWS CodeDeploy モニタリング・トラブルシューティング完全ガイド ​

デプロイメントは「実行して終わり」ではありません。本当に重要なのは、デプロイが成功したか、アプリケーションが正常に動作しているかを継続的に監視することです。本記事では、CodeDeployの監視の基本概念から実践的なトラブルシューティングまで、初心者の方にも分かりやすく解説します。

なぜデプロイメント監視が重要なのか ​

デプロイメント成功の3つの段階 ​

多くの初心者が誤解していることがあります。「デプロイメントが完了した = アプリケーションが正常に動作している」ではありません。

監視なしのデプロイメントの危険性 ​

監視を怠ると、以下のような問題が発生する可能性があります：

隠れた失敗の見落とし
デプロイは成功したが、アプリケーションが正常に動作していない状況を見逃します。

問題の早期発見機会の喪失
小さな問題が大きな障害に発展する前に対処する機会を失います。

根本原因の特定困難
問題が発生した時に、何が原因かを特定するための情報が不足します。

CodeDeploy監視の全体像 ​

監視すべき4つのレベル ​

CodeDeployの監視は、4つの異なるレベルで行う必要があります：

レベル1：デプロイメント基本監視 ​

標準メトリクスの理解 ​

CodeDeployは、以下の基本メトリクスを自動的にCloudWatchに送信します：

デプロイメント実行メトリクス

インスタンス単位メトリクス

デプロイメント成功率の計算 ​

基本アラームの設定原理 ​

初心者が最初に設定すべき重要なアラーム：

1. デプロイメント失敗アラーム

• 目的: デプロイメントが失敗した際に即座に通知を受け取る
• 監視対象: DeploymentsFailed メトリクス
• 閾値: 1回でも失敗したら通知（Threshold: 1）
• 評価期間: 5分間隔でチェック
• 通知方法: SNS（メール、SMS、Slackなど）

2. 成功率低下アラーム

• 目的: デプロイメントの品質低下を早期に検出
• 計算方法: 成功率 = 成功数 ÷ (成功数 + 失敗数) × 100
• 推奨閾値: 90%未満で警告、95%以上を目標とする
• 重要な理由: 偶発的な失敗ではなく、システム的な問題を示唆する可能性

設定時のポイント:

• 過度に敏感な設定は「アラート疲れ」を起こす原因となる
• ビジネス要件に応じて適切な閾値を設定する
• 段階的なエスカレーション（警告→重要→緊急）を設計する

レベル2：ログ収集と分析 ​

ログ収集の仕組み ​

CodeDeployに関連するログは複数の場所に分散して保存されます：

CloudWatch Agentの基本概念 ​

ログを自動収集するためのCloudWatch Agentの設定における重要なポイント：

設定の基本構造:

• 収集対象ファイル: どのログファイルを監視するか指定
• ロググループ: CloudWatch上での分類・整理方法
• ログストリーム: 個別インスタンスやアプリケーションの識別方法
• 保存期間: コストと要件のバランスを考慮した設定

主要な設定項目:

• file_path: 監視対象のログファイルパス（例: /var/log/aws/codedeploy-agent/）
• log_group_name: CloudWatchでの分類名（例: /aws/codedeploy/agent）
• retention_in_days: ログの保存日数（コスト管理の観点で重要）

初心者向けのベストプラクティス:

• まず必要最小限のログから開始（CodeDeployエージェント、アプリケーションエラーログ）
• ログ量とコストのバランスを考慮した保存期間設定
• 段階的に監視対象を拡大

ログ分析の実践的手法 ​

重要なログパターンの特定

ログ分析の実践的なアプローチ

CloudWatch Logsでの効果的なログ分析手法：

1. エラーログの優先分析

• キーワード検索: "ERROR"、"Failed"、"Exception"でフィルタリング
• 時系列分析: エラー発生の時間的パターンを把握
• 頻出エラー特定: 最も頻繁に発生するエラーメッセージの特定

2. パフォーマンス監視

• 実行時間分析: 各デプロイメントフェーズの実行時間推移
• リソース使用量: CPU、メモリ使用率とデプロイ失敗の関連性
• タイムアウト検出: 設定したタイムアウト値の妥当性検証

3. 傾向分析

• 成功率の推移: 時間経過に伴うデプロイメント品質の変化
• 失敗パターン: 特定の時間帯や条件での失敗頻度
• 復旧時間: 問題発生から解決までの時間測定

初心者向けのコツ: まずは基本的なキーワード検索から始めて、徐々に高度なフィルタリングや集計機能を活用していきましょう。

レベル3：アプリケーション監視 ​

カスタムメトリクスの基本概念 ​

標準メトリクスだけでは把握できない情報を監視するために、独自のメトリクスを追加する方法：

カスタムメトリクスが必要な理由:

• アプリケーション固有のパフォーマンス指標
• ビジネス要件に特化した監視項目
• 詳細なデプロイメント品質評価

主要なカスタムメトリクス例:

1. デプロイメント時間の追跡

• 各フェーズの実行時間を記録
• 全体のデプロイメント所要時間を監視
• 時間の推移による品質劣化の検出

2. アプリケーション応答性能

• ヘルスチェックエンドポイントの応答時間
• データベース接続テストの結果
• 外部API連携の成功率

3. リソース使用状況

• デプロイ時のCPU・メモリ使用率
• ディスク容量の変化
• ネットワーク帯域の使用量

実装時の重要ポイント: メトリクス送信はAWS CLI の put-metric-data コマンドを使用し、適切な名前空間とタイムスタンプを設定することが重要です。

アプリケーション健全性の段階的チェック ​

レベル4：自動化された対応 ​

自動ロールバックの基本概念 ​

問題を早期に検出し、自動的に安全な状態に戻すシステムの重要性：

自動ロールバックが必要な理由:

• 人間の判断を待っている間にサービス影響が拡大
• 夜間や休日のデプロイメント障害への即座の対応
• 一貫性のある障害対応の確保

自動ロールバックの判定基準:

1. 技術的な健全性チェック

• デプロイメント自体の成功・失敗状況
• アプリケーションプロセスの起動状態
• 基本的な接続性テスト（ポート開放、ヘルスチェック）

2. パフォーマンス品質チェック

• エラー率の許容範囲（通常は5%未満）
• 応答時間の品質維持（通常は2秒未満）
• リソース使用率の異常検出

3. ビジネス影響チェック

• ユーザー体験の品質維持
• 重要なビジネス機能の正常動作
• 外部システムとの連携状況

実装時の重要な考慮事項:

• ロールバック自体が失敗するリスクも考慮
• 段階的なロールバック（部分的→完全）の実装
• 適切な通知とログ記録の仕組み

段階的エスカレーション ​

問題の深刻度に応じた段階的な対応：

実践的トラブルシューティング ​

よくある問題と診断手順 ​

問題1: デプロイは成功したが、アプリケーションが応答しない

問題2: デプロイメントが途中で失敗する

デバッグ情報の効果的な収集 ​

デプロイメント時に問題の迅速な特定を可能にする診断情報の収集方法：

診断情報収集の重要性:

• 問題発生時の迅速な原因特定
• 再現困難な問題の証跡保存
• システム状態の可視化による予防保守

収集すべき主要な診断情報:

1. システム基盤情報

• OS版本とカーネル情報
• メモリ使用状況（空き容量、使用率）
• ディスク容量と使用状況
• CPU負荷とプロセス一覧

2. ネットワーク接続情報

• 開放ポート一覧（アプリケーションの待ち受け状態）
• ファイアウォール設定状況
• 外部との通信可能性テスト

3. アプリケーション状態

• 関連プロセスの実行状況
• アプリケーションログの最新エントリ
• ヘルスチェックエンドポイントの応答
• データベース接続などの依存関係チェック

診断情報の活用方法:

• 定期的な自動収集によるベースライン確立
• 問題発生時と正常時の状態比較
• トレンド分析による予防的な問題検出

継続的な改善 ​

メトリクス駆動改善 ​

監視の成熟度レベル ​

まとめ ​

効果的な監視のための重要原則 ​

1. 段階的な実装 - 基本的な監視から始めて、徐々に高度化
2. 適切な閾値設定 - 過度なアラートを避け、本当に重要な問題に集中
3. 自動化の活用 - 繰り返し作業は自動化し、人間は判断に集中
4. 継続的改善 - 監視システム自体も継続的に改善

今すぐ始められる最低限の監視 ​

初心者の方は、まず以下の3つから始めましょう：

1. 基本メトリクスのアラーム設定 - デプロイメント失敗通知
2. CloudWatch Logsの設定 - エラーログの自動収集
3. 簡単なヘルスチェック - アプリケーションの応答確認

適切な監視体制により、CodeDeployを使用したデプロイメントの信頼性を大幅に向上させることができます。最初は簡単な設定から始めて、徐々に高度な監視機能を追加していきましょう。