← AWSサービスの内部原理 コース
68. 平均は嘘をつく — p99が語る、平均が隠す遅いリクエストの世界
CloudWatchが返すのは生のデータではなく「period内の統計」だけ——その要約が何を語り、何を隠すのかを、平均が嘘をつく瞬間から図で追っていきます。
① CloudWatchが返すのは「値」ではなく「period内の統計」
period = 5分あなたが指定する集計期間
CloudWatchが期間内で集計
生データ点の集合例: 10ms, 10ms, …, 5000ms
SampleCountデータ点の個数
Sum全値の合計
AverageSum ÷ SampleCount
Min / Max期間内の最小・最大
Percentile分布の中の相対的な位置
- 公式定義:「Statistics are metric data aggregations over specified periods of time.」period = 1, 5, 10, 30、または60の倍数(秒)。デフォルトは60秒。
- SampleCount =「the number of data points during the period」、Sum =「the sum of the values of the all data points collected during the period」。
- Average =「the value of Sum/SampleCount during the specified period」——平均は定義上、合計を個数で割ったもの。
- Minimum / Maximum =「the lowest / highest value observed during the specified period」。
CloudWatchのグラフに現れる1本の線は、生データそのものではなく「period内の要約」だ。同じ生データでも、どの統計を選ぶかで見える世界がまったく変わる。
② 平均は嘘をつく — 99本が速くても平均は「みんな速い」と言う
100本のリクエストレイテンシの生データ
Sum = 99×10 + 5000 = 5990ms、SampleCount = 100
99本: 各10ms速い、正常
1本: 5000ms5秒、異常に遅い
しかし現実は…
Average ≒ 60ms「システムは平均60msで快適」
1%は5秒待ち平均はこの1本を「見えなく」した
- 5990 ÷ 100 = 59.9ms。1本の5秒が99本の10msに溶かされ、ダッシュボード上は「60ms前後の平穏な線」になる。
- 平均は分布の形を1つの数字に潰すため、「一部のユーザーが激しく待っている」事実を構造的に隠す。
平均が低いことは「全員が速い」ことを意味しない。平均は外れ値を薄める要約であり、遅いリクエストの存在を数字の上で消してしまう。
③ p99が語るのは「外れ値を除いた最悪ケース」— 公式も「パーセンタイルを使え」と言う
パーセンタイル分布の中での「相対的な位置」を測る
3つの統計を並べると
p50 (中央値)半分がこの値以下
p9595%がこれ以下、残り5%が上
p9999%がこれ以下、残り1%(外れ値)が上
= 外れ値を除いた「最悪ケース」Average異常を「隠す」
Maximumたった1つの異常に「歪められる」
Percentile分布そのものを見せる
- 公式:「p95 is the 95th percentile and means that 95 percent of the data within the period is lower than this value and 5 percent of the data is higher than this value.」
- 公式:「If you monitor the average, this can hide anomalies. If you monitor the maximum, a single anomaly can skew the results. Using percentiles, you can monitor the 95th percentile…」——原文はEC2のCPU使用率監視を例にした一節だが、平均・最大値・パーセンタイルの性質そのものはレイテンシでも同じ構造で効く。
- p99は「the maximum value of the remaining 99%」——上位1%を外れ値として除いた後の、残り99%の最大値。
平均は異常を隠し、最大値は1つの異常に歪められる。だから公式は「パーセンタイルを使え」と言う。②で平均が消した5秒のリクエストは、p99では正しく姿を現す。
④ 分布は要約から復元できない — パーセンタイルには生データが要る
生データ点の集合10, 10, 10, …, 5000
この4つの数から「95%地点の値」を逆算できるか?
統計セットSum / Min / Max / SampleCount
できない同じ要約を持つ分布は無数に存在する
分布の「形」は要約に残っていない- 公式:「CloudWatch needs raw data points to calculate percentiles.」
- 統計セットからパーセンタイルを取れる例外は次のいずれかが真のときだけ:「The SampleCount value of the statistic set is 1 and Min, Max, and Sum are all equal.」/「The Min and Max are equal, and Sum is equal to Min multiplied by SampleCount.」——いずれも実質「全データが同一値」で分布が消えている縮退ケース。
- さらに「Percentile statistics are not available for metrics when any of the metric values are negative numbers.」(負の値を含むメトリクスではパーセンタイル不可)。
- DynamoDB編のハッシュと同じ「一方向性」の別の顔: ハッシュがキーを固定長の値へ潰して元に戻せなかったように、集計は分布を数個のスカラーへ潰し、元の形を復元できない。集計は情報を捨てる非可逆変換である。
平均や合計は要約から作れるが、パーセンタイルは作れない。分布の形を捨てた後では、その形を問う質問にはもう答えられない——情報の非可逆性が、監視設計の制約として現れる。
⑤ 統計セットで送る最適化 — 毎ヒット送らず、1分に1回まとめる
毎秒何百ヒットWebページのリクエストレイテンシ
それぞれの代償
案A: 毎ヒット送信PutMetricDataをヒットごとに呼ぶ
案B: 統計セット1分ローカル集計しMin/Max/Sum/SampleCountを1回送る
高コスト・高負荷だが生データが残る
低コスト・大規模向きだがパーセンタイル不可(④の非可逆性)
- 公式:「For large datasets, you can insert a pre-aggregated dataset called a statistic set. With statistic sets, you give CloudWatch the Min, Max, Sum, and SampleCount…」
- 公式の例示:「suppose you have a metric for the request latency of a web page. It doesn't make sense to publish data with every web page hit.」——全ヒットのレイテンシを集め、1分ごとに集計して統計セットとして送ることを提案している。
- ただし④の通り、統計セットで送った時点でパーセンタイルは(縮退ケースを除き)取れなくなる。コスト削減とパーセンタイル可用性はトレードオフの関係にある。
統計セットは「1分集計して1回送る」ことでコストと負荷を下げる正攻法だが、その代償として分布を捨てる。平均・合計だけで足りる指標には最適、p99が要る指標には向かない——④の非可逆性が、そのまま設計判断になる。
⑥ 発展形 tm99 — p99は「残り99%の最大値」、tm99は「残り99%の平均」
大きい順に整列生データを値の大きい順に並べる
残り99%をどう要約するか
上位1%を捨てる最も遅い外れ値を除外
p99残り99%の「最大値」= 外れ値を除いた最悪の体験
tm99残り99%の「平均」= 外れ値を除いた典型的な体験
公式はレイテンシ監視にこちらを推奨- 公式:「Both p99 and tm99 ignore the 1% of the data points with the highest values… After that, p99 is the maximum value of the remaining 99%, while tm99 is the average of the remaining 99%.」
- 公式:「p99 tells you the worst customer experience, ignoring outliers, while tm99 tells you the average customer experience, ignoring outliers.」
- 公式:「We recommend that you use trimmed mean for monitoring latency.」さらに「Trimmed mean is a good latency statistic to watch if you are looking to optimize your customer experience.」とも述べている。
- tm99 = TM(:99%) と同じ。トリム平均も生データを必要とする(④の要件はトリム平均・IQM・Winsorized meanなどにも適用)。
- パーセンタイル対応サービス(公式リスト): API Gateway / Application Load Balancer / Amazon EC2 / Elastic Load Balancing / Kinesis / Lambda / Amazon RDS。
- API Gateway編・Lambda編で追ったレイテンシは、実は平均でなくp99——あるいはtm99——で測るべきだった、という答え合わせ。分布・外れ値・ロングテールという統計学の基礎が、そのまま監視ダッシュボードの読み方に直結する。
②で平均が消した5秒のリクエストを、p99は「最悪ケース」として、tm99は「外れ値を除いた典型」として救い上げる。そして公式が明言する通り、レイテンシにはトリム平均——「異常に振り回されない、代表的なユーザー体験」を測る統計が推奨される。