AWS X-Ray SDKがメンテナンスモード入り、終了日が撤回されてもOTelへ移る理由

AWS X-Ray SDKとX-Ray Daemon（SDKからトレースを受け取ってX-Rayへ送る常駐プロセス）は、2026年2月25日にメンテナンスモードへ入った。AWS開発者ガイドのサポートタイムラインによれば、この期間のリリースはセキュリティ問題への対応に限られ、新機能は追加されない。同じ表で、メンテナンスモードの終了日はN/Aになっている[1]。2025年8月にAWSがSDKのREADMEと開発者ガイドで告知した2027年2月25日のサポート終了は、同年11月から12月にかけてどちらからも消え、現行の公式表にも載っていない[1][2][3]。

期限が消えたのなら、X-Ray SDKを使い続けてもよいのか。AWSのブログは、X-Ray SDKには新しいライブラリ計装も、既存のライブラリ計装の改良も提供しないと明記している[4]。新機能の開発はOpenTelemetry（OTel、ベンダー中立な計装・収集の標準規格）ベースの仕組みに集中する。移行を急ぐ理由は、いつまでにという期限から、何が届かなくなるかへ移った。

予備知識

• X-Ray SDK/Daemon: リクエストがどのサービスをどう経由したかを追跡する分散トレーシングを、AWS上で実現するための計装ライブラリと収集プロセス
• OpenTelemetry（OTel）: 特定ベンダーに依存しない、トレース・メトリクス・ログ計装の業界標準規格
• ADOT（AWS Distro for OpenTelemetry）: AWSが配布するOpenTelemetryのディストリビューション
• スパン（Span）: OpenTelemetryにおけるトレースの最小単位。X-Rayのセグメント・サブセグメントに相当する

X-Ray SDKからの移行で初めてOpenTelemetryに触れるエンジニアが、Span・Tracer Provider等の基礎概念を体系的に押さえるために。

入門 OpenTelemetry ―現代的なオブザーバビリティシステムの構築と運用

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

2027年2月25日の終了日はどう消えたのか

2025年8月下旬、AWSはGitHubで公開しているX-Ray SDKのREADMEに2つの告知を加えた。2026年2月25日にメンテナンスモードへ入ること、2027年2月25日にサポートを終了し、以後は更新もリリースも行わないことである。メンテナンスモード中の提供範囲は「重大なバグ修正とセキュリティ更新」と書かれ、この一文は現在のREADMEにも残っている[2][5]。開発者ガイドにも同じ時期、End of supportを2027年2月25日とする表を載せたページ（xray-daemon-eos.html）があった[6]。

2025年11月14日にAWSが公開したブログ「AWS X-Ray SDKs/Daemon migration to OpenTelemetry」のライフサイクル表には、サポート終了の段階がない。一般提供の終了日とメンテナンスモードの開始日がともに2026年2月25日で、メンテナンスモードの終了日（End Date）はN/Aだ[4]。11月下旬には、X-Ray SDK for PythonのREADMEから2027年2月25日の節が削除された[3]。Java・Node.js・Go・.NET・RubyのSDKとDaemonのREADMEからも、同じ時期に同じ節が消えている[7]。開発者ガイドの旧ページは少なくとも12月15日まで2027年2月25日の表を載せていたが[8]、12月20日の保存版では、終了日をN/Aとする現在の表に置き換わっている[9]。終了日を外した理由はブログにもREADMEの変更にも書かれておらず、取り下げを知らせる告知も公開情報では見当たらない。

提供範囲の書き方は文書によって違う。READMEは現在も重大なバグ修正とセキュリティ更新と書いているが[5]、開発者ガイドの表はメンテナンスモード中のリリースをセキュリティ問題への対応に限り、新機能は加えないとしている[1]。旧ページの表も重大なセキュリティ問題への対応だけを挙げていて[6]、開発者ガイドには当初からバグ修正が入っていない。移行の計画は、狭いほうの開発者ガイドの記述を前提に置くのが安全である。一方でブログは、メンテナンスモードに入っても既存のX-Ray SDKとDaemonから送られるトレースは引き続き受け付けて処理すると明記している[4]。

複数サービス・複数言語にまたがる計装移行を、個人のスキルではなく組織的な導入プロジェクトとして進めたいチームに。

実践 OpenTelemetry ―オープンなオブザーバビリティ標準を組織に導入する

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

終了日がなくても移る理由は、新しい計装が届かないこと

メンテナンスモードで止まる機能の具体例として、AWSのブログが挙げるのはライブラリ計装だ[4]。X-Ray SDKのライブラリ計装は、AWS SDKやHTTPクライアント、Spring BootやExpress.jsのようなWebフレームワークを対象にしている[10]。こうしたライブラリを新しい版へ上げたり、別のライブラリを加えたりしても、X-Ray SDK側に対応する計装は増えない。

一方、X-Rayというサービス自体は引き続き完全にサポートされ、ネイティブのOpenTelemetry対応やCloudWatch Transaction Searchのような新機能が加わっている。ADOTやOpenTelemetryで計装すれば、CloudWatch Application SignalsやTransaction Searchも使えるようになる[4]。

移行ガイドの機能比較も同じ方向を示している。コードを変えずに計装できるゼロコードの自動計装は、X-Ray SDKではJavaだけだが、OpenTelemetryとADOTではJava・.NET・Python・Node.jsで使える[10]。

OTel経由のメトリクス課金

CloudWatchのOTel/PromQL対応とGB課金の実務影響

Amazon CloudWatch（AWSのマネージド監視サービス）が、OpenTelemetry（OTel、ログ・メトリクス・トレースを統一形式で扱う業界標準規格）由来のメトリクスをネイティブに取り込み、PromQL（Prometheu[…]

OpenTelemetryへの移行で何が変わるのか

移行は、ライブラリを1つ差し替えれば終わる作業ではない。AWSの移行ガイドは、移行を完了するにはX-Ray SDKの利用をOpenTelemetryのソリューションへ、X-Ray DaemonをCloudWatchエージェントかOpenTelemetry Collectorへ、それぞれ置き換える必要があるとしている[10]。

計装側では、X-Ray固有の概念がOpenTelemetryの概念に置き換わる。移行ガイドの対応表では、X-RayのセグメントはOpenTelemetryのサーバースパンに、サブセグメントはサーバー以外のスパンに、X-Ray RecorderはTracer ProviderとTracerに対応する[10]。属性の扱いも変わる。OpenTelemetryのスパン属性は既定でX-Rayのメタデータに変換されるため、検索に使う属性はaws.xray.annotationsの属性リストにキーを加えてアノテーションにする必要がある[10]。

収集側では、SDKからのUDP通信を受けてX-Rayへ送っていたDaemonの役割を、バージョン1.300025.0以降のCloudWatchエージェントか、OpenTelemetry Collectorが引き継ぐ[10]。以下は移行ガイドにある、EC2・オンプレミスのサーバー向けのOpenTelemetry Collectorの設定例である。

extensions:
  awsproxy:
    endpoint: 127.0.0.1:2000
  health_check:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 127.0.0.1:4317
      http:
        endpoint: 127.0.0.1:4318

processors:
  batch:

exporters:
  awsxray:
    region: 'us-east-1'

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [awsxray]
  extensions: [awsproxy, health_check]

awsproxy拡張はX-Rayのサンプリングルールを使うために必要な設定で、127.0.0.1:2000で待ち受ける。移行ガイドは、ポートの競合を避けるため、CloudWatchエージェントやCollectorを動かす前にX-Ray Daemonを止めるよう求めている。ECSのコンテナとして動かす場合は、エンドポイントを127.0.0.1から0.0.0.0に変える[10]。東京リージョンへ送るなら、awsxrayのregionを'ap-northeast-1'に置き換える。

移行後もCloudWatchコンソールのTraces・Trace Mapの画面で、これまでと同じ形式でトレースを見られ、X-RayのAPIからも取得できるとAWSは説明している。OpenTelemetryのスパンは、X-Rayのセグメントかサブセグメントへ自動で変換されるためだ[10]。トレース詳細画面では、上段のTrace Mapにサービス間の経路が、下段のSegments Timelineにセグメントとサブセグメントの所要時間が表示される[11]。

コードを書かないOTel計装

OTelコンパイル時計装、3つ目の計装パラダイムが安定版に

Goで書かれたサービスにOpenTelemetryを組み込む方法が、ここにきて三択になった。手動でSDKを呼び出すか、eBPFでプロセス外から観測するか、そして新たにビルド時にコードへ計装を注入するかだ。OpenTelemetryは分散シ[…]

移行の順番をどう決めるか

終了日が未定で、既存SDKからのトレースも受け付けられ続けるため[4]、すべてのサービスを一斉に移す必要はない。順番は期限ではなく、各サービスの変更予定と、X-Ray固有の機能への依存度で決められる。

第一の基準は、フレームワークやライブラリの更新・追加を予定しているサービスから着手することだ。X-Ray SDKには新しいライブラリ計装が来ないため、変更の多いサービスほど、X-Ray SDKのままでは計装が追いつかなくなる。改修予定のない安定したサービスは後に回せる。

第二の基準は、X-Rayのサンプリングルールとアノテーションへの依存度である。移行ガイドの比較表では、OpenTelemetryでX-Rayのサンプリングを使えるのは、OTelのJava・.NET・Go、ADOTのJava・.NET・Python・Node.jsに限られる[10]。検索に使っているアノテーションは、aws.xray.annotationsで1つずつ指定し直す必要がある。こうしたサービスは、依存の少ないサービスで手順を固めてから移す。

AWS Lambdaでは、自動計装のLambda Layerを追加する方法がある。推奨はAWS Lambda Layer for OpenTelemetryで、トレースだけを使う場合は環境変数OTEL_AWS_APPLICATION_SIGNALS_ENABLEDをfalseにする。移行ガイドのDaemon置き換え手順はEC2・オンプレミス、ECS、Elastic Beanstalkが対象で、Lambdaは含まれない[10]。筆者は、この手順が要らないLambdaを、移行手順を固める最初の対象に向いていると見ている。

稟議資料の2027年2月という期限を書き換える

2025年8月以降の告知をもとに、2027年2月25日を期限に据えた移行計画や稟議資料は、前提の日付が現行の公式表と合わない。日本語版の開発者ガイドも終了日を「該当なし」としているが、この版は機械翻訳で、英語版と食い違う場合は英語版が優先すると明記されている[12]。社内資料には英語版の表[1]も併記しておくと、次の改訂時に照合しやすい。旧来の終了日のページ（xray-daemon-eos.html）へのリンクは、現在は開発者ガイドのトップへ転送される。

稟議の論拠も差し替える。2027年2月までに移行しないとサポートが切れる、という説明はもう使えない。代わりに書けるのは、X-Ray SDKには新しいライブラリ計装も既存計装の改良も提供されないという、AWSが明記した事実である[4]。フレームワークの更新を控えたサービスほど、移行を後に回すとX-Ray SDKでは計装されない範囲が広がる。

まとめ

X-Ray SDKとDaemonは2026年2月25日からセキュリティ修正のみのメンテナンスモードにあり、終了日は現行の公式表でN/Aだ。終了日は示されていないが、新しいライブラリ計装はX-Ray SDKには追加されない。移行はSDKとDaemonの2か所の置き換えで、CloudWatchのTraces・Trace Mapの見え方は変わらない。

最初の作業は、各サービスが使っているX-Rayのライブラリ計装（AWS SDK、HTTPクライアント、Webフレームワーク）を洗い出し、同じライブラリの計装がOpenTelemetry Registryにあるかを確かめることである[10]。計装がそろい、ライブラリの更新を控えたサービスから移行を始める。

よくある質問（FAQ）

Q. メンテナンスモード中はX-Ray SDKを新規プロジェクトで使ってよいか。
A. 動作はするが、新しいライブラリ計装も既存計装の改良も提供されない[4]。AWSは新規・既存を問わず、OpenTelemetry SDKまたはADOTでの計装を推奨している[10]。

Q. 移行後にCloudWatchコンソールの見た目は変わるか。
A. 変わらない。AWSは、移行後もTraces・Trace Mapの画面で同じ形式のトレースを見られ、X-RayのAPIからも取得できると説明している[10]。入れ替わるのは裏側の計装と収集基盤である。

Q. 終了日が未定の間、X-Ray SDKのトレースは受け付けられるのか。
A. 受け付けられる。AWSのブログは、メンテナンスモード中も既存のX-Ray SDKとDaemonからのトレースを受け付けて処理すると書いている[4]。メンテナンスモードがいつまで続くかは示されておらず、終了日は英語版の表でN/A、日本語版で「該当なし」である[1][12]。

出典