レイテンシーを適切に測定するには、高品質のデータが必要です。KPMG の 2016 年 Global CEO Outlook (リンクは ibm.com 外部) によると、CEO の 84% が意思決定の根拠となるデータの品質を懸念しており、その理由はデータが誤解を招くことが多いためです。
データを重視する企業とそうでない企業の違いは大きいです。MIT の研究者らは、データ駆動型設計を採用した企業は、他の投資やテクノロジーの使用を考慮すると予想されるよりも 5%~6% 高いアウトプットを出していることを発見しました (リンクは ibm.com® 外部)。この理由だけでも、レイテンシーの理解がビジネスの成功に不可欠であることがわかります。
わずか 7 分で、レイテンシーの測定について知っておくべきことをすべて学習できます。
Dictionary.com (リンクはibm.com外部) では、レイテンシーを「ハードウェア システムの 1 つのコンポーネントが、別のコンポーネントによるアクションの実行を待機している間の遅延期間」と定義しています。より簡単に言うと、関数を呼び出してから実際に実行されるまでの時間を意味します。レイテンシーはすべてのシステムに固有のものです。たとえ存在しない完璧なシステムがあったとしても、コンピュータ内の電子がトランジスタをオンからオフに、またはその逆に切り替えるのにかかる時間は潜在的なものになります。
オペレーションが小規模な場合のレイテンシーは問題ではありませんが、何百万ものオペレーションを処理すると、何百万ものレイテンシーが急速に増加します。レイテンシーは作業単位や時間によって定義されるのではなく、その動作方法によって定義されます。監視ツールは、関数の開始から関数の終了までにかかる時間を報告します。
レイテンシーはビジネスに大きな影響を与える可能性があります。たとえば(リンクはibm.com外部)、「モバイルの速度に関しては、1秒も無駄にできません。モバイルページの読み込みに1秒かかるごとに、コンバージョンが最大20%減少する可能性があります。」
レイテンシーは、通常のガウス分布やポアソン分布に従うことはほとんどありません。レイテンシーがこれらの分布のいずれかに従っている場合でも、レイテンシーの観察方法により、平均値、中央値、標準偏差さえも役に立たなくなります。たとえば、ページの読み込みを測定している場合、これらの読み込みの99.9999999999%が中央値よりも悪くなる可能性があります。これは、遅延をランダムにサンプリングすると不正確なデータが発生する理由の1つですが、このテーマについては後ほど詳しく説明します。
この時点で、標準偏差を一切使用しないなら、どうやってレイテンシを意味ある形で説明できるのかと疑問に思っているかもしれません。その答えは、パーセンタイルと最大値に注目しなければならないということです。多くの人は、「なるほど、P95を見れば『一般的なケース』がわかるんだな」と考えます。しかしこの方法の問題点は、P95では悪いケースがすべて隠れてしまうことです。Azul Systems の CTO である Gil Tene 氏は、次のように述べています。「これは「これは『マーケティングシステム』だ。誰かが騙されている。」
たとえば、次のグラフを考えてみましょう。
このグラフを見ると、その中央値と平均値に実際的な重要性がない理由が明確にわかります。なぜなら、これらは問題領域を示していないのです。95パーセンタイルが左側に急上昇しているのを見ると、問題の核心を捉えているように思えます。もちろん、それは真実ではありません。プログラムに不具合が生じた原因を調査する際、実際に発生した最悪の5%の事象を見落としているのです。このような急上昇が発生するには、上位5%のデータが著しく悪化している必要があります。
次に、99.99パーセンタイルを示す同じグラフを見てみましょう。
赤い線は 95 パーセンタイル、緑の線は 99.99 パーセンタイルです。はっきりとわかるように、95 パーセンタイルは 22 の問題のうち 2 つと、データの全範囲を確認する必要がある理由しか示していません。
多くの人は、最後の5%のデータはそれほど重要ではないと考えているかもしれません。確かに、仮想マシン(VM)の再起動やシステムの一時的な不具合など、些細な事象かもしれません。しかし、それを無視することは「そんなことは起こらない」と決めつけることに等しく、実は最も注力すべき重要な事象の一つである可能性を否定しているのです。
Gil Tene 氏は、大胆に主張することを好みます。「決して排除すべきではない第一の指標は最大値です。それはノイズではなく、信号そのものです。それ以外の部分はノイズに過ぎません。」確かに最大値は大規模システムにおいて重要な指標ですが、最大ケースのみを追求することは現実的でない場合が少なくありません。完璧なシステムは存在せず、不具合は発生します。大規模な実用システムにおいて、最大ケースのみを追求することは、開発チームを疲弊させることにつながりかねません。
99.99 パーセンタイルを見ると、大多数の顧客に何が起こっているかがわかります。そこに見られる急上昇は実際の問題であることがわかりますが、最大値の急上昇は、単にシステムの一時的な問題である可能性があります。DevOps チームがこれらの小さな問題に注力すると、より重大な問題に取り組むことができなくなり、大きな機会損失を被ることになります。
99.99 パーセンタイルと最大値が非常に近い場合 (そして両方とも急上昇している場合)、それはチームが取り組むべき問題であるという大きなシグナルであることに留意してください。このように、最大値は優れた信号であるというGilの意見は正しいですが、残りのデータは単なるノイズであるという意見は誤りです。このグラフでわかるように、前の例の 99.99 パーセンタイルと最大値は正確に一致します。これは、見ているものが単なる一時的な問題ではなく、実際のバグであることを示す優れたシグナルです。
95 パーセンタイルだけを見るよりもさらに陥りやすい落とし穴は、パーセンタイルが平均化されていることを認識できないことです。パーセンタイルを平均化することは統計的には無意味です。見ているものの意味がすべて失われてしまいます。レイテンシーを見るときに平均値は適切ではないことはすでに説明しましたが、平均パーセンタイルを見ていると、振り出しに戻ってしまうだけです。多くのソフトウェア プログラムはパーセンタイルを平均化します。たとえば、次のGrafanaチャートを見てみましょう。
これまで気づいていなかったかもしれませんが、このグラフのパーセンタイル値はすべて平均値です。X軸の凡例に明記されています。ほぼ全ての監視サービスはパーセンタイル値を平均化します。これは事前計算の性質上避けられない現実です。監視サービスがデータを取得すると、その分単位のデータについてパーセンタイル値を計算しているのです。
95パーセンタイルを見ると、これは全パーセンタイルの平均値を示しています。「良い結果」を優先してサービスを高速化するこの近道は、実際にはデータから統計的有意性を完全に排除しているのです。
ご存じかもしれませんが、データサンプリングに参加している監視ツールによって、平均化されたデータを生成しています。ほぼすべての監視ツールがデータをサンプリングします。たとえば、Datadogでは大きなデータ損失が発生しています。1 分間に 300 万ポイントを送信しても、すべてを取得することはできません。代わりに、ポイントをランダムにサンプリングし、1 分あたり 1 ポイントに集計します。
レイテンシーを理解するには、サンプリングされていないデータが必要です。サンプリングされたデータでは、完全な分布にアクセスすることは本質的に不可能です。あなたの最大値はあなたの真の最大値ではなく、あなたのグローバルパーセンタイルは何が起こっているかを正確に表しているわけでもありません。
データをサンプリングすると、データが省略されます。たとえば、1 分間に 10,000 件のオペレーションが発生し、それぞれ 2 つのデータポイントが監視システムに送信されているとします。システムにバグがあり、これらのデータポイントの1つが10,000回のオペレーションごとにこのバグを示しているとします。監視システムが、このバグを最大値として表示するデータ ポイントとして選択する確率は、わずか 1/20,000 です。
十分に長く実行すると、データ ポイントは最終的に表示されますが、成果としては、1 分ごとに顧客の 1 人に発生しているにもかかわらず、散発的なエッジ ケースのように見えます。データをサンプリングしない場合、このようなスパイクの 1 つが発生すると、それが 99.99 パーセンタイルに明確に表示され、最大値もそれに近い値に表示され、プログラムにバグがあることが示されます。しかし、データをサンプリングすると、それほど頻繁には現れなくなるため、バグではなく一時的な問題として認識されることになります。この結果は、エンジニアリング・チームがその重要性を認識できないことを意味します。
監視ツールに騙されて、レイテンシーで何が起こっているかを把握していると思い込まないでください。IBM Instana®ソフトウェアの主要な機能の1つは、レイテンシーを効率的に測定できることです。IBM Instanaソフトウェアは、高度な分析と機械学習(ML)を使用して、レイテンシーの問題をリアルタイムで自動的に検知するため、開発者とITチームはパフォーマンス上の問題の根本原因を迅速に特定し、ユーザーに影響が及ぶ前に是正措置を講じることができます。
サンプリングされたデータを提供しないツールを選択しましょう。グローバルパーセンタイルを平均化しないツールを選択してください。
IBM Cloud Pak for Network Automationは、ネットワーク・インフラストラクチャー運用の自動化とオーケストレーションを可能にするクラウド・パックです。
IBMのクラウド・ネットワーキング・ソリューションは、アプリケーションとビジネスを強化する高性能な接続を可能にします。
クラウド・ネットワーキングなどにおけるデータセンター・サポートをIBM Technology Lifecycle Servicesで統合しましょう。