決済処理サービスを提供する企業がAWS上で以下のサーバーレスアーキテクチャを運用しています。 【現在の構成】 ・Amazon API Gateway（REST API）→ AWS Lambda（Node.js、12関数）→ Amazon Aurora PostgreSQL ・補助呼び出し：Amazon DynamoDB（セッションデータ）、Amazon SQS（非同期処理）、外部決済ネットワークAPI（サードパーティ） ・1トランザクションあたり平均8〜10個のLambda呼び出しが発生 ・SLA（Service Level Agreement：サービスレベル合意）：99.9%のリクエストを3秒以内に完了させること 【問題】 ・リクエストの約2〜3%が3秒を超えており、SLAを違反している ・どのサービス・どの処理ステップが遅延を引き起こしているか特定できていない 【現在の監視体制】 ・各Lambda関数個別のCloudWatch Logs・CloudWatch Metricsのみ ・サービス間の呼び出し連鎖を追跡する手段がない ・CloudWatchアラームはDurationの平均値に基づく静的閾値のみ SLAを改善するために、サービス間のエンドツーエンドのトレーシングを確立し遅延の根本原因を特定するために実施すべき変更を2つ選んでください。
X-Rayアクティブトレーシングを有効化するとAPI Gateway→Lambda間のトレースコンテキストが自動伝播し、X-Ray SDKでサブセグメントを追加すれば各DBクエリや外部API呼び出しの個別レイテンシが計測できます。X-Rayサービスマップでボトルネックサービスが視覚化されます。デフォルトサンプリング（5%前後）では遅延リクエストを見逃す可能性があるため、重要エンドポイントを100%サンプリングに設定し、X-Ray Analyticsで遅延パターンを絞り込むことが効果的です。 選択肢Bの Lambda Insightsは個別Lambda内部メトリクスを提供しますが、サービス間のトレース伝播はなく8〜10サービスにまたがる手動ログ相関は現実的ではありません。 選択肢Dの Syntheticsカナリアは外形監視に有効ですが、内部サービス呼び出しのトレース情報は提供されず根本原因特定には不十分です。 選択肢Eの OpenSearchへのメトリクス転送はサービスごとの傾向把握には役立ちますが、リクエスト単位のトレース（どのリクエストがどこで遅延したか）は得られず、構成の複雑さとコストも増大します。