【X-ray】概要と本番環境への段階的な導入案
まず、X-Rayとは
AWS X-Ray は、リクエストがアプリケ ーションを通過する際の完全なビューを提供し、ペイロード、関数、トレース、サービス、API などのビジュアルデータをノーコードおよびローコードモーションでフィルタリングします。
https://aws.amazon.com/jp/xray/
とのこと。
Lambda や API Gatewayなどの場合は設定を有効化するだけでも利用できるため、Lambdaを主体としたサーバーレス構成であれば比較的容易に導入できます。
アプリケーションコードへの埋め込みはX-Ray SDK、AWS SDK、AWSDistro for openTelemetryの３つの方法がありますが、
- 基本的には手軽に X-Ray SDK
- よりフレームワークやアプリケーションに即したトレーシングの実装が必要な場合はAWS SDK
- 複数のモニタリング先に対してトレースを送信する必要がある場合にはAWSDistro for OpenTelemetry
といったような使い分けができます。
X-Rayの主な用途としては
などで、もう少し具体的なユースケースをあげてみると、
- 負荷試験時のみ集中的に利用し、パフォーマンスチューニングを行う。
- 本番環境において、クリティカルなパスについてはすべてトレースするようにし、問題発生時の調査を可能にする。それ以外のパスについてはサンプリングレートを調整し、統計的なモニタリングを行う。
- ステージング環境や開発環境ではすべてをトレースするように設定し、ボトルネックやパフォーマンス劣化を早期発見できるようにする。
などなど。
いくらか注意事項もあります。
たとえばサンプリングレートの都合でエラー監視には向いていません。
サンプリングレートが1より小さいとエラーを取り逃がすことがあり、すべてをサンプリングしようとレートを1にするとコストが増加する可能性が高く、また同時に負荷も増加する可能性があります。
そのため、エラー監視については別途行う必要があります。
また、多少パフォーマンスへの影響があります。
これについてはサンプリングレートの調整、アノテーションを活用したフィルタリング、対象リソースの制限などによりサンプリングルールや取得期間を設定し、サンプリングをコントロールすることで対応可能です。
つまり、コストやアプリケーションへの負荷を考慮する必要があるため、導入の範囲やトレースのサンプリングは適切にコントロールする必要があるのです。
既存の本番環境へX-Rayを導入する場合にはやはりこのあたりの負荷や本番環境へのコードの追加がネックになりがちなイメージです。
その対策案として適用範囲を限定的に、段階的に拡大して導入していくのがよいのではないかと考えます。
例えば、API Gateway、Lambda、DynamoDB、S3というよくあるサーバーレス構成でパフォーマンス劣化が生じてきており、その原因と特定し、以降は継続的なモニタリングを行いたいとします。そのときに
- 詳細な調査の対象となるLambdaを絞り込む（コード追加不要）
API Gateway、Lambdaにおいてアクティブトレースを有効化し、十分な期間データを蓄積する。
コンソールにて詳細な調査の対象となるパスや処理とそれに関連するLambdaを絞り込む。 - 詳細なトレースを取得し、原因となる処理を特定する（特定のLambdaのみコード追加、サンプリングの調整）
対象のLambdaにAWS X-Ray SDKを導入し、サブセグメント等を設定する。
サンプリングルールにて対象となるリソースARNやURLを指定する。
コンソールにて分析を行い、パフォーマンス劣化の原因となる処理を特定する。 - 全体にSDKを導入し継続的にモニタリングを行う
2の対応が完了した後に、他のLambdaへX-Ray SDKを導入し、サンプリングレートの調整やクリティカルな処理へのサブセグメント設定などを行ったうえで常時有効化する。
というようなイメージです。 もちろん上記は全てが上手くいったパターンではありますが、段階的な導入を行うことでX-Rayの知見やアプリケーションへの適用方法などを蓄積していく期間を設けることができるため全体に適用する際にもスムーズに移行でき、影響範囲を限定的にする以外にもメリットが得られるのではないでしょうか。
