Amazon Web Services ブログ

AWS X-Ray – 分散アプリケーションの内部を見る

大統領自由勲章の受賞者であるGrace Hopperが、プログラムからエラーを特定し取り除く作業にデバッグという言葉を与えた最初の人だと思います。

実際にコンピュータから本物のバグ(虫)を見つけたことはないですが、働き初めた頃にアセンブラ言語のデバッグに膨大な時間を費やしました。その当時は、デバッグとはコードを1ステップずつ実行し、各プロセッサのレジスタの中身をステップの前後で比較し、自分の頭の中のモデルと実際に起こっていることが一致しているかを検証するというものでした。これはとてもうんざりするようなものでしたが、バグが残る余地はほとんどなく、自分のコードがどの様に動くかの深い理解も得られるものでもありました。その後、1ステップずつの実行はなくなり、デバック出力(こんにちは、stderr)に取って代わり、それからログファイルとログ分析ツールへと変わっていきました。

最近の過去数十年で、複雑な分散システムが登場してきたことで、デバッグは変化して新しい意味を持つようになりました。単体テストが個別の関数とモジュールが期待通り動作することを保証しているので、難易度の高いポイントは大規模な中での動作のパターンを見ることに変わっています。クラウドコンピューティング、マイクロサービス、そして非同期な通知ベースのアーキテクチャの組合せによって、システムは数百から数千もの可変な箇所を持つようになりました。こうした複雑なシステムでのパフォーマンス課題を特定し対応していく難しさは増していて、個別サービスレベルの観測情報を集約して意味のある上位の結果にすることに難しさがあります。開発者にとって、EC2インスタンス、ECSコンテナ、マイクロサービス、AWSのデータベースやメッセージサービスを辿って”筋道を追う”ことは簡単ではありません。

これを何とかしましょう!

AWS X-Rayの紹介

本日、AWS X-Rayについてご紹介します。これは、リクエストを開始から終了まで、先程言及した全てのタッチポイントに渡って追跡することを可能にするものです。大規模な分散システムを理解し改善したい時の課題に対応し、そのために必要な情報と洞察を与えてくれます。

X-Rayは(ECSコンテナを含む)EC2インスタンス、AWS Elastic BeanstalkAmazon API Gateway、その他の基盤上で実行されるコードから追跡データを捕捉できます。(ユニークIDを含む)HTTPヘッダをリクエストに追加して、それを次の層へのリクエストハンドラに渡すことで、筋道を追って追跡することができるように実装されています。各点で収集されるデータはセグメントと呼ばれ、JSONデータの塊として保存されます。セグメントは1つの単位で、リクエストとレスポンスのタイミング、それに更に小さな単位であるサブセグメント(適切に設定をしていれば、コードの行番号等)をオプションで含んでいます。統計的に意味のあるサンプリングでセグメントはX-Rayに転送され(EC2インスタンス上やコンテナ内のデーモンプロセスが処理します)、そこでトレースとして組み立てられます(共通のIDを持つセグメントをグループ化)。トレースはセグメントで処理をされサービスグラフが作成されるので、各サービスの関係性を可視化して表現することができます。

これらがどの様に動作するのかを見るために、X-Rayのコンソールを少し触ってみました。その中で、コンソールが私の代わりに起動できるように提供してくれるいくつかのサンプルアプリを使いました。

各サンプルアプリはAWS CloudFormationテンプレートによって起動されます。アプリは最新のAWS SDKsを使っているので、X-Rayを利用してX-Rayのセグメントを集めて保存する処理に組み込まれます。Java、Node.js、そして.NET SDKがX-Rayのサポートをしていますが、その他のSDKも出来る限り早く更新していきます。

自身でアプリケーションを設定して実行する準備をする時には、X-Rayコンソールが何をすべきかを教えてくれます:

私はいくつかのアプリを起動し、少しの間走らせておき、その後X-Rayコンソールに移って何が起こっていたかを見てみました。サービスマップは概要を示しています:

日付や時間の範囲セレクタを使って、興味のある時間幅を指定することもできます:

グラフのどのノードもクリックすることで、その裏のトレースを掘り下げることができます:

ページの一番上で、サインアップ操作が、頻度は低いですが(トレースの4.12%)他の2つの操作に比べて高いレイテンシになっていることがわかります。まずサインアップ操作をグループ化してURLでソートし、それからこの特定のトレースに寄与しているセグメントを見ていきます。以下は、DynamoDBとSNSの呼び出しを含むものです:

今注目しているエントリーポイントから呼び出されると、DynamoDBの呼び出しに長い時間がかかっていることが分かります。DynamoDBの呼び出しは1桁ミリ秒で実行されるので、もっと詳しく見る必要があります。メタカラムに注目し、ドキュメントのアイコンをクリックし、リソースタブで何が起こっているかを見てみます:

クライアントSDKが何回かリトライをしていることが分かります。これは、テーブルが追加の読み出しか書き込みのスループットをプロビジョンする必要があるためと考えられます。

X-Ray UIはフィルタ表現というコンセプトで作られています。2,3の主要機能のために専用のUI要素がありますが、残りは(開発者指向のツールに最適な)ページの上部のテキストボックスに入力できる自由形式フィルタを利用しています。以下は、いくつかの非常に単純な例です:

  • responsetime > 5 – レスポンス時間が5秒以上
  • duration >= 5 AND duration <= 8 – 期間が5〜8秒
  • service(“dynamodb") – DynamoDBの呼び出しを含むリクエスト

また、日付、トレースID、HTTPメソッド&ステータスコード、URL、ユーザエージェント、クライアントIPアドレス、その他でフィルタすることもできます。

今お見せした全て(そしてそれ以上のもの)がX-Ray APIやAWS Command Line Interface (CLI)でアクセス可能です。これによって、あらゆる種類のハイレベルなツール、可視化、またはパートナーに対してオープンです。何か作ったら、ぜひ私に教えて下さい!

今から利用可能

AWS X-Rayは12の全パブリックリージョンでプレビューとして利用可能で、今日から使い始められます!

Jeff;

原文: AWS X-Ray – See Inside of Your Distributed Application (翻訳: SA岩永)