CDN:CDN キャッシュ有効期限の設定

キャッシュ有効期限ルールを設定することで、POP (Points of Presence) 上にリソースがキャッシュされる期間を正確に制御し、コンテンツの更新、アクセスパフォーマンス、オリジンフェッチのコストのバランスを取ることができます。本ドキュメントでは、キャッシュルールの仕組み、設定と確認方法、トラブルシューティング、およびベストプラクティスについて説明します。

仕組み

リクエストが POP に到達すると、システムは以下の決定フローに従って、キャッシュコピーを提供するか、オリジンサーバーから最新のコンテンツをフェッチするかを判断します。

1. リソースをキャッシュしない：オリジンサーバーが pragma:no-cache、cache-control:no-cache (または no-store、max-age=0) を返した場合、POP はオリジンのポリシーに従い、リソースをキャッシュしません。

2. コンソールのキャッシュルールに従う：コンソールで特定のディレクトリやファイル拡張子に対してルールを設定しており、かつオリジンサーバーが上記の「キャッシュしない」ヘッダーを送信しない場合、コンソールのキャッシュルールが優先されます。

   • 複数のコンソールキャッシュルールが一致する場合の優先度ロジック：

     シナリオ	ロジック	例
     異なる重み	重みの値 (1～99) が大きいルールが優先されます。	ルール A (/image/ ディレクトリ、重み 50) とルール B (.jpg 拡張子、重み 90) の両方が image/a.jpg に一致する場合、ルール B が適用されます。
     重みが同じ場合	先に作成されたルールが優先されます。	ディレクトリールール (/static/) とファイル拡張子ルール (.js) を同じ重み 60 で設定し、ディレクトリールールが拡張子ルールより先に作成された場合、/static/app.js はディレクトリールールに一致します。

   • リクエストがキャッシュルールに一致すると、他のルールはチェックされません。

   • デフォルトでは、オリジンサーバーが Pragma: no-cache または Cache-Control: no-cache/no-store/max-age=0 を返した場合、POP はリソースをキャッシュしません。キャッシュを強制するには、コンソールでキャッシュルールを設定する際に [オリジンの No-Cache ヘッダーを無視] を選択します。

3. CDN がオリジンサーバーのキャッシュポリシーに従う：リクエストがコンソールのどのルールにも一致しない場合、または一致したルールで [オリジン TTL に従う] が有効になっている場合、CDN はオリジンサーバーからの HTTP レスポンスヘッダーに従います。これらのヘッダーの優先度は、高い順に cache-control > expires > last-modified > ETag となります。

   レスポンスヘッダー	処理方法	例
   Cache-Control	キャッシュ期間は s-maxage ディレクティブが優先され、次に max-age が続きます。	s-maxage=86400, max-age=3600
   Expires	有効期限の日時を指定します。これは Cache-Control ヘッダーが存在しない場合にのみ使用されます。	Expires: Wed, 21 Oct 2025 07:28:00 GMT
   Last-Modified	Last-Modified は、リソースが最後に変更された日時を示すタイムスタンプです。 キャッシュ期間は次のように計算されます： (現在時刻 - Last-Modified) * 0.1。結果の期間は 10 秒から 3,600 秒の範囲に制限されます。	Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT
   ETag	ETag は、特定バージョンのリソースに対してサーバーが生成する一意の識別子で、通常はハッシュ値やバージョン番号です。 デフォルトでは、ETag を持つリソースは 10 秒間キャッシュされます。	ETag: "abc123"

4. キャッシュしないポリシー：リクエストがコンソールのどのキャッシュルールにも一致せず、オリジンサーバーが Cache-Control などのキャッシュ関連のレスポンスヘッダーを返さない場合、POP はリソースをキャッシュしません。

操作手順

ルール変更の即時適用

新規または変更されたルールは、新しくキャッシュされるリソースにのみ適用されます。変更前にキャッシュされたリソースは、有効期限が切れるまで古いキャッシュポリシーを使用し続けます。

ネットワーク全体に新しいルールを即時適用するには、既存のキャッシュを手動でクリアする必要があります。ルールを変更した場合は、リソースのパージ機能を使用してキャッシュされたコンテンツを更新します。新しいルールを追加した場合は、リソースのプリフェッチ機能を使用してキャッシュを事前に読み込みます。

設定の確認

設定後、curl コマンドまたはブラウザの開発者ツールを使用してリソースの HTTP レスポンスヘッダーを検査し、キャッシュが期待どおりに機能していることを確認できます。

1. 確認コマンドの実行

ターミナルで次のコマンドを実行して、設定をテストします。

curl -I "https://your.domain.com/path/to/file.jpg"

2. 主要なレスポンスヘッダーの解釈

ベストプラクティス

• バージョン管理されたファイル名を使用する (推奨)：style.css のような静的リソースを更新する際は、style-v2.css や style-a1b2c3d.css のようにバージョンやハッシュ値を含む新しいファイル名を使用し、HTML 内の参照を更新します。この方法では手動でのキャッシュ更新が不要で、ユーザーは即座に最新のコンテンツを取得できます。これは、キャッシュ更新を管理するための推奨される方法です。

• 動的アセットと静的アセットを分離する：動的リソースと静的リソースには、異なるドメインまたはディレクトリパスを使用します。ポリシーの競合を避けるために、各リソースタイプに対して個別の、重みの高いキャッシュルールを設定します。例えば、/static/ ディレクトリ配下のすべてのリソースに長いキャッシュ期間を設定し、/api/ ディレクトリ配下のリソースにはキャッシュしない設定をします。

• ブラウザキャッシュを利用する：[POP キャッシュポリシーに従う] を有効にして、POP への繰り返しリクエストを減らし、読み込み速度を向上させ、トラフィックを節約します。

• キャッシュ期間を短すぎないように設定する：キャッシュ期間が短すぎると、頻繁にオリジンリクエストが発生し、アクセラレーションの利点が失われ、オリジンサーバーのトラフィックとコストが増加します。

• キャッシュ期間を長すぎないように設定する：キャッシュ期間が長すぎると、クライアントがタイムリーなデータ更新を受け取れなくなる可能性があります。頻繁な更新が必要なコンテンツには、キャッシュ更新機能またはバージョン管理されたファイル名を使用します。

HTTP キャッシュ制御の仕組み

HTTP プロトコルは、キャッシュ制御を実装するために 3 種類のヘッダーを定義しています。

1. 有効期限の検証

   サーバーがリソースを送信する際、レスポンスに有効期限を含めることができます。この時刻より前は、リソース (キャッシュコピー) は新鮮と見なされます。この時刻を過ぎると、期限切れと見なされます。

   HTTP では、キャッシュの有効期限を制御するために、一般的に以下のヘッダーが使用されます：

   ヘッダー名	プロトコルバージョン	機能	値の例	タイプ
   Pragma	HTTP/1.0	Pragma は、コンテンツをキャッシュすべきかどうかを示すために使用されます。値は通常 no-cache です。HTTP/1.0 のみをサポートするサーバーとの互換性のためにしばしば使用されます。	Pragma:no-cache	リクエスト/レスポンス
   Expires	HTTP/1.0	Expires レスポンスヘッダーには、キャッシュされたコンテンツが期限切れと見なされる日時が含まれます。 `0` のような無効な日付は、リソースがすでに期限切れであることを示します。	Expires: Wed, 21 Oct 2022 07:28:00 GMT	レスポンス
   Cache-Control	HTTP/1.1	Cache-Control レスポンスヘッダーは、柔軟なキャッシュ制御のためにさまざまなディレクティブで設定できます。これは、現代のクライアント (ブラウザなど) がキャッシュを制御するために使用する主要なヘッダーです。	次の 3 つの例は、ファイルをキャッシュすべきでないことを意味します： - Cache-Control:no-cache - Cache-Control:no-store - Cache-Control:max-age=0 1 時間のキャッシュ有効性を示す例：Cache-Control:max-age=3600	リクエスト/レスポンス

2. リソースタグの検証

   クライアントがリソースをリクエストすると、サーバーはレスポンスにリソースタグ (例：`ETag`) を含めることができます。クライアントはこのタグを保存します。同じリソースに対する後続のリクエストでは、クライアントはタグをサーバーに送り返します。タグがサーバーの現在のバージョンと一致する場合、サーバーは `304 Not Modified` ステータスで応答し、クライアントにキャッシュコピーを使用するよう指示します。タグが一致しない場合、サーバーは完全な更新済みリソースを送信します。

   HTTP では、キャッシュのバージョンを制御するために、一般的に以下のヘッダーが使用されます：

   ヘッダー名	プロトコルバージョン	機能	値の例	タイプ
   Last-Modified	HTTP/1.0	Last-Modified は、リソースの最終変更日時を示します。	Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT	レスポンス
   ETag	HTTP/1.1	ETag は、特定バージョンのリソースに一意の識別子を提供します。 ETag の値を比較することで、リソースが変更されたかどうかを判断できます。変更されていない場合、オリジンサーバーは完全なレスポンスを送信する必要はありません。	ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"	レスポンス

3. コンテンツネゴシエーション

   キャッシュソフトウェアは、キーを使用してキャッシュされたオブジェクトをインデックス化します。HTTP/1.0 では、このキーは通常リソースの URL でした。しかし、同じ URL に異なるリソースが存在することがあります。それらを区別するには、Accept-Language や Accept-Charset ヘッダーなど、クライアントからの追加情報が必要です。このコンテンツネゴシエーションをサポートするために、HTTP/1.1 はレスポンスに Vary ヘッダーを導入しました。これは、コンテンツネゴシエーションに使用されるリクエストヘッダーをリストします。

   `Vary` HTTP ヘッダーがこのためのメカニズムです。これは、キャッシュされたレスポンスが使用できるかどうかを判断する際に、どのリクエストヘッダーをチェックすべきかをキャッシュに伝えます。

   ヘッダー名	プロトコルバージョン	説明	値の例	タイプ
   Vary	HTTP/1.1	一般的な例： - サーバーが指定： <br> Vary: Accept-Encoding<br> これは受信側 (例：POP) に、リソースの 2 つのバージョン (圧縮版と非圧縮版) をキャッシュするように指示します。クライアントがリソースをリクエストすると、古いブラウザは互換性のために非圧縮版を取得し、現代のブラウザはデータ転送とトラフィックを削減するために圧縮版を取得できます。 - サーバーが指定： <br> Vary: User-Agent<br> これはブラウザのタイプを識別するために使用され、受信側 (例：POP) にブラウザのタイプに基づいてリソースの異なるバージョンをキャッシュするように指示します。	Vary: Accept-Encoding Vary: Accept-Encoding,User-Agent	レスポンス

よくある質問

• キャッシュに関するよくある質問

• キャッシュクリアの仕組みとは？

• CDN のキャッシュヒット率を向上させる

• ファイルをキャッシュせずにオリジンサーバーから直接取得するように設定するにはどうすればよいですか？

• 同じ URL でリソースの複数の表現 (例：圧縮版と非圧縮版) を CDN がキャッシュするように設定するにはどうすればよいですか？