X-Ray SDK および X-Ray デーモンが 2027 年 2 月 25 日にサポート終了するため、必要な対応について整理してみた
概要
X-Ray SDK および X-Ray デーモンは 2026 年 2 月 25 日にメンテナンスモードに入り、2027 年 2 月 25 日にサポート終了することが予定されています。
AWS X-Ray SDKs とデーモンは 2026 年 2 月 25 日にメンテナンスモードに入り、2027 年 2 月 25 日にサポートが終了します。2027 年 2 月 25 日以降、更新やリリースは配信されなくなります。
https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-migration.html#
2026 年 2 月 25 日以降、1 年のメンテナンスモードを経て完全にサポート終了する形です。
注意が必要な点として、サポート終了するのは X-Ray SDK と X-Ray デーモンのみであり、X-Ray 自体が終了するわけでは無いです。
X-Ray を使う時の典型的な構成として下記があります。
今後同じ構成を実装する場合、OpenTelemetry 仕様に即した下記流れが一般的になります。
※ OTLP は OpenTelemetry で定義されたテレメトリデータを送受信するための標準プロトコルで、gRCP または HTTP で通信を行います。
awsxrayexporter と X-Ray を利用する前提で簡略化しましたが、OpenTelemetry の場合は Collector の中にレシーバー/プロセッサー/エクスポーターといったコンポーネントが存在し、それぞれを適宜設定することでトレースデータに留まらない様々なテレメトリを扱うことができます。
上の図では OTLP や HTTPS などと書いてありますが、レシーバーやエクスポーターを変えることで、通信方式は柔軟に変更可能です。
例えば AWS が配布している ADOT Collector (AWS Distro for OpenTelemetry Collector) では下記のようなレシーバー/プロセッサー/エクスポーターを利用可能です。
OpenTelemetry の浸透を受けて、トレースを送信する側の独自仕様 (X-Ray SDK、X-Ray デーモン) はサポートされなくなり、ADOT Collector のような OpenTelemetry 互換の仕組みを使う形になると理解すれば良いと思います。
X-Ray デーモンについては CloudWatch エージェントが OTLP 経由でトレースデータを収集できるようになったことも今回の流れに大きく影響を与えていると思われます。
ただ、X-Ray 自体は今後も OpenTelemetry 互換の Observability バックエンドとして機能開発されていくと思います。
公式ドキュメントにも SDK やデーモンのサポート終了を受けて CloudWatch エクスペリエンスが変わるわけでは無いことがしっかりと明記されています。
OpenTelemetry ベースのソリューションに移行した後も、CloudWatch エクスペリエンスは変わりません。CloudWatch コンソールのトレースページとトレースマップページでトレースを同じ形式で表示したり、X-Ray APIs を使用してトレースデータを取得したりできます。
https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-migration.html#migration-overview
想定される移行先
移行する際はアプリケーションが扱う SDK とテレメトリを収集する側のそれぞれで考える必要があります。
X-Ray 計測から OpenTelemetry 計測に完全に移行するには、以下が必要です。
- X-Ray SDK の使用を OpenTelemetry ソリューションに置き換える
- X-Ray デーモンを CloudWatch エージェントまたは OpenTelemetry Collector (X-Ray Exporter) に置き換えます。
https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-migration.html#migration-overview
X-Ray SDK の移行
SDK 側でまず考えられるのが下記のような OpenTelemetry SDK を直接利用する方式になります。
X-Ray SDK に対応していた言語 (Java/Go/Node.js/.NET/Python/Ruby) は AWS 公式ドキュメントに移行後の書き方が記載されています。
例えば Node.js のものを引用すると下記のような形になります。
/*instrumentation.js*/
// Require dependencies
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-proto');
const { AWSXRayPropagator } = require("@opentelemetry/propagator-aws-xray");
const { detectResources } = require('@opentelemetry/resources');
const { awsEc2Detector } = require('@opentelemetry/resource-detector-aws');
const resource = detectResources({
detectors: [awsEc2Detector],
});
const _traceExporter = new OTLPTraceExporter({
url: 'http://localhost:4318/v1/traces'
});
const sdk = new NodeSDK({
resource: resource,
textMapPropagator: new AWSXRayPropagator(),
traceExporter: _traceExporter
});
sdk.start();
手動計測ソリューション | OpenTelemetry Node.js への移行
そこまで X-Ray SDK と変わらない形で使えそうですね。
X-Ray デーモンが OTel Collector という名前になっているかもしれませんが、やっていることは何らかのエージェントにトレースデータを投げるだけと考えるとそこまで大きな違いは無いということでしょう。
他に考えられるのが AWS Distro for OpenTelemetry Instrumentation を使うパターンです。
アップストリームの OpenTelemetry SDK を元にしながら AWS 環境での利用を意識してパッケージングしてくれているもので、X-Ray 以外の Observability バックエンドを検討しておらず、自動計装を活用したい場合におすすめです。
The AWS Distro for OpenTelemetry (ADOT) JavaScript refers to some components developed to complement the upstream OpenTelemetry (OTel) JavaScript SDK and OTel JavaScript Auto-Instrumentation for Node.js.
https://aws-otel.github.io/docs/getting-started/javascript-sdk
また、SLI/SLO を管理できる CloudWatch Application Signals を利用する場合はこちらを利用すると楽です。
CloudWatch は OTLP エンドポイントを持っているので OpenTelemetry SDK + OpenTelemetry Collector でも利用自体は可能ですが、AWS Distro for OpenTelemetry Instrumentation と CloudWatch エージェントを利用しつつ環境変数で OTEL_AWS_APPLICATION_SIGNALS_ENABLED を true にするだけで利用できるのがかなり魅力的です。
下記ドキュメントに記載されている通り、AWS Distro for OpenTelemetry Instrumentation が用意されていない言語を扱う場合でも無い限りはこちらに乗っかることがおすすめです。
以前試してみた際は AWS Distro for OpenTelemetry Instrumentation エージェントを含めつつ各種環境変数を設定するだけで自動計装の設定が終わり、CloudWatch Application Signals も利用できるようになりました。
拍子抜けするくらい簡単でしたので、是非試してみて下さい。
X-Ray SDK から移行する際に想定される考慮点
AWS 公式ドキュメントに X-Ray SDK を扱うべき場面として下記が挙げられており、こちらがそのまま移行する際の考慮点になりそうです。
以下が必要な場合は、アプリケーションの計測に X-Ray SDK を選択することをお勧めします。
・緊密に統合されたシングルベンダーソリューション
・Node.js、Python、Ruby、.NET を使用する場合に、X-Ray コンソールからサンプリングルールを設定し、複数のホスト間で自動的に使用する機能を含む、X-Ray の一元化されたサンプリングルールとの統合
https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-choosing
OpenTelemetry 化は避けられないので一つ目は置いておいて、リモートサンプリング周りは注意が必要です。
ただ、OpenTelemetry SDK でリモートサンプリングが使えないだけで、AWS Distro for OpenTelemetry Instrumentation であれば利用できそうです。
この辺りもアップストリームの OpenTelemetry SDK より AWS Distro for OpenTelemetry Instrumentation を使うべき理由になります。
Python
JavaScript
.NET
また、この点についてはローカル SDK 側でサンプリング設定を行えば良いだけとも言えます。
AWS 側の取り込んでいるトレースの量を確認しながら X-Ray のサンプリングルールを修正する方が楽な場面は多いと思いますが、この点がクリティカルになるケースは少ないんじゃないかと思います。
高度なサンプリングを行いたいのであれば、ローカル SDK 側でテールサンプリングを行う方針にもできます。
逆に AWS Distro for OpenTelemetry Instrumentation でないと使えない機能も出てきたので将来的には X-Ray SDK より便利になる可能性も高いです。
もう一つ気になる点として、ADOT Lambda Layer を差し込むとコールドスタートのレイテンシーが増加するという問題があります。
AWS Distro for OpenTelemetry は、Lambda 関数を計測するためのシンプルな入門エクスペリエンスを提供します。ただし、OpenTelemetry に備わる柔軟性が原因で、Lambda 関数が必要とするメモリが増加し、呼び出し時に、コールドスタートのレイテンシーが増加し、追加料金が発生する可能性があります。低レイテンシー向けに最適化していて、動的に設定可能なバックエンド送信先など、OpenTelemetry の高度な機能を必要としない場合は、 AWS X-Ray SDK を使用してアプリケーションを計測できます。
https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-choosing
ADOT レイヤーを差し込むだけで自動軽装され、Collector についても考えなくて良いのは大きなメリットです。
まずこちらを検討したい所ですが、コールドスタートの時間が 5 ~ 6 倍になったという話もあるので、X-Ray SDK から Lambda ADOT レイヤーに移行する際は一定注意を払う必要があります。
Lambda 内で Collector を実行せず、X-Ray UDP Span Exporter を利用して直接 X-Ray にスパンを送る手法もありますが、面倒な上にせっかく OpenTelemetry 化したのに独自仕様の方式を使いたく無い気持ちもあります。
また、Powertools for AWS Lambda 経由で X-Ray SDK に依存しているケースも多いと思っています。
Tracer is an opinionated thin wrapper for AWS X-Ray SDK for Node.js.
https://docs.aws.amazon.com/powertools/typescript/latest/features/tracer/
何らかの対応をしてくれると思いますのでこちらに乗っかるのもありだと思います。
Powertools for AWS Lambda を利用している場合は下記 discussions を追っておくと良いと思います。
ADOT レイヤーを利用した上でコールドスタートも許容範囲に収まれば一番良いものの、Lambda 周りは全般的に考慮事項が多いので、特に慎重に移行を計画した方が良さそうです。
X-Ray デーモンの移行
X-Ray デーモンの移行先は OTLP 対応した CloudWatch エージェントか、OpenTelemetry Collector 互換の各種 Collector になります。
- CloudWatch 系統
- CloudWatch エージェント
- (EKS の場合) Amazon CloudWatch Observability EKS アドオン
- OpenTelemetry Collector 系統
- ADOT Collector
- その他 Otel 互換の Collector (OpenTelemetry プロジェクトが公開しているものやカスタムビルドのものなど)
- (Lambda の場合) ADOT レイヤー
v1.300025.0 以降の CloudWatch エージェントは OTLP 経由でトレースを収集できるようになっています。
特に EC2 でログ管理やカスタムメトリクス用途で CloudWatch エージェントを既にインストールしているケースは、こちらを利用すると楽です。
EKS の場合は CloudWatch エージェントと Fluent Bit をパッケージングした Amazon CloudWatch Observability EKS アドオンを利用でき、Container Insights や CloudWatch Application Signals など AWS のサービスを中心に監視設計する際は第一候補に上がると思います。
また、ECS でも Application Signals を使う際は AWS Distro for OpenTelemetry Instrumentation エージェントと CloudWatch エージェントのセットが使いやすいです。
とはいえ、OpenTelemetry Collector を使いたいケースも多いと思います。
特にコンテナ環境ではログの収集に Fluent Bit、メトリクスの収集に Prometheus を利用するケースも多く、こういった OSS 系統のツールを多く利用している場合はガッツリ OpenTelemetry 互換の仕組みに寄せた方が後々便利に思えています。
その場合、まず AWS が配布している ADOT Collector を検討して、必要に応じてカスタムビルドするような形が良いと思います。
この辺りの選定については下記 builders-flash の記事がとてもわかりやすいです。
最後に
より OpenTelemetry 仕様に即した形に寄せていくのは避けられないだろうなと思ってはいましたが、X-Ray SDK/X-Ray デーモンのサポート終了は思ったより早かったなという印象です。
私の中ではどちらもまだまだ現役で広く使われている印象なので。
とはいえ OpenTelemetry 仕様に寄っていくのは避けられないので、しっかり移行して自動計装や CloudWatch Application Signals なども上手く活用していきたいですね！
また、Lambda 周りは思ったより複雑だったので追加情報があれば別途ブログにしようと思います。
余談ですが、既に X-Ray のサービスページにアクセスすると CloudWatch のサービスページに遷移しますし、今後は CloudWatch Application Signals(APM) のトレース機能として扱われるんだろうなと思います。
X-Ray の機能そのものはこれからも開発が進むでしょうが、X-Ray SDK/X-Ray デーモンが無くなった後、X-Ray というワード自体を意識することは減るのかもなぁって思ったりしました。
X-Ray へのメトリクス送信も OTLP 形式が一般的になり、ドメインくらいでしか意識することが無くなる未来も近いかもしれないですね。
