AWS Certified Developer - Associate (DVA-C02) #12 Domain 4-1 トラブルシューティングと最適化 — オブザーバビリティ

インフラ AWS Certification
読了 5分

#11 デプロイ戦略 までデプロイを終えました。最後のドメインは 18% のトラブルシューティングと最適化です。最初の記事は オブザーバビリティ (observability)、つまり「何が起きているかを見るツール」です。障害を追跡するには、まずログ・指標・トレースを読めるようになる必要があります。

CloudWatch Logs #

アプリケーション・サービスのログを収集・検索・保管します。

概念意味
ロググループ (Log Group)同じアプリケーション・関数のログのまとまり。保持期間を設定
ログストリーム (Log Stream)1 つのソース (インスタンス・実行環境) のログシーケンス
Logs Insightsログを クエリ言語で検索・集計
サブスクリプションフィルターログをリアルタイムで Lambda/Kinesis にストリーミング
  • Lambda はログを 自動的に CloudWatch Logs に記録 します (実行ロールにログ権限が必要)。
  • EC2・オンプレミスは CloudWatch Agent をインストールしてはじめてログ・メモリ・ディスク指標を送ります。

試験の落とし穴: EC2 の メモリ・ディスク使用率はデフォルト指標ではありません。 CloudWatch Agent を入れてカスタム指標として上がってきます。CPU・ネットワークはデフォルトで提供されます。

CloudWatch Metrics #

システム・アプリケーションの数値を時系列で収集します。

  • 標準指標 — AWS サービスが自動提供 (EC2 CPU、Lambda 呼び出し数・エラー・実行時間など)。
  • カスタム指標 — PutMetricData で直接アップロードします (注文数などのビジネス指標)。
  • 高解像度 (High-Resolution) — 1 秒単位まで。デフォルトは 1 分 (または 5 分)。
  • ディメンション (Dimension) — 指標を関数名・環境などで分類するキー・値。

CloudWatch Alarms #

指標がしきい値を外れると動作します。

  • 状態: OK / ALARM / INSUFFICIENT_DATA。
  • アクション: SNS 通知、Auto Scaling、EC2 アクション、デプロイ自動ロールバック。
  • 複合アラーム で複数のアラームを論理条件で束ねられます。

X-Ray — 分散トレーシング #

マイクロサービス・サーバーレスで リクエストが複数のサービスを通りながらどこで遅くなりどこで失敗するか を追跡します。

概念意味
セグメント (Segment)1 つのサービスが処理した作業単位
サブセグメント (Subsegment)セグメント内の詳細な呼び出し (DB クエリ、外部 API など)
トレース (Trace)1 つのリクエストが作ったセグメント全体
サービスマップ (Service Map)サービス間の呼び出し関係・遅延・エラーの可視化
サンプリング (Sampling)一部のリクエストのみ追跡してコスト・負荷を削減
  • Lambda は 有効化トグル + 実行ロール権限 で X-Ray をオンにします。コードに SDK を入れると外部呼び出しまでサブセグメントとして捉えられます。
  • EC2/ECS/オンプレミスは X-Ray デーモン を実行してトレースデータを送信します。
  • 「複数のサービスを経由するリクエストでボトルネック区間を見つけたい」の答えは X-Ray です。

EMF — Embedded Metric Format #

ログに構造化された JSON で指標を一緒に記録すると、CloudWatch がそのログから 自動的にカスタム指標を抽出 します。

  • 別途の PutMetricData API 呼び出しなしに、ログを書くだけで指標を生成。
  • 高カーディナリティのコンテキスト (リクエスト ID など) をログに残しつつ、同時に集計指標を得られます。
  • サーバーレスで API 呼び出しのコスト・遅延なしにカスタム指標を作る推奨方式です。

CloudTrail との区別 #

オブザーバビリティツールを選ぶ問題でよく混同されるペアです。

サービス何を見るか
CloudWatch性能・ログ (「どれだけ速いか/どんなログが出たか」)
X-Rayリクエスト経路・ボトルネック (「どこで遅いか」)
CloudTrailAPI 呼び出しの監査 (「誰がどの API を呼んだか」)

「誰がこのリソースを削除したか」は CloudTrail、「なぜ遅いか」は X-Ray/CloudWatch です。

試験の出題パターン #

  • 「複数のマイクロサービスを通るリクエストのボトルネックを見つける。」 → X-Ray (サービスマップ)。
  • 「EC2 のメモリ使用率をモニタリング。」 → CloudWatch Agent (カスタム指標)。
  • 「ログをクエリで検索・集計。」 → CloudWatch Logs Insights。
  • 「API 呼び出しなしでサーバーレスのカスタム指標を生成。」 → EMF。
  • 「誰が S3 バケットを削除したか。」 → CloudTrail。
  • 「エラー率がしきい値を超えたら通知。」 → CloudWatch Alarm + SNS。
  • 「ビジネス指標 (注文数) を直接記録。」 → カスタム指標 (PutMetricData) または EMF。

よく出会う落とし穴 #

1) EC2 メモリがデフォルト指標だという誤解 #

CPU・ネットワークはデフォルト、メモリ・ディスクは Agent が必要 です。

2) CloudWatch と CloudTrail の混同 #

性能・ログは CloudWatch、API 監査は CloudTrail です。

3) X-Ray をコードだけでオンにしたと考える #

Lambda はトレーシングの有効化 + 実行ロールに X-Ray 権限 が必要です。

まとめ #

この記事の要点:

  • CloudWatch Logs (グループ・ストリーム・Logs Insights・サブスクリプションフィルター)、EC2 メモリは Agent が必要
  • Metrics (標準・カスタム・高解像度・ディメンション) と Alarms (SNS・ロールバック連携)
  • X-Ray — セグメント・サブセグメント・サービスマップ・サンプリングでボトルネックを追跡
  • EMF — ログだけでカスタム指標を抽出 (サーバーレス推奨)
  • CloudWatch (性能)・X-Ray (経路)・CloudTrail (API 監査) の区別

次へ — Domain 4-2 最適化と問題解決 #

何が起きているかを見る方法を整理したので、最後は それを改善し、よくあるエラーを解決する方法 です。#13 最適化と問題解決 では、キャッシュレイヤー、Lambda 性能チューニング、そして試験によく出るエラーコードとトラブルシューティングパターンを整理します。

X