グローバル製造業の大企業が、Amazon ECS Fargate上で動作する25以上のマイクロサービスで構成されたリアルタイム決済処理プラットフォームを3つのAWSリージョンで運用しています。 現在のモニタリング構成は、ECS標準のCloudWatchメトリクス（CPU・メモリ・ネットワーク）と、各サービスが非構造化テキスト形式で出力するアプリケーションログをCloudWatch Logsに集約するものです。 運用チームは以下の深刻な問題を抱えています。 ・問題検知の平均時間（MTTD）が45分（顧客からのクレームで初めて気づくケースが大半） ・問題解決の平均時間（MTTR）が3.5時間 ・個別トランザクションが複数のマイクロサービスをどのように経由したかを追跡できないためボトルネックの特定に長時間を要している ・エンドユーザーへの影響が発生する前にパフォーマンス劣化を検知するプロアクティブな仕組みがない ・多数のメトリクスしきい値アラームによるアラート疲労が発生しており重要なアラートを見逃すリスクがある 運用チームはMTTDを5分以内・MTTRを30分以内に改善し、アラート疲労を解消することを目標としています。 ソリューションは3つのリージョンで一貫して機能し、AWSマネージドサービスを優先して運用管理の複雑さを最小化することが組織方針です。自己管理型ソフトウェアの導入やカスタムアプリケーションの開発は原則として避けるよう指示されています。 Solutionsアーキテクトが推奨すべきソリューションはどれですか？
選択肢Aは X-Ray＋ServiceLensによる分散トレーシングで個別トランザクションの経路とレイテンシを可視化しボトルネック特定を劇的に短縮してMTTRを改善します。CloudWatch Syntheticsの合成監視は顧客影響前にパフォーマンス劣化を検知しMTTDを5分以内に改善する最重要施策です。構造化ログ＋Logs Insightsはマイクロサービスをまたいだアドホック分析を可能にし、Anomaly DetectionはMLで動的ベースラインを学習してアラート疲労を根本解消します。全てAWSマネージドサービスのため3リージョンへの展開も容易です。 選択肢Bは EC2上の自己管理型ELKのメンテナンスコストが高く組織方針に反し、分散トレーシング機能も持ちません。 選択肢Cは カスタム開発が大規模で運用負荷が増大します。 選択肢Dは DevOps GuruはX-Rayのような分散トレーシングを提供せず、QuickSightはリアルタイム運用監視には適していません。