問い合わFastly 無料トライアル

キャッシュヒット率の真実

キャッシュ CDN よって提供される主要なサービス1つでありCDN パフォーマンスを評価する一般的な指標の1キャッシュヒット (CHR) です長年にわたり CDN のお客様CDN がどの程度ユーザーに優れたサービスを提供し、トラフィックを処理しているかを判断する主要な指標して CHR 使用してきました。ダッシュボードに「キャッシュヒット98 %表示されることも珍しくなく、その場合、エンドユーザーが CDN メリットを最大限に得ていると簡単に納得しがちです

しかし CHR 目に見える以上にはるかに多くの意味を含んでおり、私たちが普段、重視しているこの指標は私たちが考えていることとは別のことを意味している可能性があります。そこで今回は、CHR 実際に測定している中身について解説し、それを計算して評価する新し方法の必要性について考察したいと思います。

従来の CHR 計算方法

長年にわたり、CDN 以下の式を使用して CHR 計算してきました。

requeststotal は CDN によって受信されたクライアントリクエストの合計数で、requestsorigin はそのうちオリジンに到達したリクエストのです簡単に言えば、CDN に100件のリクエストを送信し、そのうちの1件が CDN 離れてオリジンに到達した場合、CHR は99 %になります。

「キャッシュヒット99 %聞くと、ユーザーのリクエストの99 % が CDN エッジ (リクエストを実行したクライアントに最も近いキャッシュ) からコンテンツを提供されていると本能的に考えがちですが、実際には必ずしもそうであるとは限りません。その理由を理解していただくために、CDN アーキテクチャキャッシュ階層、ロングテールコンテンツについて説明します。

CDN のしくみ

あまり細か話をするつもりはなく、もちろんすべての CDN について語ることはできませんが、最も基本的な意味で CDN プロキシをキャッシュする分散ネットワークのことです。それらのプロキシが共有されることキャッシュが共有されます。プロキシは CDN のお客様に属する、すべての多数のドメインにわたってリクエストを受信し、キャッシュします。これは、サーバーがストレージも共有していることを意味します。ストレージは有限であるため、通常はストレージを管理するための削除モデルを含む、何らかのアルゴリズムが使用されています。頻繁にリクエストされるオブジェクトは、(有効期限過ぎない限り) より長期間キャッシュ内に留まる傾向があり、あまり頻繁にリクエストされなオブジェクトは、たとえ Cache-Control ヘッダーによって長期間キャッシュされている必要があると指定されていてもキャッシュから削除される傾向にあります。

ただし、ストレージ管理機能によってまだ有効期限を過ぎていないオブジェクトが1つのキャッシュサーバーから削除されたからといって、必ずしも CDN 全体とすべてのキャッシュサーバーから削除されるとは限りません。CDN には通常、何らかの階層モデルがデプロイされており、クライアントが通信しているサーバーのキャッシュの中にオブジェクトがない場合、そのオブジェクトをオリジンからフェッチしようとする前に、そのピアまたは親にオブジェクトを要求する傾向があります。問題は、そのピアや親が、クライアントが接続されているサーバーの横に常にあるとは限らないことです。そのため、オブジェクトをフェッチしてクライアントに配信するまでにかかる時間が長くなる可能性があります。以下の図を覧いただくとわかりやすいと思います。

CHR-diagram

エッジキャッシュがクライアントからリクエストを受け取ると、クライアントとその特定のマシンの間に TCP 接続が確立されていても、レスポンスは至るところにあるストレージから送信される可能性があり、ストレージはそのサーバー上にあるとは限りません。オブジェクトはそのマシンのメモリ (最良のシナリオ)、そのマシンのディスクストレージ (SSD 望ましいです。そうでない場合、余分な負荷がかかります)ローカルのピア/ローカルでないピア/親から提供される可能性があります。そしてオブジェクトの提供元がネットワークエッジから遠ざかれば遠ざかるほど、チェーン全体を通じてパフォーマンスが低下します。

究極的には通常、オブジェクトの提供元はそのオブジェクトがフェッチされる頻度と直接関係します。リクエストの頻度が低いほど、クライアントが接続されているエッジキャッシュでミスとな可能性が高くなります。言い換えれば、ロングテールコンテンツ (ソーシャルメディアの投稿、プロフィール画像、e コマースサイトの大きなインベントリなど、あまり頻繁にフェッチされなコンテンツ) も CDN から提供される可能性はありますが、必ずしもクライアントの近くのキャッシュからとは限りません。

しかし、ほとんどの CDN は CHR 計算する際、オリジンに到達していない限り、いずれかのキャッシュから受け取ったレスポンスをすべて「ヒット」と見なします。これが CHR 指標として誤解を招き、CDN 顧客に提供しているパフォーマンスに関して誤った認識をもたらす原因です。また、これは CDN オブジェクトストレージモデルが重要な理由でもあります。エッジに十分な密度がない、エッジで適切なスケーリングが行われない、最適化された削除アルゴリズムがない環境でデプロイされている場合、CHR 高く見えますが、ロングテールコンテンツの多くが CDN 奥まったところから提供される可能性があります。

CHR のより望ましい計算方法

従来の CHR 計算方法では分からない部分があるため、私たちにとって重要なこの指標の計算方法を再考する必要があります。パフォーマンスのインジケーターとなる指標として、私たちが本当に知りたいのは、ネットワークのエッジにある CDN キャッシュから提供されるオブジェクトの割合です。以下ような計算式になります。

これは実際には以下の計算式と同じです。

hitsedgemissesedge 、それぞれネットワークエッジでのキャッシュヒット数とキャッシュミス数を表します。この CHR 計算式では、ユーザーから最も近い、ネットワークのエッジから提供されたキャッシュ可能なリクエストの割合が正確に分かります。

実際には従来の計算方法はいまだに非常に有用です。オリジンに到達しないリクエストの割合がわかるため、サーバーのオフロードを測定するのに非常に便利な指標です。しかし、パフォーマンスを評価するには、エッジで何が起きているのかに注目する必要があります。最善の方法は、以下のように2つの異な CHR 指標を考慮することです。ひとつはエッジにおける CHR です。

もう1つは全体的な CHRです。

CHRedge パフォーマンスを測定する指標で、CHRglobal オフロードを測定する指標です。両方とも貴重な指標で重要なインサイトをもたらしますが、それぞれ意味する内容は異なります。CHRedge ユーザーに近い、ネットワークのエッジから配信されているコンテンツの割合を測定します。これは直接、パフォーマンス上のメリットに換算されます。一方 CHRglobal オリジンに到達しないトラフィックの割合を示します。これは直接、プロセスとインフラストラクチャのオフロードに換算され、コストの大幅な節約につながる可能性があります。

Fastly キャッシュヒット率を計算する

Fastly ネットワークでは、すべての配信拠点 (POP) エッジに配置して構築されており、Fastly のネットワークマップですべてのエッジのロケーションを確認できます。拡張性とストレージの密度を高めるため、 POP 内に客様やエンドユーザーのリクエストに対して透過的な、キャッシュ階層のレイヤーを設けています。これにより、あるリクエストがクライアントが接続されているサーバーではキャッシュミスであっても、それが通信している POP 内部のキャッシュからコンテンツが提供される可能性が高く、その場合エッジではキャッシュヒットになります。また、キャッシングの追加レイヤーとしてオリジンシールドデプロイすることで、全体のキャッシュヒット率を高め、オリジンへのトラフィックを削減できます。

コントロールパネルを介して、または Stats API 通じて報告される CHR 以下のように計算されます。

オリジンシールドを使用しないサービスでは、これは CHRedgeCHRglobao両方に事実上相当します。すべてのヒットはエッジにおけるヒットであり、すべてのミスはエッジにおけるミス (オリジンへのリクエスト) であるためです

サービスでオリジンシールドが使用されている場合、つまりシールド POP によって別のレベルのキャッシュが追加される場合、上記の数式は成立しますが、ヒット/ミス数にはシールドのヒットやミスも含まれます。つまり、一部のリクエストが2カウントされるハイブリッドな測定基準です。シールドを使用するサービスの CHRedgeCHRglobal 分離し、それぞれ独立して計算する方法はいくつかありますが、私は通常 Fastly のリアルタイムログストリーミング使用しています。

以下の VCL スニペットで、複数のローカル変数使用した CHR 計算用のログストリーミングをセットアップします。

sub vcl_log {
#FASTLY log
  declare local var.cache_statusSTRING;
  declare local var.request_typeSTRING;

  set var.cache_status = if(fastly_info.state ~ "HIT($|-)", "HIT", if(fastly_info.state ~ "PASS($|-)", "PASS", "MISS"));
  set var.request_type = if(req.http.fastly-ff,"reqUrl": "/",

  log {"syslog req.service_id logging_endpoint :: "} var.cache_status "," var.request_type "," server.datacenter;
}

ここでは、ローカル変数 cache_statusHITMISSPASS のいずれかになります。PASS キャッシュ可能なオブジェクトではないため計算から除外します。ローカル変数 request_type コンテンツがシールド POP またはエッジ POP (または Fastly 別の POP ではなく、クライアントと直接通信するシールド POP機能的にはそのリクエストのエッジ POPとなる) のいずれかから提供されたリクエストであることを示します。次に cache_statusrequest_type、3文字の POP コードを示す server_datacenter 記録します。

この VCL では、ログエントリは以下のように表示されます。


Jan  7 23:15:26 cache-sjc3131 logging_endpoint[218999]: HIT,edge,SJC
Jan  7 23:15:33 cache-sjc3638 logging_endpoint[348011]: HIT,edge,SJC
Jan  7 23:15:40 cache-iad2120 logging_endpoint[342933]: MISS,shield,IAD
Jan  7 23:15:40 cache-sjc3644 logging_endpoint[341583]: MISS,edge,SJC
Jan  7 23:16:07 cache-iad2127 logging_endpoint[342933]: HIT,edge,IAD
Jan  7 23:16:24 cache-iad2127 logging_endpoint[14817]: MISS,edge,IAD
Jan  7 23:16:40 cache-iad2120 logging_endpoint[218999]: HIT,shield,IAD
Jan  7 23:16:40 cache-sjc3624 logging_endpoint[438579]: MISS,edge,SJC
Jan  7 23:23:25 cache-iad2122 logging_endpoint[342933]: PASS,shield,IAD
Jan  7 23:23:25 cache-sjc3140 logging_endpoint[348011]: PASS,edge,SJC

これで、これらのログ行から CHRedgeCHRglobal 簡単に計算できます。

以下の意味になります。

  • hitedgecache_status = “HIT” かつ request_type = “edge” ログエントリです。

  • missedgecache_status = “MISS” かつ request_type = “edge” ログエントリです。

同様に

以下の意味になります。

  • missshieldPOP は、cache_status = ”MISS” かつ server.datacenter = <your_shield_pop> ログエントリ

  • hitedgecache_status = “HIT” かつ request_type = “edge” ログエントリです。

  • missedgecache_status = “MISS” かつ request_type = “edge” ログエントリです。

バージニアダレス (IAD) の POP オリジンシールドとして使用する上記のサンプルログエントリを例に以下を計算します。

そして

これは、な2つの指標がそれぞれ異な内容を意味し、別々に評価される必要があるのかを示すシンプルか良い例です。

ログストリーミングを使用することで、シールドを使用するサービスの2つの指標を簡単に分離できますが、今後、Fastly 統計情報システムを通じてこれらの指標を個別に報告し、より簡単に利用できるようにすることに取り組んでいます。

最後に

Fastly では、エッジですべきこと、なぜそれがエンドユーザーにとってメリットがあるのかについてよく話し合います。キャッシュは今後もコア機能の1つでありCDN がどれほど効率的にエッジでコンテンツをキャッシュしているか、常に注意する必要があります。それには CDN キャッシュヒット率を報告する方法と、それがコンテンツやエンドユーザーのエクスペリエンスにとってどのような意味があるのかを理解することが重要です。エッジとグローバルの両方でキャッシュヒット率を計算することで、コンテンツがどのように提供されているのかを本当の意味で理解することができます。

Hooman Beheshti
VP of Technology
投稿日
興味がおありですか?
エキスパートへのお問い合わせ
この投稿を共有する
Hooman Beheshti
VP of Technology

Hooman Beheshti Fastly VP of Technology 務め、Web パフォーマンスサービスを開発しています。アプリケーションアクセラレーション開発のパイオニアである Hooman Radware 在籍中に初期のロードバランサの設計に携わったほか、Strangeloop Networks Crescendo Networks シニアレベルの技術職を歴任しました。20年近くにわたりインターネットを高速化するコアテクノロジーの開発に従事し、ロードバランシング、アプリケーションパフォーマンス、コンテンツ配信ネットワークの専門家として頻繁に講演を行っています。