Amazon DVA-C02: モニタリング、ロギングとデバッグ (CloudWatch, X‑Ray, Tracing, Alarms) — 学習ガイド

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Developer Associate DVA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

CloudWatch Logs、メトリクス、ログメトリックフィルター

CloudWatch Logsは、アプリケーションとプラットフォームのテレメトリの主要なパイプラインです。開発者は、MetricsとInsightsがログを確実に解析できるよう、構造化された（JSON）ログを設計すべきです。カスタムアプリケーションメトリクスには、即時のディメンションや高解像度のニーズに対応するため、CloudWatch Embedded Metric Format (EMF)またはPutMetricDataを使用することが推奨されます。EMFはログ行に_aws JSONを埋め込み、CloudWatchが1回のPutLogEvents呼び出しで多数のメトリクスを抽出できるようにすることで、コストとスループットの効率を高めます。サービス側でテキスト形式のログからメトリクスを派生させる必要がある場合は、ロググループに対してメトリックフィルター（PutMetricFilter）を作成し、フィルターパターンをMetricTransformationsにマッピングします。これにより、グラフ化やアラーム設定が可能なCloudWatchメトリクスが生成されます。一般的な運用APIには、CreateLogGroup、CreateLogStream、PutLogEvents（sequenceTokenとPutLogEventsのバッチサイズの制限に注意）、および保管時の暗号化のために顧客管理のKMSキーをロググループにアタッチするAssociateKmsKeyがあります。IAMに注意してください。PutLogEventsとPutMetricDataには明示的な権限が必要であり、KMSのグラントでは、サービスプリンシパルが暗号化のためにキーを使用することを許可する必要があります。コストを管理するために保持ポリシーを使用し、高解像度メトリクス（StorageResolution=1を指定したPutMetricData）は、分未満の可視性が必要な場合にのみ使用することが推奨されます。

分散システムのためのトレーシングとX-Ray

分散トレーシングは、サービス間のリクエストフローを計測し、レイテンシーやエラーが発生している場所を明らかにします。AWS X-Rayは統合されたオプションです。Lambda関数でアクティブトレースを有効にし（Lambda TracingConfig Mode: Active）、API GatewayのステージでX-Rayを有効にして、X-Rayトレースヘッダーを伝播させます。ランタイムでAWS X-Ray SDK（Nodeの場合はaws-xray-sdk-core、Pythonの場合はaws_xray_sdk、Javaの場合はAWSXRayRecorder）を使用して、サブセグメントを作成し、アノテーション（インデックス付き、小さな値）とメタデータ（インデックスなし、大きなオブジェクト）を追加します。X-RayレコーダーでAWS SDKクライアントをラップすることで、ダウンストリームのSDK呼び出しをキャプチャし、SDKがS3、DynamoDB、HTTP呼び出しへのリクエストを自動的に計測するようにします。コンテナ化されたワークロードでは、X-Rayデーモンをサイドカーとして実行するか、デーモンレイヤーを使用します。これはUDPパケット（デフォルトポート2000）を受け付け、X-Rayサービスにバッチ送信します。ノイズを避けるためにサンプリングルール（CreateSamplingRule）を設定しますが、常にトレースしたい重要なフローについては、ルールを調整するか、SDKのオーバーライドを使用します。セグメントドキュメントのサイズ制限に注意し、アノテーションはインデックス化されて検索可能であるため、個人を特定できる情報（PII）を絶対に入れないでください。

アラーム、通知、アラート設計

アラームは、対応可能なイベントを検出し、ノイズを削減し、ランブックと統合されるべきです。CloudWatch Alarmsは、ネイティブメトリクス、カスタムメトリクス（PutMetricDataまたはメトリックフィルターから）、または数式メトリクスで使用します。アラートのバタつきを避けるためにDatapointsToAlarmとEvaluationPeriodsを調整し、アラート量を削減するために、複数のシグナルが絡む条件（ダウンストリームの障害＋エラー率の増加）には複合アラームを使用することが推奨されます。アラームアクションは、人間や自動化ワークフローのためにSNSトピックに発行したり、Auto ScalingやSystems Manager OpsCenter（OpsItemsを作成）を呼び出したり、複雑なプレイブックのためにEventBridgeルール（source: aws.cloudwatch）を介してルーティングしたりできます。迅速なオンコール対応にはSNS -> HTTPエンドポイントまたはPagerDuty連携を使用し、自動修復には最小権限のIAMを持つEventBridge -> Step FunctionsまたはLambdaを使用します。トラフィックのベースライン化のために異常検知モデルを検討し、ヒステリシスを持たせてOKのしきい値を設定します。よくある落とし穴には、ディメンション付きアラームを過剰に作成すること（モニタリングコストの爆発）、単一データポイントのトリガーのみに依存すること、通知トピック（SNSアクセスポリシー）のセキュリティを確保できず、意図しないコンシューマーにアラートが漏洩することが含まれます。

トラブルシューティングのパターンとSDK/APIのプラクティス

トラブルシューティングは、期待されるタイムラインと観測されたタイムラインを比較することから始め、ログ、メトリクス、トレースを関連付けます。CloudWatch Logs Insightsを使用してアドホックなクエリ（フィールド

undefined

）を実行し、スパイクを特定してから、X-Rayトレースに切り替えて詳細なレイテンシーを調査します。LambdaをバックエンドとするAPIでは、コールドスタート、VPC ENIのアタッチ時間（VPC内の関数の場合）、そして非同期呼び出しの失敗をキャプチャするためのLambda DestinationsやDLQが設定されているかを確認します。失敗した呼び出しをキャプチャするには、Lambda Destinations（onFailureでSNS、SQS、またはEventBridgeへ）または非同期DLQを使用してペイロードを保持します。コードを計装する際は、ジッター付きエクスポネンシャルバックオフを実装してAPIスロットリングを処理し、メトリクスフィルターやEMFカウンターを介して429エラーをモニタリングします。よくある落とし穴：PutLogEventsは正しいシーケンストークンを必要とし、先にCreateLogStreamを実行する必要があります。PutMetricDataはスロットリングされる可能性があるため、メトリクスをバッチ処理して集約したものを発行します。X-Rayはxray:PutTraceSegmentsとxray:PutTelemetryRecordsの権限（マネージドポリシーAWSXRayDaemonWriteAccess）を必要とします。また、サンプリングは、低頻度だが重要なフローに対してルールを調整しない限り、問題を隠してしまう可能性があります。

実践的な問題：ユースケースシナリオ

シナリオ：Acme Retail社は、API Gateway -> Lambda -> DynamoDBを使用したサーバーレスのチェックアウトサービスをAWS上で運用しています。チームは中央集権的なCloudWatch LogsとX-Rayを運用していますが、分単位のデバイススループットメトリクスが不足しており、ノイズの多いアラートを生成することなくAPIレイテンシーのスパイクに関する信頼性の高いアラートを必要としています。

課題：分単位のデバイス/メッセージ数をほぼリアルタイムでキャプチャし、遅いリクエストのエンドツーエンドのトレースを確保し、自動修復Lambdaをトリガーしてオンコール担当者に通知する、ノイズの少ないアラームを作成します。

推奨アプローチ：

チェックアウトLambdaを計装し、PutMetricData APIを使用して高解像度のカスタムメトリクス（Namespace=Acme/Checkout, MetricName=DeviceReportsPerMinute, Timestamp=now, Value=1, StorageResolution=1）を発行します。APIスロットリングを避けるため、これらをメモリ内でバッチ処理し、30秒ごとにフラッシュします。
また、より豊富なディメンション（customerId, region）のためにEMF JSONをLambdaログに埋め込み、CloudWatch LogsがPutLogEventsとメトリクスフィルター（PutMetricFilter）を介してエラーカウントなどの追加メトリクスを抽出できるようにします。
X-Rayトレースを有効化します。LambdaのTracingConfig ModeをActiveに設定し、API GatewayステージでX-Rayを有効にし、X-Ray SDKを使用してサードパーティAPIへの外部HTTP呼び出しの周辺にアノテーション（非PII）とサブセグメントを追加します。
高い95パーセンタイルのレイテンシーメトリクス（メトリクス数学）とDeviceReportsPerMinuteのスパイクを組み合わせた複合CloudWatchアラームを作成します。EvaluationPeriods=3, DatapointsToAlarm=2に設定し、アクションとしてオンコールエンドポイントをトリガーするSNSトピックと、修復Lambdaを呼び出すEventBridgeルール（最小権限のロール）を指定します。

論理的根拠：高解像度メトリクスとEMFを発行することで、即時の分単位カウントとより豊富なディメンションの両方が得られます。X-Rayは、ダウンストリームの呼び出しに至るまでレイテンシーの根本原因を提供します。複合アラームは、アラートを発する前に関連する条件を要求することでノイズを低減し、EventBridgeを介した自動化を可能にします。

← セキュリティ、IAM、KMS とシークレット管理 (Cognito · すべてのドメイン · ストレージ、Amazon S3、CloudFront とファイルシステム (EFS →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →