DVA-C02 D4 トラブルシュート徹底解説（2025年最新）｜X-Ray・CloudWatch Logs Insights

1. D4「トラブルシュート・最適化」出題範囲と配点

本記事は「AWS DVA-C02 試験対策」シリーズの Vol4 です。
DVA-C02（AWS Certified Developer – Associate）は、AWSサービスを使って実践的なアプリケーション開発・運用ができる開発者向けの資格です。

本記事が扱う D4「Troubleshoot and Optimize AWS Services（AWSサービスのトラブルシュートと最適化）」は配点18%、LMS問題バンク換算74問 を占めます。

D4 がほかのドメインと大きく異なるのは、SAA-C03（Solutions Architect – Associate）では出題されないドメイン であることです。
つまり、D4はDVA-C02固有の「開発者視点でのトラブルシュート能力」を問う内容であり、試験における差別化ポイントになります。
X-Ray による分散トレーシング、CloudWatch Logs Insights によるログ分析、EMF によるカスタムメトリクス、SDK例外処理といった実践的な観点が中心です。

1-1. D4 の出題領域（公式タスクステートメント）

公式試験ガイドは D4 を2つのタスクステートメントで定義しています。

「何がおかしいかを見つけ、どう直し、どう改善するか」という一連の流れを問うのが D4 の本質です。
まず可観測性の全体像を把握し、各ツールの役割分担を整理しましょう。

2. 可観測性の三本柱（ログ・メトリクス・トレース）

分散システムで問題を発見・解決するには、「可観測性（Observability）」が不可欠です。
可観測性はシステムの内部状態を外部から観測できるかどうかを示す概念であり、実践の場では ログ・メトリクス・トレース の三本柱で実現します。

三本柱はそれぞれ異なる問いに答えます。
「いつ何のエラーが発生したか」はログ、「どのくらいの頻度でエラーが起きているか」はメトリクス、「あのAPIコールがどこで遅くなっているか」はトレースで解析します。
DVA-C02 の試験では「どのサービスを使えばこの問いに答えられるか」を問う問題が頻出です。

2-1. CloudWatch の役割

Amazon CloudWatch は AWS における可観測性の中心的なサービスです。
ログ（CloudWatch Logs）・メトリクス（CloudWatch Metrics）・アラーム（CloudWatch Alarms）を一元的に提供します。
Lambda・API Gateway・SQS・ECS などほぼすべての AWS サービスが、デフォルトで CloudWatch にメトリクスを送信します。
カスタムアプリケーションのデータも PutMetricData API や EMF で取り込めます。

2-2. X-Ray の役割

AWS X-Ray はトレーシングに特化したサービスです。
マイクロサービスや Lambda 関数間のリクエストフローを可視化し、ボトルネックや障害発生箇所を特定します。
X-Ray は他の可観測性ツール（CloudWatch Application Signals など）とも連携し、分散システム全体の可観測性を高めます。

3. CloudWatch Logs Insights とログ分析

CloudWatch Logs Insights は、CloudWatch Logs に保存されたログデータを 専用のクエリ言語 でリアルタイムに分析するサービスです。
複数のロググループをまたがってクエリを実行でき、エラーの特定・傾向分析・集計が素早く行えます。

3-1. Logs Insights クエリ構文

Logs Insights のクエリは6つのコマンドで構成されます。

よく使うパターン: エラー件数を5分ごとに集計する場合は次のように書きます。

fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as errorCount by bin(5m)
| sort @timestamp desc

3-2. ロググループ横断クエリ

Logs Insights は複数のロググループを同時にクエリできます。
マイクロサービスが複数の Lambda 関数に分散している場合に、複数のロググループをまとめて分析できるため、問題の特定が格段に速くなります。
コンソールでは最大50個のロググループを同時選択できます。

3-3. サブスクリプションフィルター（Logs → 別サービスへのリアルタイム転送）

特定のログパターンに一致したログを、リアルタイムで別サービスへ転送する機能です。

サブスクリプションフィルターはロググループごとに最大2件設定できます。
ログの転送には若干の遅延（数秒〜数十秒）が生じるため、リアルタイム性が重要な場合は考慮が必要です。

4. カスタムメトリクスとEMF（Embedded Metrics Format）

4-1. PutMetricData によるカスタムメトリクス

AWS サービスが自動送信するメトリクスでカバーできない指標は、アプリケーション側から PutMetricData API を使って CloudWatch に送信できます。
例えば、ビジネスKPI（注文件数・決済成功率）やアプリ固有の処理時間などが対象です。

カスタムメトリクスは 標準解像度（1分単位） と 高解像度（1秒単位） の2種類があります。
高解像度メトリクスはコストが高くなりますが、Lambda関数の短時間スパイクなどを細かく捕捉できます。

4-2. EMF（Embedded Metrics Format）の仕組み

EMF は、ログに JSON 形式でメトリクスデータを埋め込むことで、別途 API 呼び出しなしに CloudWatch Metrics を生成する仕組みです。
Lambda 関数のログとして出力するだけでメトリクスが自動的に作成されるため、コードをシンプルに保てます。

EMF の JSON 構造は次のようになります。

{
  "_aws": {
 "Timestamp": 1700000000000,
 "CloudWatchMetrics": [
{
  "Namespace": "MyApp/Orders",
  "Dimensions": [["FunctionName", "Environment"]],
  "Metrics": [
 { "Name": "OrderProcessingTime", "Unit": "Milliseconds" },
 { "Name": "OrderCount", "Unit": "Count" }
  ]
}
 ]
  },
  "FunctionName": "process-order",
  "Environment": "production",
  "OrderProcessingTime": 123,
  "OrderCount": 1
}

_aws.CloudWatchMetrics ブロックにメトリクスの定義を書き、残りのフィールドに実際の値を入れるのが基本構造です。
EMF は CloudWatch Logs エージェントが自動的に検知し、メトリクスを生成します。

4-3. EMF の利点

Lambda 関数では EMF ライブラリ（aws-embedded-metrics）を使うことで、EMF 形式の出力を簡単に実装できます。

5. X-Rayによる分散トレーシング（サービスマップ・アノテーション）

AWS X-Ray は、マイクロサービスや Lambda 関数を含む分散アプリケーションのリクエストフローを追跡・可視化するサービスです。

5-1. Trace・Segment・Subsegment の関係

X-Ray のデータ構造は階層化されています。

例えば、API Gateway → Lambda → DynamoDB という流れを追う場合、API Gateway と Lambda でそれぞれ Segment が生成され、Lambda から DynamoDB への呼び出しが Subsegment として記録されます。

5-2. Annotations と Metadata の違い

X-Ray のトレースデータにはカスタムデータを付加できます。
試験で最も問われる違いは次の点です。

検索・絞り込みが必要なデータは Annotations、詳細なデバッグ情報は Metadata に格納します。
Annotations は文字列・数値・真偽値のみ対応で、Metadata は任意の JSON オブジェクトを格納できます。

5-3. サンプリングルール

X-Ray はすべてのリクエストをトレースするとコスト・パフォーマンスへの影響が大きくなるため、サンプリングによりトレース対象を絞ります。

デフォルトのサンプリングルールは「毎秒最初の1リクエスト + 以降の5%」です。
カスタムサンプリングルールを使うと、特定のパスやサービスのみ100%トレースするといった細かい制御が可能です。

5-4. Lambda での X-Ray 有効化

Lambda 関数で X-Ray トレースを有効にするには、コンソールまたは SAM/CloudFormation の設定で TracingConfig: Active を指定します。
Active モードは自動的にトレースをサンプリングし、PassThrough は上流サービスのサンプリング判定に従います。
X-Ray SDK をコードに統合することで、Subsegment の追加やアノテーションの付加も行えます。

6. HTTPエラーコードとSDK例外の対応表

AWS API を利用するアプリケーションでは、HTTP ステータスコードと AWS SDK 例外の対応関係を正確に理解することがトラブルシュートの基本です。

6-1. 主要な HTTP エラーコード

試験の頻出ポイント: 403 は IAMポリシー・SCP・VPCエンドポイントポリシーによるアクセス拒否、429 はスロットリング（API Gateway・Lambda・DynamoDB）を意味します。

6-2. AWS SDK 例外とリトライ戦略

AWS SDK は自動的にリトライしますが、例外の種類によって適切な対処が異なります。

Exponential Backoff + Jitter: リトライ間隔を指数的に増やしつつ、ランダムなジッター（ゆらぎ）を加えることで、複数クライアントのリトライが同時に集中することを防ぎます。
AWS SDK はデフォルトでこの戦略を実装しています。

7. SQS/SNSのトラブルシュート（DLQ・可視性タイムアウト）

7-1. SQS のトラブルシュートポイント

SQS（Simple Queue Service）のトラブルシュートで最も重要な概念は 可視性タイムアウト（VisibilityTimeout） と DLQ（Dead Letter Queue） です。

可視性タイムアウト（VisibilityTimeout）:
コンシューマーがメッセージを受信すると、そのメッセージは一時的に他のコンシューマーから見えなくなります（非表示状態）。
非表示の時間が可視性タイムアウトで、デフォルトは30秒、最大12時間です。
可視性タイムアウトより処理時間が長くなると、同じメッセージが再配信されて重複処理が発生します。

DLQ（Dead Letter Queue）:
最大受信回数（maxReceiveCount）を超えたメッセージを DLQ に転送します。
DLQ を設定することで、処理不能メッセージを本キューから分離し、エラー分析・再処理が容易になります。

7-2. SQS キュータイプの使い分け

FIFO キューはスループットが Standard より低く（デフォルト300TPS）、コストも高くなります。
Lambda との統合では、FIFO キューの場合 MessageGroupId ごとに順序保証した処理が行われます。

7-3. SNS の配信トラブルシュート

SNS がサブスクライバーに配信できない場合のポイントです。

8. Lambda/APIの並行性最適化

8-1. Lambda 並行性の種類

Lambda の並行性には3つの設定があります。

コールドスタート問題: Lambda 関数は初回（または一定時間後の）実行時に実行環境の初期化が発生します（コールドスタート）。
プロビジョニング済み同時実行を使えば実行環境をウォームアップ状態で保持でき、リクエスト到着時から即座に処理を開始できます。

8-2. スロットリング（TooManyRequestsException）

Lambda の同時実行制限に達すると、新しいリクエストは ThrottleError（HTTP 429） が返されます。
Lambda の呼び出し方によって挙動が異なります。

8-3. API Gateway のスロットリング

API Gateway にはリクエストレートのスロットリング設定があります。

スロットリングを超えたリクエストには 429 Too Many Requests が返されます。
使用量プランとAPIキーを組み合わせることで、テナント（顧客）ごとに異なるリクエスト制限を設けられます。

8-4. Lambda コールドスタートの最適化

コールドスタートを軽減するための主な手法です。

1. プロビジョニング済み同時実行の設定: 最も確実な解決策ですがコストが発生します
2. デプロイパッケージのサイズ削減: 初期化時間の短縮（不要な依存関係を除外）
3. ランタイム選択: Python/Node.js は Java/C# より起動が速く、コールドスタートの影響を受けにくい傾向があります
4. Lambda SnapStart（Java向け）: スナップショットからの高速起動（Java 11 以降）
5. VPC 設定の見直し: VPC 内 Lambda では初期化時に ENI アタッチの処理を経る場合があります（現在は大幅に改善済み）

9. SNSサブスクリプションフィルター

SNS のサブスクリプションフィルターポリシー（Subscription Filter Policy）は、メッセージ属性（MessageAttributes）に基づいてサブスクライバーへの配信を制御する機能です。

9-1. フィルターポリシーの仕組み

フィルターポリシーは JSON 形式で記述し、サブスクリプション単位で設定します。
ポリシーに一致するメッセージのみがそのサブスクライバーに配信されます。

フィルターポリシーを設定した場合、ポリシーに一致しないメッセージはそのサブスクライバーには配信されません。
フィルターポリシーがない場合はすべてのメッセージが配信されます。

9-2. フィルターポリシーの記述例

{
  "store": ["example_corp"],
  "event": [{"anything-but": "order_cancelled"}],
  "price": [{"numeric": [">=", 100, "<=", 500]}],
  "premium_user": ["true"]
}

9-3. フィルターポリシースコープ

2022年以降、フィルターポリシーのスコープとして MessageBody フィルタリングが追加されました。
FilterPolicy のスコープを MessageBody に設定すると、メッセージ本文の JSON フィールドに対してフィルタリングを適用できます（従来の MessageAttributes スコープとは異なります）。

10. CloudWatch Alarms と通知設計

10-1. CloudWatch Alarms の基本

CloudWatch Alarms はメトリクスの値を監視し、閾値を超えた場合にアクションを実行します。

アラームの状態は3つです。

アラームのアクションとして設定できる主なものは次のとおりです。

• SNS 通知: メール・Lambda・HTTP エンドポイントへの通知
• EC2 アクション: 停止・再起動・回復・終了
• Auto Scaling アクション: スケールアウト・スケールイン

10-2. Composite Alarm（複合アラーム）

Composite Alarm は複数のアラームを論理演算（AND/OR）で組み合わせた複合アラームです。
個々のアラームがノイズを多く発生させる場合でも、複数条件が同時に成立した場合のみ通知するといった制御が可能です。

使用例: 「CPU 使用率が高い AND エラー率も高い」の両方が成立した場合のみアラームを発報し、単独のメトリクス悪化では通知しない、といった設定が可能です。

10-3. Anomaly Detection（異常検知）

CloudWatch Anomaly Detection は機械学習を使って、メトリクスの通常パターン（ベースライン）を自動的に学習し、異常を検知します。
曜日・時間帯による変動（営業時間帯の高負荷など）を学習してベースラインを構築するため、固定閾値では対応しにくいメトリクスに有効です。

異常検知アラームでは「ベースライン ± N σ」の範囲を外れた場合にアラームを発報するよう設定します。

10-4. メトリクスフィルター（ログからメトリクスを生成）

CloudWatch Logs のログデータからメトリクスを抽出する機能です。
例えば、Lambda 関数のログに出力されたエラーメッセージの件数をメトリクス化し、アラームを設定できます。

# エラーパターンに一致する行数をメトリクスとして記録する設定例
フィルターパターン: [timestamp, requestId, level = "ERROR", ...]
メトリクス名前空間: MyApp/Lambda
メトリクス名: ErrorCount
値: 1

11. CertTrend LMS で400問チェック

本シリーズで解説したD1〜D4の内容は、CertTrend LMS の DVA-C02 問題バンク（400問） で実践的に確認できます。
実際の試験と同じ選択式で繰り返し演習することで、知識の定着とスコアアップが図れます。

関連記事（実務での深掘り）

D4 の内容をさらに深く学びたい方は、以下の本番運用解説記事も参照してください。

Vol0 ロードマップで学習計画を確認

DVA-C02 試験対策の全体像は Vol0 ロードマップ記事でまとめています。
各ドメインの出題比率・おすすめ学習順序・受験申込の手順は以下からご確認ください。