Amazon Web Services ブログ

アプリケーションパフォーマンスのパーセンタイルと AWS アプリケーションロードバランサーへのリクエストのトレース

本日のゲストポストでは、同僚の Colm MacCárthaigh が新しいCloudWatch パーセンタイル統計およびロードバランサーの意味と利点について語ります。 また、個別のリクエストがロードバランサーに到着した時点からその進行を追跡でき、そのリクエストがアプリケーションに繋がるための新しいリクエストのトレース機能も紹介します。

— Jeff;

アプリケーションパフォーマンスのパーセンタイルメトリクス
AWS Elastic Load Balancer はすでに以前から Amazon CloudWatch メトリクスに含まれ、ロードバランサーのバックグラウンドで実行しながらインスタンスとソフトウェアのヘルス状態とパフォーマンスの可視化を提供します。たとえば、ELB はアプリケーションに送られたすべてのリクエストが負荷分散される応答時間を測定します。多くのカスタマーはアプリケーションのパフォーマンスを監視するために、ビルトインの平均と最大レイテンシーメトリクスを使用しています。また、インスタンスやコンテナを負荷の変動として追加や削除するためのきっかけとしてこういったメトリクスを使用することも一般的です。新しい CloudWatch パーセンタイルサポートに基づき、ELB Classic and Application Load Balancer(ALB) はアプリケーションの応答時間によりきめ細かなデータを提供します。こういった測定により範囲内のパフォーマンスをより正確に掴むことができます。たとえば、10 番目のパーセンタイルが 2 ミリ秒とすると、10% のリクエストは 2 ミリ秒以下かかることになり、99.9 番目のパーセンタイル値が 50 ミリ秒とすると、99.9% のリクエストは 50 ミリ秒以下かかっているという具合です。

パーセンタイルがどれだけ役に立つかという現実的な例としては、ほとんどのリクエストを 1 から 2 ミリ秒で高速キャッシュから処理するアプリケーションの場合、キャッシュが空になるとリクエストの処理はさらにずっと遅くなり、100 ミリ秒 から 200 ミリ秒の範囲までも落ちてしまいます。従来の最大メトリクスでは 200 ミリ秒台の最低速の案件のみが反映され、平均には高速と低速の回答が混合して示されることになり、どれだけのリクエストが高速または低速で処理され、そしてそれぞれがどれだけの速度であったかについての詳細はほとんど提供されませんでした。パーセンタイルメトリクスは、アプリケーションのパフォーマンスをリクエストの範囲を通して映し出し、より分かりやすい情報を提供します。パーセンタイルのメトリクスはアプリケーションに対してより有意義で積極的なパフォーマンスとして使用できます。たとえば、99番目のパーセンタイルを Auto Scaling のトリガーあるいは CloudWatch アラームとして使用すると、スケーリングのターゲットを設定できるために十分なリソースが提供されて 1% を超えないリクエストのみで 2 ミリ秒以上の処理時間がかかることになります。

リクエストのトレーシング内蔵
パーセンタイルはすべてのリクエストにおけるパフォーマンスの全体像を示すことでアプリケーションの可視性を大幅に向上させますが、AWS のアプリケーションロードバランサーの新しいトレーシング機能では、アプリケーションのパフォーマンスとヘルス状態を個々のリクエストの核心レベルまで掘り下げた理解を提供できます。ALB は現在 1 つの ALB へのすべてのリクエストにおける新しいカスタム X-Amzn-Trace-ID HTTP ヘッダーを探索しています。受信リクエストにこのヘッダーがない場合、ALB は次のようなヘッダーを生成します。

X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354

そしてこのリクエストをアプリケーションに渡します。ヘッダーがないため、この受信リクエストは「ルート」リクエストと考慮され、ALB が送る新しいヘッダーが無作為に生成されるルート属性に含められます。受信リクエストにヘッダーが付けられている場合、そのコンテンツは保持され、こうしてヘッダーはリクエスト間の系統やタイミングデータなどのトレーシングと診断状態を送付、保持します。たとえば、生成されるリクエストは次のようになります。

$ curl -H \
  "X-Amzn-Trace-Id: Root=1-58211399-36d228ad5d99923122bbe354; TimeSoFar=112ms; CalledFrom=Foo" \
  request-tracing-demo-1290185324.elb.amazonaws.com

このリクエストは ALB によって多少異なるヘッダーが生成されます。

X-Amzn-Trace-Id: Self=1-582113d1-1e48b74b3603af8479078ed6;\
  Root=1-58211399-36d228ad5d99923122bbe354;\
  TotalTimeSoFar=112ms;CalledFrom=Foo

この例にように受信ヘッダーが自身のルーツ属性に含まれる場合、ALB はそれを保持して無作為に生成される新しい「セルフ」属性を代わりに追加します。この例に TotalTimeSoFar および CalledFrom 属性は任意でありオプショナルとなり、そしてロードバランサー自体にとっては実際意味のないものですが、アプリケーションとトレーシングフレームワークがリクエスト間でデータを移動させるためにそのまま保持されます。受信リクエストにヘッダーを設定しないアプリケーションでは、ALB のリクエストのトレースはすべてのリクエストを一意に識別する働きをします。リクエスト間でヘッダーを送付するアプリケーションでは、トレース機能によってシステム全体におけるエントリポイントを容易に識別し、ルート属性によって関連するリクエストを検索し、アプリケーションがリクエストをつなぐ「パンくず」リストを作成できるようにします。X-Amzn-Trace-ID ヘッダーのコンテンツは Application Load Balancer アクセスログに記載され、これにはそれぞれのリクエストにおけるエラー表示やパフォーマンス測定が含まれ、個別のリクエストにおける事案の特定のための識別用に使用できます。

http 2016-11-08T00:04:13.109451Z app/request-tracing-demo/f2c895fd3ea253c5 \
  72.21.217.129:20555 172.31.51.164:80 0.001 0.001 0.000 200 200 276 550 \
  "GET http://request-tracing-demo-1290185324.elb.amazonaws.com:80/ HTTP/1.1" \
  "curl/7.24.0 (x86_64-redhat-linux-gnu) libcurl/7.24.0 NSS/3.16.1 \
  Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" - - \
  arn:aws:elasticloadbalancing:us-east-1:99999999999:targetgroup/echoheader/21a6f1501d2df426 \
  "Root=1-5821167d-1d84f3d73c47ec4e58577259"

パーセンタイル統計は今すべての Application Load Balancer に利用でき、CloudWatch コンソール、AWS SDKs、API からアクセスできます。既存の Application Load Balancer とすべての Classic Load Balancer へのサポートはこれから利用できる予定です。どちらの新しい機能も無償で導入されます。

— Colm MacCárthaigh、AWS Elastic Load Balancer