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

仕組み

リクエストが CDN の POP に到達すると、システムはキャッシュされたコピーを配信するか、オリジンサーバーから最新のコンテンツを取得するかを決定します。以下の手順は優先順に評価され、番号が小さいほど優先度が高くなります。

1. オリジンの no-cache ディレクティブ — オリジンサーバーが Pragma: no-cache、Cache-Control: no-cache、Cache-Control: no-store、または Cache-Control: max-age=0 で応答した場合、CDN はリソースをキャッシュしません。 これらのリソースを強制的にキャッシュするには、キャッシュ有効期限ルールを設定する際に レスポンスヘッダーを無視 を選択します。

2. [コンソール] で設定されたキャッシュルール — CDN [コンソール] で設定されたキャッシュルールは、ステップ 1 で説明されているようにオリジンサーバーが no-cache ディレクティブを明示的に送信する場合を除き、優先されます。複数の [コンソール] のキャッシュルールがリクエストに一致する場合、重みが大きい方のルールが優先され、重みが同じルールは作成順に解決されます。リクエストがいずれかのキャッシュルールに一致すると、他のルールは評価されません。

3. オリジンレスポンスヘッダー — リクエストが CDN コンソールルールに一致しない場合、または一致したルールで オリジンの TTL を優先 が有効になっている場合、CDN はオリジンサーバーの HTTP レスポンスヘッダーに従います。 ヘッダーの優先度は、高い順に次のとおりです：Cache-Control > Expires > Last-Modified > ETag。

4. デフォルトの no-cache ポリシー — リクエストが CDN コンソールのどのキャッシュルールにも一致せず、オリジンサーバーが Cache-Control などのキャッシュレスポンスヘッダーを返さない場合、CDN は no-cache ポリシーを適用します。

5. CDN は、オリジンサーバーがステータスコード 200、203、206、300、301、308、または 410 を返すリクエストにのみキャッシュポリシーを適用します。404 などのステータスコードの有効期限を設定するには、キャッシュ設定 > HTTP ステータスコード有効期限 ページを使用します。

次の表は、複数のコンソールのキャッシュルールがリクエストに一致する場合の優先順位ロジックを示しています。

次の表は、各オリジンサーバーのレスポンスヘッダーがどのように処理されるかを示しています。

キャッシュルールのマッチングロジック

CDNキャッシュの有効期限ルールは、異なるマッチング動作を持つ 2 つのルールタイプに対応しています。

• [ディレクトリ]：パスのプレフィックス (前方一致) でマッチングします。たとえば、/static/ を設定すると、そのディレクトリ配下のすべてのリソース (たとえば、/static/image/1.jpg や /static/css/style.css) に一致します。/ を設定すると、すべてのパスに一致します。ディレクトリパスはスラッシュ (/) で始まる必要があります。各ルールは 1 つのディレクトリのみをサポートします。

• [ファイル拡張子]：拡張子の完全一致でマッチングします。拡張子はドットなしで入力し、複数の拡張子はカンマで区切ります (例：jpg,css,js)。拡張子は英数字のみに対応し、特定の拡張子タイプに制限はありません。以下の拡張子タイプはすべて設定可能です：

  • 一般的な静的リソースの拡張子：jpg、png、gif、css、js、html

  • フォントファイルの拡張子：ttf、otf、woff、woff2、eot

  • 動的ページの拡張子：php、aspx、jsp

  • その他の英数字の拡張子

キャッシュルールのマッチングに関する以下の点に注意してください。

• 複数のキャッシュルールが同じリクエストに一致する場合 (たとえば、ディレクトリールールとファイル拡張子ルール)、より高い [重み] を持つルールが優先されます。重みが等しいルールは作成順 (先に作成されたルールが優先) に解決されます。詳細については、「仕組み」をご参照ください。

• ルール条件 (ルールエンジンで設定) をキャッシュルールに関連付ける場合、複数の条件は AND ロジックで評価され、リクエストが一致するにはすべての条件を満たす必要があります。

• すべての動的拡張子 (たとえば、aspx) に包括的な no-cache ルールを設定する場合、キャッシュするつもりの静的リソースに影響しないように注意してください。フォントファイルをキャッシュするには、ttf,otf,woff,woff2,eot などの拡張子を持つ専用のルールを追加してください。

操作手順

ルール変更の即時適用

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

検証

設定が完了したら、curl コマンドまたはブラウザー開発者ツールを使用してリソースの HTTP レスポンスヘッダーを検査し、キャッシュが期待どおりに機能することを確認します。ルール変更がいつ有効になるかの詳細については、「ルール変更の即時適用」をご参照ください。

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

ベストプラクティス

• バージョン付きファイル名を使用する (推奨) — style.css などの静的リソースを更新する場合は、style-v2.css や style-a1b2c3d.css のように、バージョンまたはハッシュを含む新しいファイル名を使用し、HTML の参照を更新します。この方法により、ユーザーは手動で CDN キャッシュをパージすることなく、すぐに最新のコンテンツを受信できます。これは、キャッシュされたコンテンツを更新するための推奨される方法です。

• ブラウザキャッシュを効果的に使用する — CDN のキャッシュルール優先 を有効にすると、CDN への繰り返しリクエストが削減され、読み込み速度が向上し、CDN のトラフィックを節約できます。

• キャッシュ期間を過度に短く設定しない — キャッシュ期間が短いと、CDN が頻繁にオリジンフェッチを実行するため、アクセラレーションのメリットが損なわれ、オリジンサーバーのトラフィックとコストが増加します。

• 長いキャッシュ期間に関する注意 — 長いキャッシュ期間は、クライアントがタイムリーにコンテンツの更新を受け取るのを妨げる可能性があります。頻繁な更新が必要なコンテンツについては、必ずキャッシュをパージするか、バージョン管理されたファイル名を使用してください。

• ゲーム業界と小容量ファイルのシナリオ — ゲーム業界の小容量ファイルリソース (設定ファイルやアセットパッケージなど) で、更新頻度が低い (たとえば、週次または隔週) ものについては、キャッシュの有効期限を 15 日に設定するか、実際のリソース更新サイクルに合わせます。これにより、更新速度と高速化パフォーマンスのバランスが取れます。キャッシュ期間が短すぎると、頻繁なオリジンフェッチが発生して高速化の利点が減少し、長すぎると古いコンテンツがプレイヤーに提供される可能性があります。(推奨) コンテンツが更新された際には、パージとプリフェッチ機能を使用して、事前にキャッシュを更新してください。

• robots.txt と sitemap.xml — これらのファイルは検索エンジンのクロールに直接影響します。これらが広範な拡張子ルールに一致して長期間キャッシュされ、更新が遅れるのを防ぐために、キャッシュ期間を別途設定してください。(推奨) これら 2 つのファイルのみを対象とするには、タイプとして [ディレクトリ] を選択し、[オブジェクト] フィールドに特定のファイルパス (たとえば、/robots.txt) を入力し、広範な拡張子ルールを上書きするために高い重みを設定します。ファイル拡張子で設定する場合は、txt,xml 拡張子に対して 1 時間から 1 日のキャッシュ期間を設定します。拡張子ルールは、robots.txt や sitemap.xml だけでなく、これらの拡張子を持つすべてのリソースに適用されます。頻繁に更新されるサイトマップについては、キャッシュ期間を 1 時間以下に設定してください。

トラブルシューティング

キャッシュが有効にならない、キャッシュミス、キャッシュヒット率が低い、コンテンツが更新されないなどの問題のトラブルシューティング方法については、「キャッシュ問題のトラブルシューティング」をご参照ください。

付録：HTTPキャッシュ制御メカニズム

このセクションでは、プロトコルの背景について説明します。POP での対応するキャッシュ動作については、「仕組み」をご参照ください。HTTP プロトコルは、キャッシュ制御のために 3 種類のヘッダーを使用します。

1. 有効期限の検証

   クライアントがサーバーにリソースを要求すると、両者はリソースの有効期限について合意します。この時刻より前は、キャッシュされたコピーは有効と見なされ、この時刻を過ぎると無効になります。

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

   ヘッダー	プロトコルバージョン	説明	例	タイプ
   Pragma	HTTP/1.0	コンテンツをキャッシュすべきかどうかを示します。その値は通常 no-cache であり、ファイルがキャッシュされるべきではないことを意味します。HTTP/1.0 プロトコルのみをサポートするサーバーとの互換性のために、よく使用されます。	Pragma: no-cache	リクエスト/レスポンス
   Expires	HTTP/1.0	Expires レスポンスヘッダーは、キャッシュされたコンテンツが陳腐化する日時を指定します。0 のような無効な日付が使用された場合、そのリソースはすでに期限切れであることを意味します。	Expires: Wed, 21 Oct 2025 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 など) を含めます。クライアントが同じリソースを再度要求すると、このタグをサーバーに送り返して検証を求めます。リソースが変更されていない場合、サーバーは HTTP ステータスコード 304 で応答し、クライアントはキャッシュされたコピーを使用できます。リソースが変更されている場合、サーバーは新しいコンテンツを送信します。

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

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

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

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

   コンテンツネゴシエーションでは、通常、HTTP Vary ヘッダーを使用して異なるキャッシュコピーを区別し、異なるクライアントが同じリソースを要求したときに異なるキャッシュコピーを受信できるようにします。