AWS X-Rayってなんだろ?
AWS X-Rayについて調べてみました。
AWS X-Ray(分散アプリケーションの分析とデバッグ)| AWS
概要
- 本番環境や分散アプリケーションを分析およびデバッグ
- アプリケーションやその基盤となるサービスの実行状況を把握
- パフォーマンスの問題やエラーの根本原因を特定
- アプリケーション内で転送されるリクエストがエンドツーエンドで表示
- アプリケーションの基盤となるコンポーネントのマップも表示
簡単にまとめると、
「アプリやアプリ基盤を分析し、エラーや問題の原因を特定できるサービス」
といったところでしょうか。
メリット
- リクエスト動作の確認
- アプリケーションの問題の検出
- アプリケーションのパフォーマンスの向上
- AWS との連携
- さまざまなアプリケーション向けの設計
イメージ
よくある質問 - AWS X-Ray | AWS
X-Ray を使用するメリットは何ですか?
- サービスやリソース中心ではない、ユーザーを中心としたモデルを通して、アプリケーションに対するリクエストに関連したデータが収集される
- ユーザーを中心とした視点で、サービスやリソースを経由するリクエストを把握することができる
- X-Ray によってデータの関連付けと集計が実行されることで、お客様はアプリケーションのエンドユーザー環境を向上させることに注力できる
分散アプリで複雑になるリクエストの追跡をX-Rayに任せ、アプリの開発に集中できるというのがメリットのようです。
X-Ray ではどのようなことができますか?
- サービスマップの作成
- アプリケーションに対するリクエストが追跡され、アプリケーションによって使用されるサービスマップが作成される
- アプリケーション内のサービス間のつながりを把握できる
- 依存性ツリーの作成
- 複数の AWS アベイラビリティゾーンまたはリージョン間で発生するレイテンシーやエラーの検出
- 正常に実行されていないサービスの把握
- エラーとバグの特定
- アプリケーションに対する各リクエストの応答コードが分析され、アプリケーション内のバグやエラーが自動的に検出
- バグやエラーを再現することなく、アプリケーションコードを簡単にデバッグ
- 独自の分析と可視化アプリケーションの作成
- X-Ray で用意されたクエリ API のセットを使用して、X-Ray で記録されたデータに基づく独自の分析や可視化のためのアプリケーションを構築
すべてまとめると、
「サービスマップでサービス間のつながりを把握」し、
「応答コードからバグやエラーを自動検出」し、
「独自の分析、可視化アプリ構築」できる。
ってかんじだと思います。
追跡とは何ですか?
- 同じ追跡 ID を持つデータポイントの集合体
- クライアントからアプリケーションに対するリクエストが作成されると、それに対して一意の追跡 ID が割り当てられる
- このリクエストがアプリケーション内の複数のサービスを経由すると、リクエストに関する情報は、この一意の追跡 ID によってサービスから X-Ray に中継
- アプリケーション内のサービスから X-Ray に中継される各情報はセグメントであり、追跡はセグメントの集合体
リクエストを追跡するためにIDが割り振られ、同じIDを持つ各データポイント(コンポーネント?)の集合体らしいです。1つのリクエスト(=ID)が通過したコンポーネントの集合体というかんじでしょうか。
セグメントとは何ですか?
- 分散アプリケーションの 1 つのコンポーネント (認証サービスなど) に関するすべてのデータポイントをカプセル化したもの
- システム定義のデータとユーザー定義のデータが注釈の形式で含まれている
- 各セグメントは、サービスからのリモートコールを表す 1 つ以上のサブセグメントで構成
- リクエストに応じてアプリケーションからデータベースが呼び出されると、そのリクエストに対して、データベース呼び出しとその結果を表すサブセグメントを伴うセグメントが作成される
- サブセグメントには、クエリ、使用されたテーブル、タイムスタンプ、エラーステータスなどのデータが含まれる
1つのコンポーネントにおけるすべてのデータポイントで、サブセグメントから構成されるようです。
サブセグメントは各データポイント間でのやり取りの結果といったところでしょうか。
コンポーネント全体がセグメント、コンポーネント内でのデータのやり取りがサブセグメントみたいなかんじで捉えておきます。
注釈とは何ですか?
- セグメントに関連付けられたシステム定義のデータまたはユーザー定義のデータ
- システム定義の注釈には、AWS のサービスによってセグメントに追加されたデータが含まれている
- ユーザー定義の注釈は、開発者がセグメントに追加したメタデータ
- アプリケーションによって自動的に作成されたセグメントには、AWS のサービス呼び出しに対するリージョンデータが自動的に挿入される
- AWS 以外のサービスに対する呼び出しの場合は、リージョンデータの追加を選択することができる
セグメントにくっつける情報で、システム定義はAWSが自動でくっつける、ユーザー定義は開発者がくっつけるみたいなかんじでしょうか。
エラーとは何ですか?
- エラーが返された呼び出しのあるセグメントに関連付けられたシステム注釈
- エラーには、ソースファイルと関連付けるためのエラーメッセージ、スタックトレースやその他の追加情報 (バージョンやコミット ID など) が含まれる
エラーが起きたコンポーネントにAWSがくっつけたデータが、X-Rayで言う「エラー」とのことです。
サンプリングとは何ですか?
- 統計的に有意なリクエスト数のデータが収集される
- パフォーマンスやコスト効率の観点から、X-Ray ではアプリケーションに送信されるリクエストすべてのデータが収集されるわけではない
- X-Ray ではデータの完全性が保証されないため、監査やコンプライアンスのツールとして使用することはできない
「監査やコンプライアンスのツールとして使用することはできない」というのはポイントですね。全データを追跡しているわけではないんですね。
X-Ray エージェントとは何ですか?
- X-Ray エージェントでは、データがログファイルから収集され、X-Ray サービスに送信される
- その後、データは X-Ray サービスで集計、分析、保存される
- このエージェントにより、API を使って直接送信するよりも簡単にデータを X-Ray サービスに送信することができる
要はログファイルからX-Rayにデータを送るやつですかね。CloudWatchエージェントみたいなものをイメージしました。
re:Growthで「X-Ray」について話してきました! #reinvent #cmdevio | DevelopersIO
- X-Rayとは、1つのリクエストをトレースすることにフォーカスしたサービス
- コンポーネント化が進むことで各要素間の関係が複雑になり、リクエストのトレースも難しくなり、エラーの発生個所やボトルネックの検出も難しくなってきた
- ログ地獄
- X-Rayによりリクエストトラッキングの手間を軽減
- エラーの発生がサービスマップ上でわかる
- エラーコードやExceptionの内容、レスポンス時間が分かる
- 使える言語はNode.js、Java、C#
コンソール
CloudFormationで作ってくれるみたいです。
作成完了後に出力からサンプルアプリにアクセスします。
適当にアプリをいじってX-Rayコンソールに移動します。
リクエストに関するレスポンスやステータスコードなどがダッシュボードになってわかりやすく表示されます。
まとめ
今回はAWS X-Rayについて調べてみました。
以下がポイントでした。
- アプリやアプリ基盤を分析し、エラーや問題の原因を特定できるサービス
- リクエストの追跡に時間を割かずに、本来やりたいアプリの開発に集中できる
- サービスマップでサービス間のつながりを把握
- 応答コードからバグやエラーを自動検出
- 独自の分析、可視化アプリ構築
- 追跡とは、同じ追跡 ID を持つデータポイントの集合体
- セグメントとは、 1 つのコンポーネントに関するすべてのデータポイントをカプセル化したもの
- 注釈とは、セグメントに関連付けられたシステム定義のデータまたはユーザー定義のデータ
- エラーとは、エラーが返された呼び出しのあるセグメントに関連付けられたシステム注釈
- サンプリングとは、統計的に有意なリクエスト数のデータを収集すること
- X-Ray エージェントでは、データをログファイルから収集し、X-Ray サービスに送信する
参考になれば幸いです。
Discussion