エッジにおけるキャッシュヒット率 : パフォーマンス調査

[以前の記事で](https://www.fastly.com/blog/truth-about-cache-hit-ratios)、キャッシュヒット率 (CHR) の意味について説明し、メトリックとは何か、またメトリックによってわからないものは何かを分析しました。また、CDN がクライアントにサービスを提供する方法を完全に理解できるように2つの異なる CHR メトリック (_CHR_edge_ および _CHR_global_) を必要とする理由も示しました。この記事では、_CHR_edge_ について掘り下げ、エンドユーザーのパフォーマンスに対する _CHR_edge_ の影響を説明します。では、準備はいいですか。チャートやグラフを見ていきましょう！ CDN では、おそらくデフォルトで _CHR_global_ メトリックが提供されています。しかし、CDN によって、両方のメトリックが提供されるか、簡単に計算するための手段が提供されると期待できます。そうでない場合でも、_CHR_edge_ をテストする方法があります。これらは当然、実際のユーザートラフィックメトリックほど優れてはいませんが、めったにフェッチされないキャッシュ可能なコンテンツまたはロングテールのキャッシュ可能なコンテンツを CDN がどのように処理しているかがわかる適切な指標が提供されます。このため、ここでは、テストを介したパフォーマンス測定の説明を通じて _CHR_edge_ の分析を示します。 一般的な CDN パフォーマンステストに関する誤り --------------------------------------------- CDN のパフォーマンスをテストする最も一般的な方法では、常に分散テストノードのネットワークを使用し、同じオブジェクトを繰り返しフェッチして、テスト期間を通じてレスポンス時間を分析します。以前は、ほとんどのテストツールは「バックボーン」ノードからしかテストを行いませんでした。そこでは、テストノードが大規模データセンターにデプロイされ、場合によっては CDN キャッシュサーバーに隣接していました。ユーザーの観点では、これは明らかに実際のパフォーマンスを反映していませんでした。また、ほとんどのサードパーティテストサービスではまだ主要機能としてバックボーンテストがありますが、一部はネットワークスロットリングまたは「ラストマイル」テストノード (実際のエンドユーザーインターネット接続などを使用) の提供に移行しています。また、RUM ベースツールも登場しています。ページにデプロイされた JavaScript タグを介してクラウドソースデータ収集を使用して、大容量のリアルユーザー測定値を生成しますが、こちらはさらに優れています。 ただし、現在では、より現実的な条件でデータを収集しているものの、私たちは依然として同じオブジェクトを繰り返しテストすることを強く勧めます。実際、ホームページからイメージを選んで、それをテスト用ネットワークにフィードして繰り返しフェッチするのがごく一般的な方法です。したがって、そのオブジェクトは最初からかなりアクセス回数が多い (ホット) 可能性が高くなります。たとえ、そうでなくても、テストの回数のためにホットオブジェクトに変わります。 [私の前の記事では](https://www.fastly.com/blog/truth-about-cache-hit-ratios)、CDN キャッシングモデルが、最もホットなオブジェクトをエッジに近づけておく方法について説明しました。非常にホットなオブジェクトのテストを続けると、どれだけキャッシングしてエッジから提供できるかという CDN の性能ではなく、CDN のフットプリントを実際にはテストしていることになります。大規模な作業セットとロングテールコンテンツの場合は特にそうなります。したがって、このテストスタイルでは、集合的な Web アセットのコンテンツ表現は実際にはテストされません。また、現実におけるエンドユーザーのパフォーマンスエクスペリエンス全般について知識が得られることもめったにありません。言い換えると、すべてのアプリに対するすべてのコンテンツに関して CDN のパフォーマンスをテストしているつもりでも、実際にテストしているのは、頻繁にアクセスされる1つのオブジェクトを CDN が提供する能力です。言うまでもなく、この2つはまったく違うことです。 エッジでのキャッシュヒット率のテスト --------------------------------------- 私は、CDN パフォーマンスを測定する際にやりがちなさまざまな間違いについて[講演](https://conferences.oreilly.com/velocity/devops-web-performance-eu-2015/public/schedule/detail/44588)を[2回](https://www.youtube.com/watch?v=gRLFws1btDA)行いましたが、そこではこれらの問題の多くを徹底的に掘り下げました。ここでは、その必要はないかもしれませんが、CHR について説明する上で、適切なテストを行えば、作業用セット全体でのコンテンツに関する実際の CDN のパフォーマンスを明らかにできることを示すよいタイミングだと思います。 これをテストする方法の1つは、[Catchpoint](http://www.catchpoint.com/) のテストスイートを使用することです。具体的には Catchpoint の「ラストマイル」ノードを使用します。これは、基本的に家庭にデプロイされるテスト用マシンで、実際のルーターや実際のインターネット接続に対して設置し、通常のユーザートラフィックがインターネットで流れている間にテストを行います。これによって、通常の帯域とレイテンシの制約がある実際のユーザー環境をテストで使用でき、バックボーンノードを使用するどのテストよりも現実的なパフォーマンスデータを得ることができます。 テストのために実際の条件を使用することは必須ですが、それだけでは十分ではありません。同じオブジェクトを何度も何度もテストする代わりに、いくつもの異なるオブジェクトをさまざまな間隔でテストします。また、フェッチされるオブジェクトはテストノードに固有であるため、あるテストによって別のテストのためにキャッシュが用意される危険はありません。この意図は、キャッシュ可能なものがまれにフェッチされるときの CDN のパフォーマンスをよく理解することです。これによって、ネットワークの末端でオブジェクトがどの程度キャッシュされるかが示されるはずです。CDN がすべてのテスト間隔で良好に機能している場合、エッジでのキャッシングがほとんどのコンテンツで適切であることを意味し、実際のユーザートラフィックで高い _CHR_edge_ を予想できます。間隔が広がるにつれてパフォーマンスが低下する場合は、ネットワークのエッジでオブジェクトがキャッシュからよくこぼれ落ちることを意味し、大規模作業セットでの _CHR_edge_ はあまり高くなりません。 私たちは多数の異なる間隔のテストを行っていますが、ここでは説明のために以下の結果を示します。 * 従来のテストで使用されるような、非常にホットなオブジェクト。これによって適切なベースラインも設定されます。 * 6時間に1回フェッチされるオブジェクト。 * 12時間に1回フェッチされるオブジェクト。 * 24時間に1回フェッチされるオブジェクト。 すべてのオブジェクトには、Cache-Control ヘッダーを介して非常に高い有効期間値 (TTL) が設定されているため、テスト中にキャッシュで期限切れになることはありません。 ここでちょっと一つ言わせてください。以下のすべてのデータは、Fastly を含む複数の CDN ベンダーでの多数のテストに基づいています。重要なのは CDN を非難することではありません。唯一の目標は、CDN がネットワークの末端でキャッシュする量が減るとどのようにパフォーマンスに影響するかを見せることです。したがって、すべてのデータを匿名で示して、どの数値がどの CDN のものかは記載しません。ただし、どの結果が Fastly のものかは説明します。 以下で説明するデータの詳細は次のとおりです。 * すべてのグラフは3週間分のデータを表します。 * 各テストでフェッチするのは1 KBの小さなオブジェクトです。分析される測定基準は、TTFB (最初のバイトまでの時間) です。これは (TCP 接続が確立された後で) リクエストが送信された時刻から、レスポンスの最初のバイトまでを測定します。TTFB は、キャッシュされたオブジェクトを CDN が提供できる速さの確認に使用する適切な測定基準です。TTFB が大きいほど、テストオブジェクトが提供されるエッジが遠くにあります。 * ここで示す結果は、米国内の約60のテストエージェントによって生成されたものです。各エージェントはホットオブジェクトを15分間に1回フェッチします。その他のオブジェクトは指定された間隔でフェッチされます。 ここではすべてのデータを示しませんが、次の2つの CDN では、スーパーホットオブジェクトを処理するようにはロングテールコンテンツを処理できていないようです。   これらのグラフでは、データが集計され、TTFB の日次中央値がフェッチ間隔ごとにプロットされています。CDN2は、12時間おきにフェッチされるオブジェクトでは CDN1よりもわずかに優れているものの、24時間おきにフェッチされるオブジェクトでは CDN1と同様によくありません。 このケースでは CDN1と CDN2のどちらでも、テストクライアントによるフェッチの頻度が少ないほど、オブジェクトの TTFB が悪影響を受けています。非常にホットなオブジェクトのパフォーマンスは良好であり、ネットワークの末端から一貫して頻繁に提供されています。しかし、テストの頻度が減るとパフォーマンスも低下します。つまり、ロングテールオブジェクトがネットワークの深いところから提供されているか、キャッシュでまったくヒットしていません。作業セットが大規模でオブジェクトがあまりフェッチされない場合には、これによって実際の世界での貧弱な _CHR_edge_ につながることがあります。もし _CHR_global_ を評価しているのであれば、これはこの CDN のパフォーマンスとは関係ありません。このメトリックはオリジンに対して実行するかしないかのみを測定するためです。言い換えれば、これらのオブジェクトはすべて実際に CDN のキャッシュから提供できます。しかし、それらのパフォーマンスが等しく高いことを必ずしも意味しません。 上記とは対照的な、ロングテールコンテンツのパフォーマンスに優れている、同じテストノードと期間での2つの CDN を示します。   CDN3と CDN4はどちらもホットオブジェクトについて問題ありません。また、ロングテールコンテンツに関しては CDN1および CDN2よりも優れています。ただし、CDN3は6時間おきと12時間おきのフェッチ間隔では優れていますが、24時間に1回フェッチされるオブジェクトでは非常に不安定な結果を示しています。CDN4は24時間おきのフェッチ間隔でははるかに安定していますが、クライアントリクエストの間隔が長くなるにつれ徐々に悪化しています。 最後に、フェッチ間隔と関係なく、すべてのオブジェクトの提供が非常に良好な3つの CDN を示します。    わかっていましたが、やはりグラフが多いですね。内容を要約してみましょう。すべての CDN を集約したグラフをご覧ください。ここに示しているのは、日次データではなく、3週間分すべてのデータに対する TTFB の中央値です。  これらのテスト結果を関係の中で見ると、CDN 1および2は _CHR_edge_ が低い可能性があり、CDN 3および4はそれらよりもよく、CDN 5から7はオブジェクトがネットワークの末端から提供される率が最も高くなります。これらすべてのケースで、CDN で高い _CHR_global_ が報告されます。しかし、_CHR_edge_ は CDN 1および2では _CHR_global_ とかけ離れていますが、CDN 5から7では _CHR_edge_ と _CHR_global_ はほぼ同じになります。 これは、すべてのデータポイントでの TTFB の中央値 (50パーセンタイル) の分析です。テストの50%が、示されている TTFB 以上で実行されました。データセット全体について各 CDN の95パーセンタイルを見ると、少し興味深くなってきます。  CDN 1から4までの状況はほとんど変わりませんが、CDN3は95パーセンタイルでは24時間に1回フェッチされるオブジェクトで悪化しています。CDN5は精彩を欠いています。パーセンタイルが高くなると、パフォーマンスが中央値の場合ほどよくなく、フェッチ間隔が TTFB に悪影響を及ぼしているようです。CDN 6および7は、95パーセンタイルでも引き続き好調な結果を示しています。つまり、フェッチ間隔にかかわらず CDN 6および7には一貫性の高いパフォーマンスを期待できます。 99パーセンタイルでさらに明らかになることがあります。  99パーセンタイルの確認は、データセット全体から最も遅いレスポンス時間を分離するのと本質的に同じです。ここでは、CDN3の6時間、12時間、24時間のテスト間隔の最も遅いレスポンスがすべてよくないことがわかります。また、CDN 4と5の一貫性が低下していることや、CDN6では差が広がり始めていることがわかります。95パーセンタイルと似ていますが、99パーセンタイルでの結果からは、さらにはっきりと多様なユーザーリクエストに対して予期できる一貫性がわかります。このケースでは、CDN7が一貫性が最も高く、データセット全体での差異が最も少ないことがわかります。 これらすべての結果から、また、これらの結果によってフェッチ間隔がパフォーマンスに及ぼす影響が示され、_CHRedge_ の理解と測定がなぜ重要であるかということがよくわかります。作業セットによっても異なりますが、CDN のパフォーマンスはアセットがユーザーからリクエストされる頻度に大きく依存します。 多くの場合、パフォーマンスに関する科学には微妙な差異が含まれます。このケースでは、問題文を実用的に組み立てることで、やや型破りなテストができあがりました。これを使用して、ユーザーがアプリケーションを使用する際のエクスペリエンスに関して正しく予期できることを望んでいます。 下記はこれらをすべて記載したものです。 ----------------------- キャッシュヒット率の分析について、この記事と[直前の記事](https://www.fastly.com/blog/truth-about-cache-hit-ratios)でかなり詳しく扱いました。CDN が皆さんのお客様にサービスを提供する方法をよく理解するために、2つの異なる CHR 測定基準が必要なのはなぜかについて説明しました。パフォーマンスの需要な指標である _CHRedge_ を掘り下げて、一般的なテスト方法が、ユーザーがすべてのコンテンツとすべてのアプリケーションで予期できるパフォーマンスの適切なプロキシにならない理由を説明しました。さらに、もっと興味深い内容としてテストの結果を示しました。これは、ホットとコールド両方のキャッシュ可能コンテンツに関して CDN をテストして、CDN にどの程度の _CHRedge_ を想定できるかを明らかにするものです。 数字やきれいなグラフを見てパフォーマンス分析ばかりやっていると、簡単に行き詰まります。私はいつもそうです。ただし、私たちは、これらすべてはごく一部であり、全体像があることを忘れないようにする必要があります。もちろん、CDN の高いパフォーマンスが、すべてのコンテンツとアプリケーションに関して求められています。しかし、CDN が[アプリケーションスタックの一部](https://www.fastly.com/blog/extending-your-application-edge-fastly)でもあるという事実を見失うことはできません。これにはプログラムを使用してリアルアイムで対処する必要があります。リアルタイムで完全な可視性を持つ必要があります。CDN は、ネットワークのエッジで複雑なロジックを実行する際にアプリケーションを保護する必要があります。これらはすべて CDN の特徴であり、それによって、実際にコンテンツを配信するだけではなく、ユーザーに近いネットワークのエッジにアプリケーションを拡張することができます。これはホールパッケージです。パフォーマンスはその微妙な差異も含め、パッケージのごく一部にすぎません。もちろん重要なものなのですが。 (Fastly は CDN7でした。)