この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ウェブパフォーマンスのレイテンシを計測する場合、リクエスト全体の平均やパーセンタイル(p90など)を用いる事が多いですが、期待通りにレイテンシーを測定できていないケースがあります。
Amazonが、これらの指標からトリム平均とヒストグラム方式に切り替え、ユーザー観点でレイテンシを改善した事例が Re:invent で紹介されていたので共有します。
セッションについて
セッションタイトル
AMZ302:How Amazon uses better metrics for improved website performance
セッション概要
In this session, learn how you can improve your website latency with Amazon.com insights on latency metrics and goals. Find out how Amazon optimizes customer experience with website latency metrics. Discover why the new Amazon CloudWatch trimmed mean metric is preferred over other metrics, how it’s used, and what benefits it offers. Also learn about how Amazon uses goals for new latency measurements to avoid past pitfalls and how you can apply Amazon learnings in your own environments.
資料
スピーカー
VP, Distinguished Engineer Amazon.com
Jim Roskind氏はAmazonジョイン前には、Infoseek、Netscape、Googleなどに勤め、HTTP/3で使われているQUICに大きく貢献しています。
レイテンシと正しいメトリクスが大事な理由
ユーザーは、アクセスしたウェブサイトがすぐに表示されることを期待します。
ECサイトにおいては、レイテンシーが10−40ms上下しただけでも、売上が大きく変動します。
AmazonのECサイトで、メトリクスを変更し、レイテンシを30−40％しました。
正しいメトリクスを利用すれば、リグレッションにもすぐに気づけます。
メトリクスに平均を利用すると?
レイテンシを平均(mean)で計測するのはどうでしょうか?
すべてのデータポイントの平均を利用すると、極端に遅い、ロングテールなデータポイント(外れ値)に平均値が引きずられてしまいます。
たとえば、TCP接続で、85msなこともあれば、24時間なこともあります。 極端に遅い、24時間に平均値が引きずられてしまいます。
Understats も危険
「99％のページを、99％の顧客に1秒以内にレスポンスしている」というようにしきい値を設定し、それ以下の値を同じようにみなして評価することがあります(Understats)。
1秒以内であれば、0.5秒も0.99秒も同じですし、1秒を超えている限り、2秒も4秒も同じです。
しきい値(fenceposts=塀の柱)を堺に、いい値とわるい値が別れます。
ラウンドトリップに400msかかるエリアにおいて、TCPの1 RTTとTLSの2 RTTで1リクエストに合計400ms x 3 = 1.2 秒かかる場合、fenceposts方式の1秒のレイテンシの壁は改善しようがありません。 さらには、機能を追加してレイテンシが伸びても、もともと1秒を超えているレイテンシが更に伸びたところで、指標に影響がありません。
このような状況に陥っていると、レイテンシを正しく計測できているとは言えないでしょう。
パーセンタイルも危険
p50/p90のようなパーセンタイルで計測しても、別の問題があります。
もし分布が正規分布に従うのであれば、p50やp90の指す値は意味があります。
しかし、p50やp90のようなターゲットを設定すると、レイテンシもこの値を超えないように最適化され、それぞれのターゲットに合わせた複数の最頻値(モード)をもった分布となることがあります。
パーセンタイルの値だけを見ていると、問題には気づきにくいですが、ヒストグラムをプロットすると、一目瞭然です。
トリム平均
そこで登場するのが、トリム平均です。 トリム平均では、データ全体の両側N％を除外した平均を利用します。
TM99(99%のトリム平均)の場合、両側1％を除外した平均値です。
トリム平均は実社会でも利用されています。
体操競技のEスコアは5人の審判が採点し、最高点と最低点を除外した3人の平均点を利用します(TM80)。
トリム平均で除外するの全体のデータに対する％ベースです。特定のしきい値を設定し、しきい値を超えたデータを除外するわけでは有りません。
TM99を設定していて値が変わらなければTM99.9、TM99.9で値が変わらなければ、TM99.99をターゲットにしましょう。
トリム平均に変更した効果をヒストグラムで確認
レイテンシをヒストグラムでプロットすると、改善状況が明快になります。
p50・p90のパーセンタイルを利用していた頃は、モードが2つ有りました。
時間が経過するに従い、カーブが左により、滑らかになっていくのがわかります。
WindowsのChromeからのTCP接続レイテンシをヒストグラム
正規分布のように見えますが、実際はX軸はログスケールです。 レイテンシをヒストグラムにする際は、X軸をログスケールにしましょう。
このヒストグラムにおいて、左端の10ms以下のエリアは、新規のTCP接続ではなく、右端の3000ms以上のエリアの多くは、SYNに対するACKが返ってこず、Windowsでタイムアウトが発生しています。
所管
セッションタイトル「AMZ302:How Amazon uses better metrics for improved website performance」からは、ウェブサイトパフォーマンスの一般論を想像しますが、セッションの中身は、2021年7月にリリースされたCloudWatch Metricsのトリム平均のユースケースの紹介です。
本レポートでは「トリム平均」の概念を中心に紹介しましたが、今回端折ったセッション後半では、CloudWatch Metricsを実例に、トリム平均の運用が解説されています。 合わせてご確認ください。
レイテンシなど、外れ値のある値を改善したい場合、平均・パーセンタイルだけでなく、トリム平均やX軸をログスケールにしたヒストグラムも検討しましょう。
Brendan Gregg御大も、レイテンシ計測にトリム平均を利用しています。
Frequency Trails: What the Mean Really Means
それでは。
2
