マイクロサービスアーキテクチャでは、1つのリクエストが複数のサービスをまたいで処理されます。どこでレイテンシが発生しているかを特定するために不可欠なのがAWS X-Rayです。

SAA レベル：基礎概念

X-Rayの基本概念

セグメント: 1つのサービス（Lambda関数、EC2上のアプリ等）内での処理の記録
サブセグメント: セグメント内のより詳細な処理単位（DB呼び出し、外部API呼び出し等）
トレース: 1つのリクエストが複数サービスを経由した際の、すべてのセグメントをつなげた全体像

SAA 試験のポイント

X-Rayを使うには、アプリケーションにX-Ray SDKを組み込むか、対応サービス（Lambda、API Gateway等）でX-Rayトレーシングを有効化する必要があります。多くのマネージドサービスでは設定を有効化するだけで自動的にトレースが収集されます。

サービスマップ

X-Rayコンソールで、リクエストがどのサービスを経由し、それぞれでどれだけの時間がかかったかを**視覚的なグラフ（サービスマップ）**として確認できる

SAP レベル：高度な設計シナリオ

マイクロサービス間のボトルネック特定

SAP 試験のポイント

「ユーザーからのリクエストが遅い」という漠然とした問題に対し、X-Rayのトレースを分析することで、具体的にどのサービス（例: 決済サービスの外部API呼び出し）がレイテンシの大部分を占めているかを特定できます。SAPでは、複数のマイクロサービスにまたがるパフォーマンス問題を、ログの手動突合ではなくトレースIDで一貫して追跡する設計の重要性が問われます。

アノテーションとメタデータによる高度な分析

SAP 試験のポイント

X-Rayのセグメントにアノテーション（インデックス化され検索可能なキーバリュー、例: customer_tier=premium）を付与することで、「プレミアム顧客のリクエストだけのレイテンシ傾向」といった、ビジネス的に意味のある切り口でのトレース分析が可能になります。単なる技術的なトレースだけでなく、ビジネスコンテキストを組み込んだ可観測性設計がSAPレベルで評価されます。

設計上の落とし穴

「全リクエストを100%トレースする」という設計は、高トラフィックなシステムではX-Rayのコストとオーバーヘッドが無視できなくなる場合があります。SAPレベルでは、サンプリングルールを使い、通常のリクエストは一定割合（例: 5%）のみトレースしつつ、エラーが発生したリクエストは100%トレースする、といったコストと可観測性のバランスを取った設計が問われます。

CloudWatch・OpenTelemetryとの統合

X-Rayのトレースデータは、CloudWatchのメトリクスやログと組み合わせて、統一されたダッシュボードで確認できる
業界標準のOpenTelemetryにも対応しており、マルチクラウド環境や、将来的にベンダーロックインを避けたい構成でも活用しやすい設計になっている

まとめ

SAA: X-Rayのセグメント・サブセグメント・トレースの基本概念、サービスマップによる可視化を理解する。
SAP: トレースIDによるマイクロサービス間のボトルネック特定、アノテーションによるビジネスコンテキストの付与、サンプリングルールによるコストとのバランス設計ができる。

次は **IaC運用（CloudFormation StackSets、AWS CDK）**を見ていきましょう。