ALBのレスポンスタイムの統計量としてパーセンタイルを参照する

はじめに

最近読んでいたデータ指向アプリケーションデザインでレスポンスタイムの平均値と中央値について記述があって目から鱗だったので改めて確認してみました。

平均値(算術平均）と50パーセンタイル値

レスポンスタイムの統計量として平均値（算術平均）は馴染みがある統計量かと思います。 典型的なレスポンスタイムを知りたい場合には、平均値はあまり優れた計測値ではありません。 平均値は実際に観測された値ではなく外れ値の影響を受けるためです。

50パーセンタイル値（中央値）

そこでより良い統計量として挙げられるのが、パーセンタイル(percentile)です。 データを小さい順に並べたとき、初めから数えて全体のn %に位置する値がnパーセンタイルです。

たとえば、レスポンスタイムの50パーセンタイル(中央値）が 200 ミリ秒だったら、これはリクエストの半分に対して 200 ミリ秒以下でレスポンスが返されたということであり、もう半分のリクエストにはそれ以上の時間がかかったということです。

つまり、ユーザーのリクエストの半分に対しては、中央値のレスポンスタイム以下でレスポンスが返されており、残りの半分ではそれ以上の時間がかかっていることがわかります。

ALBのパーセンタイル統計値の確認方法

CloudWatchを使う方法

ALBのレスポンスタイムのパーセンタイル統計値はCloudWatchで確認できます

参考: [CloudWatch] パーセンタイル統計値がELBなどで利用可能になりました

Amazon Athenaを使う方法

CloudWatchのメトリクスはALBが処理する全てのリクエストでの値となります。通常レスポンスタイムはURLごとに特性が異なるためURLごとの値を知りたくなります。 その場合Amazon Athena上にALBのアクセスログを参照するテーブルを作成しクエリすることでより細かな値を求めることができます。

Application Load Balancer ログのクエリ にある手順でテーブルを作成後、次のクエリのようにapprox_percentileを使うことでURLごとのレスポンスタイムの各パーセンタイル値を求めることができます。

以下の例ではURLごとに複数のパーセンタイル値（50, 90, 95)を求めています。

select  request_url, 
approx_percentile(target_processing_time, 0.50) as percentile_50,
approx_percentile(target_processing_time, 0.90) as percentile_90,
approx_percentile(target_processing_time, 0.95) as percentile_95
from alb_logs
group by request_url;

実際に使うときには以下のような点をさらに考慮する必要があると思います。

• 任意の時間間隔で丸める(5分ごと、１時間ごとなど）
• URLに含まれるクエリパラメータの正規化
• botなどからのアクセスを除外する

まとめ

• レスポンスタイムの統計量として平均だけでなくパーセンタイル値も参照するのが望ましい
• パーセンタイル値はCloudWatchおよびAmazon Athenaで確認できる

参考

性能エンジニアリング入門（2）：負荷テストのデータ、読めてますか？ (1/2)