平均値が役に立たない理由とパーセンタイルの有用性

アプリケーションの監視や分析を行ったことのある方なら、平均値を利用されたことがあるでしょう。平均値は理解しやすく、計算も簡単です。しかし、平均値が世界を描き出すイメージがいかに誤っているかについては、私たちはつい見過ごしがちです。この点を強調するため、最近新聞で読んだ、パフォーマンス分野以外の現実世界の例をご紹介しましょう。

その記事によれば、ヨーロッパのある地域における平均給与は1,900ユーロでした（念のため申し上げますと、この地域ではこれは良い金額です！）。しかし、詳しく調べてみると、大多数の人々、具体的には10人中9人が約1,000ユーロしか稼いでおらず、1人だけが10,000ユーロを稼いでいることが判明しました（もちろん、これは非常に単純化した例ですが、お分かりいただけると思います）。 計算すれば、確かに平均は1,900ユーロとなりますが、日常生活で私たちが「平均」という言葉を使う意味での「平均的な」給与とは言い難いでしょう。では、この考え方をアプリケーションのパフォーマンスに当てはめてみましょう。

平均応答時間

平均応答時間は、アプリケーションパフォーマンス管理において圧倒的に最も一般的に使用される指標です。これは「正常な」トランザクションを表すと想定されますが、これは応答時間が常に同じ（すべてのトランザクションが同等の速度で実行される）場合、または応答時間の分布がほぼベルカーブ（正規分布）である場合にのみ当てはまります。

ベルカーブでは、平均（算術平均）と中央値は一致します。つまり、観測されたパフォーマンスはトランザクションの大部分（半分以上）を反映していることになります。

現実には、ほとんどのアプリケーションには少数の極端な外れ値が存在します。統計学的には、この分布曲線はロングテールを持つと言えます。ロングテールは、遅いトランザクションが多数存在するのではなく、標準値よりも数桁遅いトランザクションが少数存在する状態を意味します。

平均値がもはやトランザクションの大半を代表せず、中央値よりもはるかに高くなる可能性があることを認識しております。

平均値が中央値よりも良く見えなければ問題ないと主張されるかもしれません。私は異論がありますが、多くの顧客が経験する別の現実的なシナリオを見てみましょう：

このケースでは、かなりの割合のトランザクション（10～20％）が非常に高速である一方、大部分のトランザクションは数倍遅くなります。中央値は依然として真実を伝えますが、平均値は突然、実際のトランザクションの大半よりもはるかに高速に見えるようになります。これは検索エンジンやキャッシュが関与する場合に典型的です。一部のトランザクションは非常に高速ですが、大部分は標準的です。 この現象が生じる別の理由として、失敗したトランザクション、特に高速に失敗したトランザクションが挙げられます。多くの実世界のアプリケーションでは、ユーザーエラーや検証エラーにより1～10％の失敗率が生じます。これらの失敗トランザクションは正常なトランザクションよりも桁違いに高速であることが多く、結果として平均値を歪めてしまいます。

もちろん、パフォーマンス分析担当者は愚かではなく、より高頻度のチャート（視覚的に小さな集計単位を見ることで補正）や観測された最小・最大応答時間の採用によって、定期的に補正を試みます。しかし、これを実行できるのは、アプリケーションを非常に熟知している場合に限られることが多いのです。アプリケーションに不慣れな者は、チャートを容易に誤解する可能性があります。この分析に必要な知識の深さと種類のため、分析結果を他者に伝えることは困難です。 この問題がITチーム間でどれほどの議論を引き起こしてきたか、考えてみてください。しかもこれは、ビジネスステークホルダーとのコミュニケーションについて考える前の段階です！

より優れた指標はパーセンタイルです。分布を理解できるためです。ただしパーセンタイルを検討する前に、すべての運用監視ソリューションに共通する重要な機能、自動ベースライン設定とアラート機能について見ていきましょう。

自動ベースライン設定とアラート機能

実稼働環境では、パフォーマンスが低下しビジネスやユーザーに悪影響を及ぼす場合にのみ注目が集まります。では、悪影響を未然に防ぐために、パフォーマンス問題を迅速に特定するにはどうすればよいでしょうか？遅延するトランザクションは常に一定数存在するため、全てにアラートを設定することは現実的ではありません。さらに、多くの運用チームは多数のアプリケーションを管理しており、全てに精通しているわけではないため、手動での閾値設定は不正確で手間がかかり、時間を要する作業となります。

業界では「自動ベースライン設定」と呼ばれる解決策が考案されました。ベースライン設定は「正常な」パフォーマンスを算出し、アプリケーションの速度低下や通常以上のエラー発生時にのみ警告を発します。ほとんどのアプローチは平均値と標準偏差に依存しています。

統計的な詳細には立ち入らず説明しますと、この手法もまた応答時間が正規分布に従うことを前提としています：

一般的に、標準偏差の2倍を超えるトランザクションは遅延とみなされ、分析対象として捕捉されます。平均値が大幅に変化した場合にアラートが発生します。ベル曲線では、これは最遅の16.5％（もちろん調整可能です）に相当しますが、応答時間分布がベル曲線を形成していない場合、この手法は不正確になります。 その結果、誤検知（平均より大幅に遅いが分布曲線上では正常範囲内にあるトランザクション）が多発するか、あるいは問題を見逃す（偽陰性）かのいずれかとなります。さらに、分布が正規分布でない場合、平均値と中央値が大きく異なる可能性があり、そのような平均値に標準偏差を適用すると、予想とは大きく異なる結果が生じる恐れがあります。 この問題を回避するため、これらのアルゴリズムには多くの調整可能な変数と、特定のユースケース向けの「ハック」が数多く用意されています。

パーセンタイルと平均値

パーセンタイルは、曲線のどの部分を見ているのか、そしてその指標がどの程度のトランザクション数を表しているのかを示します。これを視覚化するために、以下のグラフをご覧ください：

上記のグラフからわかるように、平均値は非常に変動が激しいです。他の2本の線は中央値と⁹⁰パーセンタイルを表しています。中央値は比較的安定していますが、いくつかの跳躍が見られます。これらの跳躍は、トランザクションの大半（50%）における実際のパフォーマンス低下を意味します。^{90パーセンタイル}（「尾部」の始まり）はさらに変動が大きく、外れ値の遅延はデータやユーザー行動に依存します。ここで重要なのは、平均値がトランザクションの大部分ではなく、⁹⁰パーセンタイル（尾部）によって大きく影響（引きずられ）を受けている点です。

応答時間の⁵⁰パーセンタイル（中央値）が500msである場合、これはトランザクションの50%が500ms以下、あるいはそれより高速であることを意味します。同じトランザクションの⁹⁰パーセンタイルが1000msである場合、90%がそれ以下、つまり高速であり、遅いのは10%のみであることを示します。 この場合の平均値は、500ミリ秒を下回る場合（フロントカーブが重い場合）、大幅に上回る場合（ロングテール）、あるいはその中間となる可能性があります。パーセンタイルは応答時間曲線の一部を示すため、実際のパフォーマンスをより正確に把握できます。

まさにこの理由から、パーセンタイルは自動ベースライン設定に最適です。例えば50パーセンタイルが500ミリ秒から600ミリ秒に上昇した場合、トランザクションの50％で20％のパフォーマンス低下が発生したことを意味します。この変化には対応が必要です。

多くの場合、このような状況では75パーセンタイルや90パーセンタイルは全く変化しません。これは遅いトランザクションがさらに遅くなったわけではなく、通常のトランザクションだけが遅くなったことを意味します。テール（分布の末端部分）の長さによっては、平均値が全く動いていない可能性すらあります！

別のケースでは、98パーセンタイルが1秒から1.5秒に低下する一方で、95パーセンタイルは900ミリ秒で安定している場合があります。これはアプリケーション自体は安定しているものの、ごく一部の異常値が悪化したことを意味し、直ちに懸念すべき事態ではありません。パーセンタイルに基づくアラートは誤検知が発生せず、変動が少なく、重要なパフォーマンス低下を見逃すこともありません。 したがって、パーセンタイルを用いたベースライン設定アプローチは、効果的に機能するために多くの調整変数を必要としません。

以下のスクリーンショットは、パーセンタイルベースのアラートが誤検知に悩まされず、変動が少なく、重要なパフォーマンス低下を見逃さない仕組みを説明しています。

パーセンタイルをチューニングに活用する方法についてご説明いたします。

パーセンタイルはチューニングや最適化の具体的な目標設定にも非常に有効です。例えば、アプリケーション内の処理が全体的に遅く、高速化が必要な場合を考えてみましょう。この場合、90パーセンタイルの削減に注力します。これによりアプリケーション全体の応答時間が確実に短縮されます。 一方で、許容できないほど長い外れ値が存在する場合、98パーセンタイルや99パーセンタイルを超えるトランザクション（外れ値のみ）の応答時間短縮に注力すべきです。90パーセンタイルでは問題ないパフォーマンスを示しながら、98パーセンタイルが桁違いに悪化するアプリケーションを数多く目にします。

一方、スループット重視のアプリケーションでは、大多数のトランザクションを高速化しつつ、最適化によって少数の外れ値が遅くなることを許容します。そのため、90パーセンタイルを安定させたり、大幅に悪化させないようにしつつ、75パーセンタイルの改善を図る場合があります。

平均値や最小値、最大値では同様の観察はできませんが、パーセンタイルを用いれば非常に容易に把握できます。

結論

平均値はあまりにも単純化され、一面的であるため効果的ではありません。パーセンタイルは、アプリケーションの実際のパフォーマンス特性を理解する上で非常に優れた、かつ容易な方法です。また、自動的なベースライン設定、動作学習、適切な焦点を持ったアプリケーション最適化の基盤としても優れています。要するに、パーセンタイルは非常に有用です！