グローバル金融機関が、Amazon ECS Fargate上に構築した決済処理プラットフォームを運用しています。システムは開発・ステージング・本番の3つのAWSアカウントにわたる42のマイクロサービスで構成され、ピーク時に毎分5万件のトランザクションを処理します。開発言語はJava・Python・Goが混在しています。最近、全トランザクションの0.1%で間欠的な決済失敗が発生していますが、各チームが独立してサービスを監視しているためログフォーマットが不統一でサービス間・アカウント間のリクエスト追跡が存在せず、根本原因の特定が困難です。SREチームの要件は次のとおりです。 ①障害を引き起こしているサービスとコードパスを特定すること ②単一トランザクションについて42サービス全体のログを相関付けること ③顧客が影響を受ける前に性能低下を検知する異常ベースの自動アラートを設定すること ④多言語サービスへのコード変更を最小限に抑えること これらすべての要件を最もよく満たすアーキテクチャはどれですか？
選択肢AのAWS Distro for OpenTelemetry (ADOT) はOpenTelemetry標準に準拠した自動インストルメンテーションライブラリを提供し、Java・Python・Go等の多言語ランタイムに対してアプリケーションコードを変更することなくトレースコンテキストを付与できます。サイドカーコンテナとしてECS Fargateタスク定義に追加するだけで既存コンテナへの影響なしにデプロイ可能です。 AWS X-RayはADOTコレクターが送信したスパンデータを受け取り、マイクロサービス間をまたぐ完全なトレースとサービスマップを生成します。単一決済トランザクションに対して42サービスすべてのトレースをトレースIDで相関付けられるため、遅延・エラーが発生したサービスとコードパスを即座に特定できます。CloudWatch ServiceLensはX-Rayトレース・メトリクス・ログを統合した単一ビューを提供し、サービスマップ上でエラー率とレイテンシーを可視化します。CloudWatch Cross-Account Observabilityを設定することで3アカウントのデータを一元的なモニタリングアカウントから横断参照でき、アカウントごとの個別監視という根本課題を解消します。 選択肢BのCloudWatch Application Insightsは主に.NETやJavaアプリケーションのリソース自動検出・障害分析に特化しており、マイクロサービス間のエンドツーエンドリクエストトレースを生成する機能を持たない。 選択肢CのAmazon OpenSearch Serviceはログ分析基盤として有効だが、各サービスへのKinesis連携追加はコード変更最小化の要件に反し、ネイティブ分散トレーシングもないためAPM（アプリケーションパフォーマンス管理）構築に追加開発が必要になる。 選択肢DのVPC Flow LogsはIPアドレス・ポート・バイト数などネットワークレイヤーのフロー情報を記録するものであり、HTTPトランザクションIDや業務ロジックの呼び出し経路を追跡することは原理的に不可能である。