DOPインシデントとイベントへの対応
あるマイクロサービスアプリケーションは、Amazon API Gateway、AWS Lambda、Amazon DynamoDB、および外部の決済プロバイダAPIで構成されている。ユーザーから断続的にレイテンシー増加とタイムアウトが報告されているが、CloudWatch の Lambda メトリクスと API Gateway メトリクスはいずれも正常範囲を示している。DevOpsチームは、エンドツーエンドのどのコンポーネントが遅延を引き起こしているのかを、アプリケーションコードの変更を最小限に抑えつつ迅速に特定したい。最も適切な方法はどれか。
AAWS X-Ray を有効化して API Gateway と Lambda をトレースし、Amazon CloudWatch ServiceLens のサービスマップでダウンストリーム依存（DynamoDB および外部決済API）ごとのレイテンシー分布とエラー率を可視化して、遅延を生んでいるセグメントを特定する。
✓ 正解
X-Ray はリクエストが通過する各依存先をサブセグメント単位で計測し、ServiceLens のサービスマップで DynamoDB や外部決済 API ごとのレイテンシー・エラー率を可視化できる。コード変更を抑えつつ遅延セグメントを特定できる最適解。
BCloudWatch Logs Insights で Lambda 関数のログをクエリし、@duration フィールドを対象に stats 関数でパーセンタイル（p50・p90・p99）を算出したうえで、遅延の大きい呼び出しのタイムスタンプとリクエストIDを抽出して傾向を分析する。
Logs Insights で @duration のパーセンタイルを算出しても、それは Lambda 全体の実行時間にすぎず、外部決済 API や DynamoDB のどの依存先が遅延の原因かを分解できない。コンポーネント特定という要件に届かない。
CAmazon CloudWatch Synthetics のカナリアを作成して API エンドポイントを定期的に呼び出し、エンドツーエンドの可用性とレスポンスタイムを継続的に計測し、しきい値超過時に CloudWatch アラームで通知する監視を構築する。
Synthetics のカナリアはエンドツーエンドのレスポンスタイムや可用性の外形監視には有効だが、内部のどのコンポーネントで遅延が生じているかを分解して特定する用途には対応しない。
DAmazon CloudWatch Contributor Insights で API Gateway のアクセスログを分析対象に設定し、レイテンシーに最も寄与しているクライアントIP・リソースパス・ステータスコードの上位ランキングを継続的に生成して原因を絞り込む。
Contributor Insights はクライアントIPやリソースパス別の上位寄与ランキング抽出に向くが、DynamoDB や外部API などダウンストリーム依存ごとのレイテンシー内訳を可視化する機能ではなく、原因コンポーネントの特定には不十分。
解説
AWS X-Ray は分散トレーシングにより、1 リクエストが通過する各コンポーネント（サブセグメント）ごとの処理時間を計測する。API Gateway と Lambda でトレースを有効化すると、Lambda から呼び出す DynamoDB や外部決済 API への呼び出しもサブセグメントとして記録され、どの依存先が遅延の原因かを分解して把握できる。
CloudWatch ServiceLens はこの X-Ray トレースとメトリクス・ログを統合し、サービスマップ上で各ダウンストリームのレイテンシー分布やエラー率を可視化するため、コード変更を最小限に抑えつつ根本原因のセグメントを迅速に特定できる。
選択肢Bの Logs Insights は Lambda 全体の実行時間は集計できるが、外部決済 API や DynamoDB のどこで時間を要したかを分解できない。
選択肢Cの Synthetics は外形監視でレスポンスタイムの傾向は掴めるが、内部のどのコンポーネントが原因かは特定できない。
選択肢Dの Contributor Insights はクライアントIPやパス別の上位寄与要因を抽出するが、ダウンストリーム依存ごとのレイテンシー分解には向かない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →