CDN とキャッシュの違いとは

CDN とキャッシュの違い

コンテンツ配信ネットワーク (CDN) は、ユーザーの地理的な場所に基づいて Web コンテンツやページを配信する分散されたサーバーで構成されるシステムを指し、パフォーマンスの向上とレイテンシの削減に貢献します。CDN はキャッシュ処理を実行します。キャッシュは CDN の中核機能です。HTML ページや JavaScript ファイル、CSS ファイル、画像、動画など、Webサイトの重要なファイルをエッジサーバーにキャッシュして保存し、読み込み時間を短縮します。

CDNキャッシュとは何ですか？

CDN (コンテンツ配信ネットワーク) の文脈では、CDN でキャッシュすることで、ユーザーにより近い場所からコンテンツを配信してレイテンシを短縮し、大幅に読み込み時間を改善してサイトパフォーマンスを向上できます。CDN キャッシュは、世界中に分散されたエッジサーバーにコンテンツの複製を保存する仕組みを意味します。ユーザーがコンテンツをリクエストするたびに、CDN はオリジンサーバーが応答するのを待つのではなく、最も近い場所にあるエッジサーバーからコンテンツを配信します。これにより、リクエストが複数のサーバーに分散されるため、オリジンサーバーのワークロードが減ると同時に、より多くのトラフィックを処理できるようになります。

CDN は本質的にキャッシュであるため、ブラウザキャッシュを使用しないことで複雑化を避けたいと考えているお客様もいらっしゃるかもしれません。しかし、どちらのキャッシュにも、それぞれ独自のメリットがあります。このブログ記事では、各キャッシュのメリットをご紹介し、これらのキャッシュを組み合わせてWebサイトのパフォーマンスを最適化し、優れたユーザーエクスペリエンスを実現する方法をご説明します。

キャッシュバスティングとは

キャッシュバスティングとは、新しいファイルをアップロードしてキャッシュ済みの既存ファイルと置き換えるプロセスを指します。キャッシュバスティングによって、置き換えられる古いファイルをブラウザがキャッシュから取得するのを回避できます。

CDN キャッシュブラウジングを使用する理由

CDN を使用すると、非常に迅速にアセットを配信できますが、僻地など携帯電話の電波が届きにくい場所にいるユーザーにとってはあまり効果がありません。実のところ、Cedexis のレポートによると、米国ではすべての CDN への往復時間 (RTT) の95パーセンタイルが200ミリ秒を大きく上回っています。つまり、少なくともユーザーの5%が、Webサイトまたはアプリケーションの遅延を経験しているということです。参考までに RTT の50パーセンタイルまたは中央値は、約45ミリ秒です。

ではなぜ、ブラウザキャッシュのみに頼らず、わざわざ CDN を使用する必要があるのでしょうか。

1. より優れたコントロール。ほとんどの CDN で、キャッシュからアセットをパージできます。これはアセットに変更を加える際に非常に便利な機能ですが、ブラウザキャッシュにはこのオプションはありません。

2. 重要な第一印象をアップ。ブラウザキャッシュは、ユーザーが初めてサイトを訪問する際にはコールドキャッシュ (利用できるオブジェクトがない状態) であるため、まったく役に立ちません。CDN でコールドブラウザキャッシュによるユーザーエクスペリエンスを可能な限り高速化し、ウォームブラウザキャッシュで連続するページの配信を加速できます。

3. CDN の地理的なメリット。ユーザーが95パーセンタイルに含まれる場合でも、250ミリ秒の RTT は350ミリ秒の RTT よりまだましです。各アセットをオープン接続で取得するのに1往復はするわけですが、その接続を開始するには追加の往復が必要なことを考えると当然です。しかもトランスポートレイヤーセキュリティ (TLS、以前の名称は SSL) では接続ごとに少なくともさらに1回、ときには2回の往復が追加されます。こうした追加の往復により、あっという間に RTT が加算されます。

4. すべてのユーザー間でキャッシュを共有できる CDN の優れた効率性。CDN を利用することで、オリジンサーバーの負荷を低く抑えることが可能になり、プラットフォームに独自のキャッシュレイヤーを設置する必要がなくなります。

CDN とブラウザキャッシュの両方を使用する方法

CDN の重要性とブラウザキャッシュの価値を理解したところで、次は、この2つを組み合わせる手法を2つご紹介します。

1. ブラウザキャッシュでは有効期限 (TTL) を短く設定し、CDN 側では長い TTL とパージ機能使用する。

2. CDN とブラウザキャッシュの両方で TTL を長く設定し、バージョンベースのキャッシュバスターを使用する。

以下にそれぞれの手法について詳しく説明し、2つの手法を組み合わせて使用する方法についてもご紹介します。

短いTTLと長いTTL

ブラウザキャッシュでは 、TTL がアクセス時間全体のみをカバーし、それ以上はキャッシュが持続されないことが理想的です。そうすれば、ユーザーの訪問中はページが迅速に読み込まれ、同じユーザーが後で同じサイトに再度アクセスしても過去のアセットが表示されることはありません。分析ツールでサイトの滞在時間を確認できますが、通常5 - 10分といったところです。

Fastly 側の TTL は1か月または1年程度にし、デプロイパイプラインの一部としてパージをセットアップして、できる限り早く新しいバージョンを配信できるようにすることをお勧めします。パージについて詳しくは、https://docs.fastly.com/guides/purging/ をご覧ください。

注 : 更新するアセットの新しいバージョンが確実にオリジンから配信されることが確認できるまで、パージコマンドを送信しないでください。Fastly にパージが送信され、オリジンサーバーへの同期が完了する前に Fastly が即座にファイルを取得したことによって、混乱が生じたケースが過去に確認されています。

ブラウザキャッシュの TTL を設定するには、オリジンのレスポンスに Cache-Control ヘッダーを使用します。さらに、Surrogate-Control ヘッダーまたは Fastly 設定でオーバーライドを使用して、TTL を設定します。

以下は Surrogate-Control ヘッダーを使用した例です。

Cache-Control: max-age=600
Surrogate-Control: max-age=31536000

上記の例では、Cache-Control ヘッダーはブラウザに10分キャッシュするよう指示し、Fastly には1年間キャッシュするよう指示しています。Surrogate-Control ヘッダーは、レスポンスがクライアントに送信される前に削除されるため、この実装の詳細はユーザーからは見えません。Fastly で TTL をコントロールする際に使用できるヘッダーについて詳しくは、Fastly のドキュメントをご覧ください。

バージョンベースのキャッシュバスター

その名前に反して、キャッシュバスターは賢く使用するとキャッシュを改善できます。簡単に言うと、キャッシュバスターは URL に追加される新しいクエリ文字列パラメーターです。Web サーバーと多くのアプリケーションサーバーは関係のないクエリ文字列パラメーターを無視しますが、キャッシュはクエリ文字列のあらゆる差異が結果に影響を与えると仮定します。これはブラウザキャッシュの場合も同じです。以下の3つのオブジェクトに対してサーバーがまったく同じレスポンスを返したとしても、ブラウザはそれぞれ一意のオブジェクトとして扱う必要があります。

https://www.example.com/css/main.css, https://www.example.com/css/main.css?cb=foo、https://www.example.com/css/main.css?foo=bar

ビルド番号が133のアプリを運用しているとします。アプリは https://www.example.com/css/main.css にリンクする代わりに、https://www.example.com/css/main.css?v=133 にリンクします。ビルド134を構築する場合は、代わりに https://www.example.com/css/main.css?v=134 にリンクします。ブラウザは、有効期限内のコピーがキャッシュにあっても、この main. css の新しいバージョンを取得する必要があります。

一般的には、ファイルコンテンツの (短い) ハッシュ、ビルド番号、またはコミットハッシュのいずれかを使用します。

個人的にはファイルコンテンツのハッシュを使用することをお勧めします。この方法では、コンテンツが変化した場合にのみキャッシュバスターが変化します。一方、ビルド番号またはコミットハッシュを使用すると、何らかの変更があるたびに必ずキャッシュバスターも変化します。ただし、サイトのアセットのすべての URL にキャッシュバスターが必要なため、ビルド番号またはコミットハッシュを使用する方が便利な場合もあります。

このアプローチのデメリットは、変更のたびにすべてのアセット URL を更新する必要があるということです。メリットは、長い TTL を使用してブラウザでアセットをキャッシュでき、キャッシュの有効期限が過ぎるとブラウザが新しいアセットを取得できるという点です。

組み合わせてお楽しみください

Fastly の CDN を使用すると、150ミリ秒以内に古いコンテンツをパージできるため、すべての HTML ページをキャッシュすることも検討すべきでしょう。ただし、画像やスタイルシート、JavaScript などのアセットにキャッシュバスターを使用するようサイトを再エンジニアリングしたとしても、実際のページの URL にキャッシュバスターを使用するべきではありません。 Google などの検索エンジンでは、ページの URL にクエリ文字列があるとペナルティが課されるためです。

ページをキャッシュする場合は、ページに短い TTL と長い TTL を設定するテクニックを使い、ページで使用されるアセットにキャッシュバスターを使用することを検討してください。

高度な技 : 再検証

ブラウザキャッシュを使用することの二次的なメリットは、オブジェクトの有効期限を過ぎてもブラウザがオブジェクトを保持し、リクエストと一緒に再検証を行う追加のヘッダーを送信することです。リクエストされているオブジェクトが変更されていない場合、CDN は本文なしの 304 Not Modified ステータスを返し、有効期限を過ぎたオブジェクトを使用できることをブラウザに伝え、任意で新しい TTL を提供できます。

304レスポンスを受け取るリクエストの場合でも、処理が完了するまでに必ず往復する必要があることは変わりませんが、レスポンスの本文がないためデータ転送量を大幅に削減できます。これは、低速回線を使用しているユーザーにとってメリットがあるだけでなく、月々の CDN 料金を削減できる可能性もあります。

再検証を有効にするために必要なのは、オリジンからのレスポンスに Last-Modified ヘッダーまたは ETag ヘッダーが含まれるようにすることだけです。幸い、ほとんどの Web サーバーではすでに、ディスクから配信する静的ファイルすべてに Last-Modified ヘッダーおよび ETag ヘッダーが含まれています。Last-Modified ヘッダーの値は、ファイルの変更日時に基づきます。ETag ヘッダーの値は、(Apache の) 変更日時、inode 番号、サイズに基づきます。

ブラウザのキャッシュにある有効期限が切れたオブジェクトに、これら2つのヘッダーのいずれか、あるいは両方が存在することをブラウザが認識すると、Last-Modified の値を持つ If-Modified-Since ヘッダーと、ETag の値を持つ If-None-Match ヘッダーが追加されます。If-None-Match とETag の値が同じ場合、および If-Modified-Since の値が Last-Modified の値と一致するか、それより後である場合、オブジェクトに変更がないとみなされます。

静的アセット向けに単一の Web サーバーを使用している場合、共通のデフォルト設定によって、すでに再検証が完全に機能していると考えられます。

しかし、冗長性を確保するために複数の Web サーバーを使用しており、各サーバーが共有ストレージではなくそれぞれローカルストレージを使用している場合、ランダムに再検証の失敗が発生する場合があります。なぜなら、特定のファイルが各 Web サーバーで同じ inode 番号を割り当てられるとは限らず、生成される ETag ヘッダーはサーバーによって異なるからです。また、ほとんどのデプロイスクリプトはファイルをコピーする際に変更日時を保持しないので、Last-Modified ヘッダーの値も異なります。

これは2つの理由で好ましくありません。まず、Fastly がオリジンと通信する場合、304レスポンスの代わりにフルレスポンスを送信して無駄に帯域が使用される可能性があります。次に、Fastly は異なるサーバーで異なる ETag と Last-Modified の値を保持することになる可能性があります。ブラウザがリクエストのたびに同じサーバーと通信するという保証はないため、値の不一致が原因で不要なフルレスポンスが返される可能性があります。

ローカルストレージを使用する Web サーバーが複数ある場合、再検証を最大限に活用するには ETag をオフにして Last-Modified のみを使用し、ファイルをコピーする際にデプロイスクリプトで変更日時を記録することをお勧めします。

Google Cloud Storage や Amazon S3 などのクラウドストレージプロバイダーを使用している場合、ETag ヘッダーはすでにコンテンツのハッシュに自動的に設定されているはずです。従って、同一のファイルを再アップロードしても ETag は変化しないため、クラウドストレージは Fastly にとって最適なオリジンのひとつです。