変更要約: in-scopeサービス網羅(軸B): s1(CloudWatch)にAthena/OpenSearch Serviceによる大規模ログ分析の定義・役割・選択基準を追記。
5.2X-Ray による分散トレースとデバッグ
AWS X-Ray による分散トレース（リクエストの経路と各区間の遅延）、ボトルネックやエラーの特定、サービスマップといったデバッグ手法を理解します。
複数サービスにまたがる処理では「どこで遅い/失敗しているか」の把握が難しくなります。AWS X-Ray はリクエストを追跡し、各区間の遅延やエラーを可視化します。
5.2.1トレースとサービスマップ
- トレース：1リクエストが通る各サービスの区間（セグメント）と遅延を記録する。
- サービスマップ：サービス間の依存と健全性を図で可視化する。
- 遅い区間やエラー率の高い区間を特定し、ボトルネックの切り分けに使う。
X-Ray の構造を押さえます。1リクエスト全体が トレース、各サービスでの処理区間が セグメント、その内部の細かい処理（DB 呼び出しなど）が サブセグメント です。全リクエストを記録すると重いので サンプリング で一部だけ取得し、コストと網羅性のバランスを取ります。注釈（Annotation） はインデックス付きでフィルタ検索でき、メタデータ（Metadata） は検索対象外の付加情報です。Lambda や API Gateway は設定で アクティブトレースを有効化でき、EC2/ECS では X-Ray デーモン（またはサイドカー）がトレースを送信します。アプリには SDK を組み込み、外部呼び出しを計測します。サービス間でトレースをつなぐには トレースヘッダー（X-Amzn-Trace-Id） が伝播される必要があります。可視化された サービスマップ で、エラー率やレイテンシが高いノードを一目で特定できます。
| 用語 | 意味 |
|---|---|
| トレース | 1リクエスト全体の記録 |
| セグメント | 各サービスでの処理区間 |
| サブセグメント | 区間内の細かい処理（DB 呼出等） |
| サンプリング | 一部のみ記録しコストを抑制 |
シナリオ：API のレスポンスが時々遅い。 Lambda と API Gateway のアクティブトレースを有効化し、X-Ray のサービスマップでレイテンシの高いノードを特定。トレースを開くと外部 API のサブセグメントが 210ms で支配的——ボトルネックは外部依存と切り分けられます。注釈にユーザー ID を入れておけば、特定ユーザーの遅延だけ絞り込めます。
Q. どこが遅いか知りたい。 X-Ray の分散トレース。Q. 全部記録するの？ いいえ、サンプリングで一部。Q. 検索でフィルタしたい値は？ 注釈（インデックス付き）。Q. ログとの違いは？ ログ＝何が起きたか、X-Ray＝どこで時間がかかったか（補完関係）。
混同に注意：
①X-Ray は「どこで時間がかかったか」、ログは「何が起きたか」——置き換えではなく補完。
②検索でフィルタしたい値は注釈に入れる（メタデータは検索不可）。
③サービス横断でトレースをつなぐにはトレースヘッダーの伝播が必要。
5.2.2この節のまとめ
- X-Ray＝分散トレースで各区間の遅延/エラーを可視化
- サービスマップで依存と健全性を把握、ボトルネックを切り分け
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 複数サービスにまたがるリクエストの、どの区間で遅延しているかを特定したい。最も適したサービスはどれですか？
Q2. X-Ray がサービス間の依存関係と健全性を図で示す機能はどれですか？
Q3. 「何が起きたか」を示すログと、「どこで時間がかかったか」を示すトレースの関係として正しいものはどれですか？