AWS X-Ray とは？ ​

マイクロサービスアーキテクチャやサーバーレスアプリケーションが普及するにつれ、システムは複雑化し、障害発生時の原因究明が難しくなっています。 「あるリクエストが遅い」という問題が発生したとき、それがデータベースのせいなのか、外部APIのせいなのか、あるいはコードの処理効率が悪いのかを特定するのは容易ではありません。

AWS X-Ray は、このような分散アプリケーションを分析・デバッグするためのサービスです。 リクエストがアプリケーション内をどのように流れていくかを追跡（トレース）し、パフォーマンスのボトルネックやエラーの原因を特定するのに役立ちます。

1. X-Ray の主な機能 ​

分散トレーシング (Distributed Tracing) ​

ユーザーのリクエストがアプリケーションのエンドツーエンドでどのように処理されたかを記録します。 API Gateway → Lambda → DynamoDB といったサービス間の呼び出し連鎖を一つの「トレース」として可視化できます。

サービスマップ (Service Map) ​

トレースデータを元に、アプリケーションを構成するサービス間の依存関係を自動的に図式化します。 各ノード（サービス）のレイテンシーやエラー率が色分け（緑：正常、赤：エラー、黄：スロットリングなど）で表示されるため、一目で問題箇所を把握できます。

X-Ray Insights ​

異常な振る舞いを自動検出し、根本原因（Root Cause）を特定する分析機能です。 手動でログを掘り下げることなく、いつ、どこで問題が発生したかのインサイトを提供します。

2. 重要な基本概念 ​

X-Ray を理解するための用語を整理します。

  • セグメント (Segment): 個々のサービス（例: Lambda関数）内での処理単位です。リクエストの開始・終了時間、ステータスなどが記録されます。
  • サブセグメント (Subsegment): セグメント内のさらに細かい処理（例: DynamoDBへのクエリ、外部HTTPコール）です。コードのどの行が時間を費やしているかを詳細に分析できます。
  • トレース (Trace): 1つのリクエストに関連する全てのセグメントを集めたものです。リクエストID（Trace ID）によって紐付けられます。
  • サンプリング (Sampling): 全てのリクエストを記録するとコストと負荷が高くなるため、統計的に有意な一部のリクエストのみを記録する仕組みです。

3. 仕組みとアーキテクチャ ​

X-Ray がデータを収集する仕組みは主に以下の2つです。

X-Ray SDK + X-Ray Daemon ​

従来からの標準的な方法です。 アプリケーションコードに X-Ray SDK を組み込み、データをローカルで動作する X-Ray Daemon に送信（UDP）します。Daemon がバッファリングしてまとめて AWS X-Ray バックエンドに送信します。

AWS Distro for OpenTelemetry (ADOT) ​

現在推奨されている新しい方法です。 ベンダーニュートラルな OpenTelemetry (OTel) の標準SDKを使用し、ADOT Collector を経由して X-Ray にデータを送信します。 ※ 詳細は AWS Distro for OpenTelemetry (ADOT) とは？ をご覧ください。

4. いつ X-Ray を使うべきか？ ​

  • マイクロサービス環境: 多数のサービスが連携するシステムで、どこが遅いのかわからない場合。
  • サーバーレス開発: Lambda や API Gateway など、インフラが見えない環境でのパフォーマンス分析が必要な場合。
  • ボトルネックの特定: SQLクエリや外部APIの応答時間を正確に計測したい場合。

まとめ ​

AWS X-Ray は、複雑なモダンアプリケーションの「レントゲン写真」を撮るようなツールです。 CloudWatch だけでは見えない「リクエストの中身」と「サービス間のつながり」を可視化することで、迅速なトラブルシューティングと継続的なパフォーマンス改善が可能になります。

まずは、主要な Lambda 関数や ECS サービスに導入して、サービスマップを見てみることから始めてみましょう。