AWS X-Ray 完全ガイド v2.0

分散トレーシングとサービスマップによる可観測性実現

AWS X-Ray は、マイクロサービス・Lambda・コンテナアプリケーションのリクエストをエンドツーエンドでトレースし、レイテンシ・エラー・依存関係を可視化する 分散トレーシングサービス です。2024年からOpenTelemetry（OTel）への移行を加速し、2026年2月にX-Ray SDKsがメンテナンスモード、2027年2月にEOSを迎えます。本ドキュメントはX-Rayの本質・アーキテクチャ・実装パターン・2026年の最新動向を体系的に解説します。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： X-Rayとは何か、なぜマイクロサービスで必須かを学びたい方
• 開発者向け： Lambda・ECS・EKS アプリケーションのトレーシングを実装したい方
• SRE / 運用向け： サービスマップでシステム全体の依存関係を可視化したい方
• 意思決定者向け： OpenTelemetry・Jaeger・Datadog APM・Honeycombとの比較検討

2025-2026年のX-Ray最新動向

• OpenTelemetry SDKsへの移行（2026年2月メンテナンスモード、2027年2月EOS）：X-Ray SDKsは2025年末でメンテナンスモード入り、ADOT（AWS Distro for OpenTelemetry）またはネイティブOTelが推奨実装パス
• CloudWatch Application Signals統合強化：X-Ray トレース + Application Signals SLOで、トレース詳細と目標達成率を統合分析
• Transaction Search（CloudWatch Logs統合）：トレーススパン単位でLogs Insightsで全文検索・フィルタリング可能に
• ADOT コレクタの拡張：Go・Java・Python・JavaScript・.NETの自動計装（ゼロコード）でX-Ray互換トレース送信
• Lambda Extension（ネイティブサポート）：Lambda実行環境でトレース収集・送信の自動化
• 複数リージョンのトレース集約：X-Ray APIでリージョン間のトレースフェデレーション

目次

1. 概要
2. X-Rayが解決する課題
3. 主な特徴
4. アーキテクチャ
5. コアコンポーネント
6. トレーシング計装の方式
7. 主要ユースケース
8. 設定・操作の具体例
9. 類似サービス比較
10. ベストプラクティス
11. トラブルシューティング
12. 2025-2026最新動向
13. 学習リソース
14. 導入ロードマップ
15. 実装チェックリスト
16. まとめ
17. 参考文献

概要

初心者向けメモ： X-Rayは「マイクロサービスの診察用MRI」です。単一の物理的マシンなら top コマンドで全体の様子が見えますが、マイクロサービスでは「どこでレイテンシが増えているのか」を発見するのが困難。X-Rayは複数のマイクロサービスを経由するリクエストの全経路を追跡し、各サービスでの実行時間を可視化してボトルネックを特定します。

X-Rayはマイクロサービス・Lambda・コンテナアプリケーションのリクエストをエンドツーエンドで追跡（トレース）し、各コンポーネント間のレイテンシ・エラー率・依存関係を サービスマップ として可視化します。CloudWatch Logsと異なり、トレーシングに特化しており、「API Gateway → Lambda（200ms）→ DynamoDB（800ms）→ 外部API（100ms）」といった各段階の実行時間を自動キャプチャして分析できます。

X-Rayの位置づけ

マイクロサービスの可観測性スタックにおいて：

• メトリクス：CloudWatch Metricsで集約的な傾向把握
• ログ：CloudWatch Logsで詳細なテキストベース検索
• トレース：X-Rayでリクエスト全体の依存関係・レイテンシ追跡（本サービス）

X-Rayが解決する課題

X-Rayは、マイクロサービス環境における次の問いに答えるための基盤です。

主な特徴

アーキテクチャ

【図1】X-Rayトレーシングデータフロー：

graph TD
    subgraph ClientLayer[クライアント層]
        CLT["クライアント<br/>HTTP リクエスト"]
    end

    subgraph InstrumentationLayer[計装層]
        APIGW["API Gateway<br/>トレース ID 生成<br/>X-Amzn-Trace-Id"]
        Lambda["Lambda関数<br/>X-Ray SDK or ADOT"]
        EC2["EC2/ECS/EKS<br/>CloudWatch Agent<br/>or ADOT Collector"]
    end

    subgraph DataCollection[トレースデータ収集]
        XDAEMON["X-Ray Daemon<br/>UDP:2000"]
        OTEL["ADOT Collector<br/>OTLP Protocol"]
    end

    subgraph XRayService[X-Ray Service]
        XCORE["X-Ray Core<br/>Segment Storage"]
        SERVICEMAP["Service Map<br/>自動生成"]
        INSIGHTS["Insights<br/>異常検知"]
    end

    subgraph Integration[統合サービス]
        CWLOGS["CloudWatch Logs<br/>Insights Integration"]
        APPSIGNALS["Application Signals<br/>SLO Dashboard"]
        CLOUDWATCH["CloudWatch<br/>Custom Metrics"]
    end

    CLT -->|HTTP| APIGW
    APIGW -->|TraceID Propagation| Lambda
    APIGW -->|TraceID Propagation| EC2
    Lambda -->|Segments/Spans| XDAEMON
    Lambda -->|OTLP| OTEL
    EC2 -->|Segments| XDAEMON
    EC2 -->|OTLP| OTEL
    XDAEMON -->|JSON Upload| XCORE
    OTEL -->|Translation| XCORE
    XCORE -->|Service Mesh| SERVICEMAP
    XCORE -->|Analysis| INSIGHTS
    XCORE -.->|Trace Lookup| CWLOGS
    XCORE -.->|Metrics| APPSIGNALS
    XCORE -.->|Custom Metrics| CLOUDWATCH

コアコンポーネント

1. トレース（Trace）

定義： 単一のユーザーリクエストが複数のサービスを経由する全経路。トレース ID（X-Amzn-Trace-Id ヘッダー）で一意に識別。

トレース: 1 リクエスト全体（例：注文処理）
├─ トレースID: 1-5e6722a7-cc2xmpl46db7ae98d0da47ae
├─ 開始時刻: 2026-04-26T10:30:00Z
├─ 終了時刻: 2026-04-26T10:30:02.345Z
└─ 総レイテンシ: 2345ms

2. セグメント（Segment）

定義： 1つのサービス（Lambda関数、EC2インスタンス、コンテナ）がリクエストを処理する過程。

{
  "name": "OrderAPI",
  "namespace": "aws",
  "trace_id": "1-5e6722a7-cc2xmpl46db7ae98d0da47ae",
  "id": "70de5b6f19ff9a0a",
  "start_time": 1614556200.000,
  "end_time": 1614556202.345,
  "in_progress": false,
  "service": {
    "version": "1.0.0",
    "runtime": "python3.9"
  },
  "aws": {
    "region": "ap-northeast-1",
    "function_arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:OrderAPI",
    "request_id": "abcd1234-5678-90ab-cdef"
  }
}

3. スパン（Span）・サブセグメント（Subsegment）

定義： セグメント内の個別操作（DynamoDB PUT、S3 GET、HTTPリクエスト、DB接続など）。

{
  "name": "DynamoDB PutItem",
  "namespace": "aws",
  "start_time": 1614556200.100,
  "end_time": 1614556200.950,
  "duration": 0.85,
  "subsegments": [
    {
      "name": "aws_dynamodb_putItem",
      "aws": {
        "table_name": "Orders",
        "operation": "PutItem",
        "region": "ap-northeast-1"
      }
    }
  ]
}

4. アノテーション（Annotation）とメタデータ

アノテーション： インデックス付きラベル。トレース検索時にフィルタリング可能。

from aws_xray_sdk.core import xray_recorder

xray_recorder.put_annotation('customer_id', 'cust-12345')
xray_recorder.put_annotation('order_id', 'ord-67890')
xray_recorder.put_annotation('region', 'jp')

メタデータ： インデックスなし。詳細情報格納用。

xray_recorder.put_metadata('request', {
    'body': {'items': 3, 'total': 9999},
    'headers': {'user-agent': 'curl/7.64.1'}
})

5. サンプリング（Sampling）

デフォルトルール：

• 秒間最初の 1 リクエスト（固定）
• 残り 5%（可変）

カスタム設定例：

{
  "version": 2,
  "default": {
    "fixed_target": 1,
    "rate": 0.05
  },
  "rules": [
    {
      "description": "Health check - no sampling",
      "service_name": "*",
      "http_method": "GET",
      "url_path": "/health",
      "fixed_target": 0,
      "rate": 0.0
    },
    {
      "description": "Payment operations - 100% sampling",
      "service_name": "PaymentAPI",
      "http_method": "POST",
      "url_path": "/api/v1/payments",
      "fixed_target": 0,
      "rate": 1.0
    }
  ]
}

6. X-Ray Daemon

• クライアント SDK → X-Ray Daemon（UDP:2000） → X-Ray Service
• （バッファリング・バッチ送信）

X-Ray Daemonはセグメントデータを受け取り、バッファリング後にX-Ray ServiceのAPIに送信。SDKから直接API呼び出しより高速・信頼性が高い。

トレーシング計装の方式

方式1：X-Ray SDK（レガシー・2027年2月EOS）

# Python SDK - AWS X-Ray SDK for Python
from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all

patch_all()  # boto3, requests, sqlite3 を自動トレース

@xray_recorder.capture('process_order')
def process_order(order_id):
    # 関数実行がサブセグメントとして記録
    dynamodb = boto3.resource('dynamodb')
    table = dynamodb.Table('Orders')
    table.put_item(Item={'OrderId': order_id, 'Status': 'Processing'})

メリット： AWS ネイティブ、簡単セットアップ
デメリット： 2027年2月EOS、OTel標準との不互換性

方式2：ADOT（AWS Distro for OpenTelemetry）- 推奨（2026年以降）

# Python + ADOT（OpenTelemetry標準）
from opentelemetry import trace
from opentelemetry.exporter.aws.trace import AWSXRayIdGenerator
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# X-Ray Exporter（OTLPベース）
exporter = OTLPSpanExporter(
    endpoint="http://localhost:4317"  # ADOT Collector
)
trace_provider = TracerProvider(id_generator=AWSXRayIdGenerator())
trace_provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(trace_provider)

tracer = trace.get_tracer(__name__)

with tracer.start_as_current_span("process_order") as span:
    span.set_attribute("order.id", order_id)
    dynamodb = boto3.resource('dynamodb')
    # 自動計装でDynamoDB呼び出しも記録

メリット： OTel標準、複数バックエンド対応（X-Ray・Datadog・Honeycomb等）、将来性
デメリット： 初期セットアップやや複雑

方式3：自動計装（Lambda・ECS・EKS）

Lambda： 環境変数 _X_AMZN_TRACE_ID でトレースコンテキスト自動取得。X-Ray Daemonなしで送信。

# Lambda実行ロール設定で自動有効化
aws lambda update-function-configuration \
  --function-name MyFunction \
  --tracing-config Mode=Active

EKS： CloudWatch Observability Addon + ADOT による自動計装

# EKS クラスタで Application Signals有効化
aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name amazon-cloudwatch-observability

主要ユースケース

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

シナリオ： EC2上の注文処理API（Go）→ Lambda（Python）→ DynamoDB → 外部決済API のレイテンシが増加

X-Rayでの対応：

• サービスマップで各セグメントの実行時間を表示（秒単位で可視化）
• DynamoDBのレイテンシが800msで最大 → インデックス設計見直し
• 結果：P99レイテンシが5秒→1秒に改善

2. エラーの根本原因追跡

シナリオ： 支払い処理が10%の確率で失敗

X-Rayでの対応：

• エラートレースのみをフィルタ（http.status: >= 500）
• 失敗したトレースの詳細を表示 → 外部決済APIがタイムアウト
• API側の接続タイムアウト設定を10秒→30秒に増加 → エラー率低下

3. 特定顧客の問題調査

シナリオ： VIP顧客Aから「システムが遅い」とクレーム

X-Rayでの対応：

X-Ray Filters: annotation.customer_id = "cust-vip-001"
                AND duration > 5000  # 5秒以上

→ その顧客のトレースのみ抽出。独自のデータセット（100万件）をスキャンしているバッチ処理が原因 → クエリ最適化

4. Lambda Cold Start検出

シナリオ： Lambda関数の応答時間が不安定

X-Rayでの対応：

• Lambda セグメントの “init_duration” フィールド確認
• Cold Startで 500ms、Warm で 50ms → 同時実行数を確保（Provisioned Concurrency）

5. 複数リージョン・AZでのレイテンシ分析

シナリオ： 東京リージョンと大阪リージョンのレイテンシ差

X-Rayでの対応：

トレースにリージョン・AZ情報を付加
annotation.region = "ap-northeast-1"
annotation.availability_zone = "ap-northeast-1a"

→ リージョン間のデータ転送遅延を特定。キャッシュ戦略見直し

6. 分散トランザクション整合性確認

シナリオ： マイクロサービス間での非同期処理順序の確認

X-Rayでの対応：

• トレースにタイムスタンプ・スパン順序を記録
• 各SQS受信→Lambda処理の遅延を計測 → メッセージ順序保証の必要性判定

7. サードパーティAPI統合の可観測性

シナリオ： 複数の決済ゲートウェイ（Stripe・PayPal・Square）を統合

X-Rayでの対応：

with tracer.start_as_current_span("stripe_charge") as span:
    span.set_attribute("payment_provider", "stripe")
    response = stripe.Charge.create(...)
    span.set_attribute("charge_id", response.id)

→ 各プロバイダの応答時間・エラー率を比較

8. リアルタイムアラート

シナリオ： P99レイテンシが1秒超えたら即座に通知

X-Rayでの対応：

• X-Ray Insights + CloudWatch Alarms
• → エラーレート異常検知 → SNS/EventBridge通知

9. SLA・SLO管理

シナリオ： 「API P99 < 200ms」の目標達成率を監視

X-RayとApplication Signalsの連携：

• トレース詳細でP99レイテンシ取得
• Application Signals SLOダッシュボードで達成率・エラーバジェット表示

10. コスト最適化分析

シナリオ： Lambda実行時間を短縮してコスト削減したい

X-Rayでの対応：

• 実行時間分布（ヒストグラム）を分析
• P95以上の遅いリクエストの原因特定 → コード最適化の優先度決定

設定・操作の具体例

AWS CLI による操作

1. サンプリングルール表示

aws xray get-sampling-rules

2. カスタムサンプリングルール作成

aws xray create-sampling-rule \
  --cli-input-json file://sampling-rule.json

sampling-rule.json:

{
  "SamplingRule": {
    "ruleName": "payment-critical",
    "priority": 100,
    "fixedRate": 1.0,
    "reservoirSize": 1,
    "serviceName": "PaymentAPI",
    "serviceType": "*",
    "host": "*",
    "HTTPMethod": "POST",
    "URLPath": "/api/*/payments",
    "version": 1
  }
}

3. トレース検索

# エラーを含むトレース
aws xray get-trace-summaries \
  --start-time 2026-04-26T10:00:00Z \
  --end-time 2026-04-26T10:30:00Z \
  --filter-expression 'error = true'

# 特定のアノテーション条件
aws xray get-trace-summaries \
  --start-time 2026-04-26T10:00:00Z \
  --end-time 2026-04-26T10:30:00Z \
  --filter-expression 'annotation.customer_id = "cust-vip-001" AND duration > 5000'

4. Insightsを使用した異常検知

# Insightsで異常を検出
aws xray get-insight-summary \
  --start-time 2026-04-26T10:00:00Z \
  --end-time 2026-04-26T10:30:00Z

Terraform / CloudFormation（IaC）

Terraform

resource "aws_xray_sampling_rule" "payment_rule" {
  rule_name      = "payment-critical"
  priority       = 100
  fixed_rate     = 1.0
  reservoir_size = 1
  service_name   = "PaymentAPI"
  http_method    = "POST"
  url_path       = "/api/*/payments"
}

resource "aws_xray_group" "payment_group" {
  group_name        = "PaymentTraces"
  filter_expression = "service(\"PaymentAPI\") AND http.status >= 400"
  insights_enabled  = true
}

CloudFormation

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  PaymentSamplingRule:
    Type: AWS::XRay::SamplingRule
    Properties:
      RuleName: payment-critical
      Priority: 100
      FixedRate: 1.0
      ReservoirSize: 1
      ServiceName: PaymentAPI
      HTTPMethod: POST
      URLPath: /api/*/payments

  PaymentTraceGroup:
    Type: AWS::XRay::Group
    Properties:
      GroupName: PaymentTraces
      FilterExpression: 'service("PaymentAPI") AND http.status >= 400'
      InsightsEnabled: true

boto3（Python SDK）

import boto3
from aws_xray_sdk.core import xray_recorder

# X-Ray SDK の設定
xray_recorder.configure(
    service='OrderProcessing',
    sampling=True
)

# DynamoDB操作を自動トレース
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Orders')

@xray_recorder.capture('put_order_item')
def create_order(order_data):
    """注文をDynamoDBに保存"""
    xray_recorder.put_annotation('order_id', order_data['order_id'])
    xray_recorder.put_annotation('customer_id', order_data['customer_id'])
    
    response = table.put_item(Item=order_data)
    return response

# トレース情報の取得
client = boto3.client('xray')
traces = client.get_trace_summaries(
    StartTime=1619380800,
    EndTime=1619384400,
    FilterExpression='annotation.customer_id = "cust-12345"'
)
for trace in traces['TraceSummaries']:
    print(f"Trace ID: {trace['Id']}, Duration: {trace['Duration']}ms")

Docker/ECS での X-Ray Daemon

FROM python:3.9-slim

# X-Ray SDK をインストール
RUN pip install aws-xray-sdk boto3

# アプリケーションコピー
COPY app.py /app/

ENTRYPOINT ["python", "/app/app.py"]

docker-compose.yml:

version: '3'
services:
  app:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - xray-daemon
    environment:
      AWS_XRAY_SDK_ENABLED: "true"
      AWS_XRAY_DAEMON_ADDRESS: "xray-daemon:2000"
  
  xray-daemon:
    image: public.ecr.aws/xray/aws-xray-daemon:latest
    ports:
      - "2000:2000/udp"

類似サービス比較

X-Ray vs OpenTelemetry（OSS）

選択基準：

• AWS専用環境＋シンプルセットアップ → X-Ray（またはADOT）
• マルチクラウド・複数バックエンド対応 → ネイティブOpenTelemetry
• 高度な分析・ダッシュボード → Datadog APM・Honeycomb

X-Ray vs Jaeger

選択基準：

• AWS + マネージド重視 → X-Ray
• オンプレミス・Kubernetes・自管理重視 → Jaeger

X-Ray vs Datadog APM

選択基準：

• AWS ネイティブ・低コスト → X-Ray（ADOT）
• 豊富なダッシュボード・マルチクラウド → Datadog
• AWS低コスト + SLO管理 → Application Signals + X-Ray

X-Ray vs Honeycomb（CloudEvents形式）

ベストプラクティス

1. サンプリング戦略

✅ 推奨： 層状サンプリング

├─ 重要パス（支払い・ユーザー登録）: 100% サンプリング
├─ 標準API: 10% サンプリング
├─ ヘルスチェック: 0% サンプリング（除外）
└─ デバッグエンドポイント: 5% サンプリング

❌ 避けるべき： 全トレース100%サンプリング（コスト爆発）

2. アノテーション設計

✅ 推奨：

# ビジネスコンテキスト追加
xray_recorder.put_annotation('customer_id', customer_id)
xray_recorder.put_annotation('order_id', order_id)
xray_recorder.put_annotation('region', 'ap-northeast-1')
xray_recorder.put_annotation('tier', 'premium')  # 顧客レベル

❌ 避けるべき：

# パスワード・トークンをアノテーション（セキュリティリスク）
xray_recorder.put_annotation('api_key', api_key)

3. メタデータ運用

✅ 推奨： 本当に必要な情報のみ

xray_recorder.put_metadata('order', {
    'items_count': 3,
    'total_price': 9999
})

❌ 避けるべき： 全リクエストボディをメタデータに格納（ストレージ爆発）

4. Lambda での計装

✅ 推奨： X-Ray Tracing Mode を有効化

resource "aws_lambda_function" "my_function" {
  # ...
  tracing_config {
    mode = "Active"
  }
}

Subsegment 数削減（コスト最適化）

# 細粒度過ぎる計装を避ける
# ❌ 悪い例：ループ内でサブセグメント生成
for item in items:
    with xray_recorder.capture(f'process_item_{item.id}'):  # 1000個のサブセグメント
        process(item)

# ✅ 良い例：ループ全体を1つのサブセグメント
with xray_recorder.capture('process_items_batch'):
    for item in items:
        process(item)

5. エラーハンドリング

✅ 推奨： エラー情報をトレースに付加

try:
    result = external_api.call()
except Exception as e:
    xray_recorder.current_subsegment().add_exception(e)
    xray_recorder.put_annotation('error_type', type(e).__name__)
    raise

6. パフォーマンス最適化

✅ 推奨策：

• サンプリングレート調整でコスト削減
• Subsegment 数の最小化（ループ内計装を避ける）
• メタデータサイズ制限（各 Trace 最大 1MB）

❌ 避けるべき： すべてをトレースしようとしてコスト超過

トラブルシューティング

トレースが表示されない

Lambda で X-Ray が機能しない

サンプリングルールが適用されない

トレース検索が遅い

2025-2026最新動向

1. OpenTelemetry SDKsへの移行

重要： X-Ray SDKs はメンテナンスモード（2026年2月25日）→ EOS（2027年2月25日）

推奨移行パス：

• ADOT（AWS Distro for OpenTelemetry）採用
• またはネイティブOpenTelemetry + X-Ray Exporter

2. Application Signals との統合強化

新機能（2026年3月）：

• SLO Recommendations（30日の自動分析 → 推奨SLO値）
• Service-Level SLOs（複数エンドポイントの統合SLO）
• SLO Performance Report（カレンダーベースの達成率）

3. Transaction Search（CloudWatch Logs統合）

概要： X-Ray トレーススパン単位で Logs Insights 全文検索可能に

X-Ray Trace → Logs Insights Query
  filter @message like /payment_failure/
  AND span.name = "stripe_charge"
  AND duration > 5000

4. Lambda Extension による自動トレース収集

改善： デーモン不要で Lambda 実行環境で直接トレース送信

# Lambda レイヤーで自動有効化予定
aws lambda create-function \
  --tracing-config Mode=Active  # 自動でX-Ray対応

5. マルチリージョン・フェデレーション

リージョン間でのトレース集約が可能に

• 東京リージョン → Central Region（統一X-Ray Service）
• 大阪リージョン ↗

学習リソース

公式ドキュメント

1. AWS X-Ray Developer Guide
2. X-Ray SDKs（レガシー、2027年2月EOS）
3. AWS Distro for OpenTelemetry
4. ADOT Collector Configuration

OpenTelemetry・トレーシング標準

• OpenTelemetry Documentation（標準仕様）
• OpenTelemetry Python SDK
• Jaeger Tracing（OSS参考実装）

比較・ベストプラクティス

• OneUptime: OpenTelemetry vs X-Ray（2026）
• AWS Cloud Operations Blog - X-Ray & ADOT Migration
• Observability Best Practices - AWS

導入ロードマップ

Week 1-2         Week 3-4         Week 5-6         Week 7+
┌─────────────┬──────────────┬──────────────┬──────────────┐
│   基礎      │   実装       │   発展       │   運用・最適 │
│             │              │              │    化        │
│ ・概念理解  │ ・Lambda   │ ・アノテー │ ・コスト     │
│ ・サービス  │ で計装      │ ション設計 │  最適化     │
│ マップ概要 │ ・ECS/EKS  │ ・サンプリ│ ・ADOT移行 │
│             │ セットアップ│ング最適化 │ ・複数リージョン│
└─────────────┴──────────────┴──────────────┴──────────────┘

実装チェックリスト

Phase 1：基本セットアップ

• [ ] AWS アカウントで X-Ray コンソールアクセス確認
• [ ] 最初の Lambda 関数に X-Ray Tracing Mode を有効化
• [ ] X-Ray ダッシュボードで自動トレース表示を確認

Phase 2：計装・トレース収集

• [ ] Lambda 関数に X-Ray SDK（またはADOT）をインストール
• [ ] EC2/ECS インスタンスに CloudWatch Agent 導入
• [ ] X-Ray Daemon 起動確認（ECS/Kubernetes 環境）

Phase 3：アノテーション・メタデータ設計

• [ ] ビジネスコンテキスト（customer_id・order_id）アノテーション追加
• [ ] サンプリングルール（重要パス 100%、ヘルスチェック 0%）作成
• [ ] トレース検索フィルタ整備

Phase 4：ダッシュボード・可視化

• [ ] X-Ray Service Map でマイクロサービス依存関係を確認
• [ ] Insights で異常検知有効化
• [ ] CloudWatch カスタムダッシュボード作成（レイテンシ分布等）

Phase 5：Application Signals連携

• [ ] Application Signals有効化（EKS/EC2）
• [ ] SLO定義（P99 < 200ms等）
• [ ] エラーバジェット監視

Phase 6：統合・自動化

• [ ] EventBridge + Lambda で自動修復（Insights異常検知時）
• [ ] CloudWatch Alarms で P99 レイテンシ超過時の通知設定

Phase 7：ADOT移行・将来対応

• [ ] X-Ray SDKsからADOT への移行計画（2026年前半）
• [ ] OpenTelemetry 標準への準備
• [ ] 複数バックエンド（Datadog等）対応の検討

まとめ

初心者向けメモ： X-Rayは「マイクロサービス時代の必須トレーシングツール」です。リクエストが複数のサービスを経由する際、どこでレイテンシが増えているか、どのサービスでエラーが発生しているかを自動的に可視化します。

X-Rayを使うべき3つの理由

1. AWS ネイティブ統合：Lambda・ECS・EKS・DynamoDB・RDS など 100+ のサービスと自動統合。追加エージェント不要で計装開始可能。
2. サービスマップの自動生成：マイクロサービス間の依存関係グラフが自動生成され、各エッジにレイテンシ・エラー率が表示される。ビジュアルでボトルネック特定が容易。
3. ビジネスコンテキストの追跡：アノテーション機能でユーザーID・注文IDなどを付加し、「VIP顧客のみのトレース」など検索可能。インフラ観点だけでなくビジネス影響の分析に活用。

2026年以降の進み方

• X-Ray SDKs → ADOT（OpenTelemetry）への移行 が主流化
• Application Signals との統合 で SLO 管理が統一される
• 複数バックエンド対応 でベンダーロック軽減

次のステップ

1. 単一 Lambda 関数で X-Ray Tracing を有効化
2. マイクロサービスの依存関係マップ確認
3. アノテーション設計でビジネス文脈追加
4. サンプリング戦略の最適化
5. ADOT への移行を 2026 年前半に完了

参考文献

公式リソース

1. AWS X-Ray Developer Guide
2. AWS X-Ray Pricing
3. AWS Distro for OpenTelemetry (ADOT)
4. Announcing AWS X-Ray SDKs/Daemon End-of-Support - AWS Blog
5. AWS X-Ray SDKs/Daemon Migration to OpenTelemetry
6. CloudWatch Application Signals Integration with X-Ray
7. AWS Observability Best Practices
8. AWS X-Ray Insights Documentation

OpenTelemetry・業界標準

• OpenTelemetry Official Documentation
• Jaeger Distributed Tracing
• Zipkin Tracing

比較・ベストプラクティス記事

• OneUptime: OpenTelemetry vs AWS X-Ray Comparison (2026)
• AWS Messaging and Targeting Blog
• Tracing ETL Workloads using AWS X-Ray and ADOT

ベンダー・OSS

• Datadog APM Documentation
• Honeycomb Observability Platform
• New Relic APM
• Prometheus & Grafana

最終更新：2026-04-26 バージョン：v2.0