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

• CDN/DCDN のキャッシュのパージメカニズムとは

• デフォルトの CDN/DCDN キャッシュルールとは

• リソースが CDN/DCDN POP にキャッシュされているかどうかを判断する方法

• URL 内の可変パラメーターによる低い CDN/DCDN キャッシュヒット率を解決する方法

• ファイルをキャッシュせずにオリジンサーバーから直接フェッチするように設定する方法

• CDN/DCDN コンソールでキャッシュの TTL を 0 に設定しても、コンテンツが最新ではないのはなぜですか？

• オリジンサーバー上のファイルが更新された後、CDN/DCDN POP 上のキャッシュは自動的かつリアルタイムに更新されますか？

• CDN/DCDN のキャッシュヒット率を低下させる可能性のある要因

• 低いキャッシュヒット率のトラブルシューティング方法

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

• グローバルキャッシュ設定の構成方法

• Nginx の HTTP キャッシュポリシーの設定

• Apache のキャッシュポリシーの設定

• IIS のキャッシュポリシーの設定

• CDN を使用して静的リソースを高速化する際のサーバーサイドキャッシュの TTL の設定方法

• CDN によって提供されるコンテンツがオリジンサーバーのコンテンツと異なるのはなぜですか？

• キャッシュ設定が有効にならないのはなぜですか？

• CDN のオリジン間リソース共有 (CORS) の設定

• Access-Control-Allow-Origin レスポンスヘッダーを設定した後でも、オリジン間エラーが発生し、設定したレスポンスヘッダーが見つからないのはなぜですか？

• 異常なステータスコードのキャッシュルール

• 送信レスポンスヘッダーと受信レスポンスヘッダーの違い

• ドメイン全体をキャッシュしないように設定する方法

• CDN はマルチレプリカキャッシングをサポートしていますか？

キャッシュのパージメカニズムとは

CDN POP 上でキャッシュされたリソースのアクセス頻度が低い (つまり、同じ CDN POP 上のクライアントからのアクセスが少ない) 場合、キャッシュの有効期限が切れる前に、よりアクセス頻度の高いリソースによって CDN POP 上で上書きされる可能性があります。

デフォルトのキャッシュルールとは

CDN POP がオリジンサーバーからファイルを受信すると、次の優先順位に基づいてキャッシュルールが適用されます。数値が小さいほど優先順位が高くなります。

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

2. CDN コンソールで設定されたキャッシュ TTL またはステータスコード TTL。

   説明

   リクエストが複数のルールに一致する場合、1 つのルールのみが有効になります。優先順位は、まず重みによって決定され、次に作成時間によって決定されます。

   • 複数のキャッシュルールがある場合は、各ルールに異なる重みを設定して、実行の優先順位を制御します。重みが大きいほど優先順位が高くなります。

   • 同じ重みのルールの場合、ルールタイプに関係なく、先に作成されたルールが優先されます。

3. オリジンサーバーで設定された他のキャッシュルール。優先順位は高い順に cache-control > expires > last-modified > ETag となります。

   1. オリジンの応答に cache-control ヘッダーが含まれ、その値に max-age または s-maxage が含まれ、max-age または s-maxage の値が 0 より大きい場合、cache-control ヘッダーがキャッシュの有効期限を決定します。例：cache-control: max-age=3600。max-age と s-maxage の両方が存在する場合、s-maxage が優先されます。

   2. オリジンの応答に cache-control は含まれず、Expires ヘッダーが含まれる場合、キャッシュの TTL は Expires ヘッダーによって決定されます。例：expires:Tue, 25 Nov 2031 17:25:43 GMT。

   3. オリジンの応答に cache-control または Expires は含まれず、last-modified が含まれる場合、キャッシュ期間は (現在時刻 - last-modified) × 0.1 の式で計算されます。期間は 10 秒から 3,600 秒の間に制限されます。計算値が 10 秒未満の場合、キャッシュ期間は 10 秒です。値が 3,600 秒を超える場合、キャッシュ期間は 3,600 秒です。

   4. オリジンの応答に cache-control、Expires、または last-modified は含まれず、ETag が含まれる場合、リソースは 10 秒間キャッシュされます。

4. オリジンサーバーからの応答にこれらのキャッシュ関連ヘッダー (cache-control、expires、last-modified、または ETag) がいずれも含まれていない場合、リソースはデフォルトではキャッシュされません。

リソースがキャッシュされているかどうかを確認する方法

HTTP レスポンスヘッダーを確認することで、CDN がファイルをキャッシュしているかどうかを判断できます。

1. X-Cache：リクエストが CDN キャッシュにヒットしたかどうかを示します。値が HIT の場合はキャッシュヒットを示します。値が MISS またはヘッダーがない場合はキャッシュミスを示します。

2. Age：ファイルが CDN POP にキャッシュされてからの時間 (秒) です。このヘッダーは、パージされたファイルや初回リクエストには存在しません。Age の値が 0 の場合は、キャッシュの有効期限が切れており、オリジンサーバーでの再検証が必要であることを示します。

3. X-Swift-CacheTime：CDN POP で設定されたキャッシュ期間です。残りのキャッシュ時間は、X-Swift-CacheTime – Age の式で計算できます。

4. X-Swift-SaveTime：リソースが CDN POP に初めてキャッシュされた GMT 時刻です。UTC+8 に変換するには、8 時間を加算します。

これらの HTTP レスポンスヘッダーを表示するには、次のいずれかの方法を使用して、コンテンツが CDN にキャッシュされているかどうかを確認できます。

curl "http://example.com/path/to/response.html" -v

URL 内の可変パラメーターによる低いキャッシュヒット率の問題を解決する方法

これは、「パラメーターを無視」機能が有効になっていないことが原因である可能性があります。詳細については、「URL 内の可変パラメーターによる低いキャッシュヒット率」をご参照ください。

ファイルをキャッシュせずにオリジンサーバーから直接フェッチするように設定する方法

特定のリソースがキャッシュされないようにするには、ディレクトリ、ファイルパス、またはファイルタイプに基づいてキャッシュの TTL を 0 に設定します。

• タイプ：ディレクトリ または ファイル拡張子 を選択します。

• アドレス：キャッシュしたくないディレクトリのパスまたはファイル拡張子を入力します。たとえば、.php、.jsp、.asp 拡張子を持つ動的ファイルや、/admin ディレクトリ内のすべてのファイルなどです。

• 有効期限：値を 0 に設定します。これにより、このタイプのリソースはキャッシュされないことを指定します。

• 重み：必要に応じて重みの値を調整します。重みが大きいほど優先順位が高くなります。

詳細については、「CDN キャッシュの有効期限の設定」をご参照ください。

キャッシュ TTL を 0 に設定してもコンテンツが最新でないのは、CDN コンソールの設定が原因ですか？

CDN コンソールでキャッシュの TTL を 0 に設定すると、すべてのリクエストがオリジンサーバーにリダイレクトされ、最新のコンテンツが取得されるようになります。しかし、アクセスしたリソースがまだ最新バージョンでない場合、原因は次のいずれかである可能性があります。

1. ブラウザのキャッシュ：ブラウザが古いコンテンツをキャッシュしている可能性があります。ブラウザのキャッシュをクリアするか、プライベートブラウジングウィンドウを使用してテストできます。

2. 設定の伝搬遅延：キャッシュの TTL を 0 に設定した後、その設定がすべての CDN POP に伝搬するまでに時間がかかる場合があります。CDN POP が更新された設定を受信していない場合、古いコンテンツを提供し続ける可能性があります。

3. オリジンサーバーのキャッシュ：オリジンサーバーには独自のキャッシュ機構がある場合があります。オリジンサーバーのキャッシュが更新されていない場合、CDN POP はオリジンフェッチ中に古いコンテンツを取得する可能性があります。

4. POP キャッシュのパージ遅延：設定変更前にキャッシュされたリソースは、パージされるまでに時間がかかる場合があります。キャッシュを手動でパージして、すぐに最新のコンテンツを取得できます。詳細については、「ユーザーガイド」をご参照ください。

オリジンサーバー上のファイルが更新された後、POP 上のキャッシュは自動的かつリアルタイムに更新されますか？

オリジンサーバー上のファイルが更新された後、CDN POP 上のキャッシュは自動的またはリアルタイムには更新されません。キャッシュの更新は、設定されたキャッシュポリシーによって決まります。

• CDN POP は、設定されたキャッシュ TTL に基づいてキャッシュを更新します。キャッシュの有効期限が切れていない場合、オリジンサーバー上のファイルの変更は CDN キャッシュにすぐには反映されません。詳細については、「CDN キャッシュの有効期限の設定」をご参照ください。

• キャッシュを手動でパージすることで、次のリクエストでオリジンサーバーから最新のコンテンツを取得できます。

  • コンソールからパージするには、「ユーザーガイド」をご参照ください。

  • API 操作を呼び出してパージするには、「キャッシュの更新」をご参照ください。

キャッシュヒット率を低下させる可能性のある要因

以下の要因が Alibaba Cloud CDN のキャッシュヒット率を低下させる可能性があります。

1. キャッシュのパージ：手動または自動のキャッシュパージにより、キャッシュヒット率が一時的に低下する可能性があります。

2. 帯域幅の急増：短期間での帯域幅の急激な増加は、CDNDCDN POP からのオリジンリクエストの増加につながり、キャッシュヒット率を低下させます。

3. 新しいコンテンツへのリクエスト：CDNDCDN POP が新しいコンテンツへの初回リクエストを頻繁に受信する場合、より多くのオリジンフェッチが必要になります。これにより、キャッシュヒット率が低下します。

4. キャッシュルールの変更：キャッシュポリシーの変更は、キャッシュヒット率に影響を与える可能性があります。例としては、不適切に設定されたキャッシュ TTL やキャッシュポリシーが挙げられます。

5. URL 内の可変パラメーター：URL の疑問符 (?) の後に可変パラメーターが含まれている場合、コンテンツが同じであっても、各ユニークな URL は異なるリソースとして扱われます。これにより、オリジンフェッチの数が増加し、キャッシュヒット率が低下します。

6. 不適切に設定されたキャッシュ TTL：静的ファイルの更新頻度に基づいて適切なキャッシュ TTL を設定しない場合、キャッシュされたリソースが早期に期限切れになる可能性があります。これにより、オリジンフェッチが増加し、キャッシュヒット率が低下します。

キャッシュヒット率に影響を与える要因の詳細については、「CDN のキャッシュヒット率の向上」をご参照ください。詳細については、「リソースの更新とプリフェッチ」、「パラメーターの無視」、および「CDN キャッシュの有効期限の設定」をご参照ください。

低いキャッシュヒット率のトラブルシューティング方法

低いキャッシュヒット率は、コンテンツの読み込みを遅くし、オリジンサーバーの負荷を増加させる可能性があります。詳細については、「低い CDN キャッシュヒット率のトラブルシューティング」をご参照ください。

グローバルキャッシュ設定の構成方法

キャッシュの Time to Live (TTL) を使用してグローバルキャッシュ設定を構成するには、タイプ を ディレクトリ に設定し、コンテンツフィールドにスラッシュ (/) を入力してすべてのディレクトリに一致させます。詳細については、「CDN キャッシュの有効期限の設定」をご参照ください。

キャッシュ設定が有効にならないのはなぜですか？

設定したキャッシュルールが有効にならなかった場合、原因は次のいずれかである可能性があります。

1. 伝搬遅延：新しいまたは変更されたキャッシュルールが伝搬するまでに時間がかかる場合があります。伝搬が完了した後にルールを確認できます。

2. キャッシュ更新メカニズム：新しいルールは、すでにキャッシュされているコンテンツにすぐには適用されません。新しいルールは、既存のキャッシュの有効期限が切れた後にのみ有効になります。

3. キャッシュがパージされていない：キャッシュ設定を変更した後、既存のキャッシュされたコンテンツは、有効期限が切れるか手動でパージされるまでユーザーに提供され続けます。詳細については、「リソースの更新とプリフェッチ」をご参照ください。

4. 不適切なキャッシュレスポンスヘッダー：オリジンサーバーからの HTTP レスポンスの Cache-Control および Expires ヘッダーが正しく設定されているか確認してください。

5. キャッシュルールの優先順位：CDN リクエストが複数のルールに一致する場合、優先順位はまず重みによって決定され、次に作成時間によって決定されます。

   • 複数のキャッシュルールがある場合は、各ルールに異なる重みを設定して、実行の優先順位を制御できます。重みが大きいほど優先順位が高くなります。

   • 同じ重みのルールの場合、ルールタイプに関係なく、先に作成されたルールが優先されます。

   設定例：高速化ドメイン名 demo.aliyun.com に以下のキャッシュポリシーが設定されています。CDN POP は、オリジンサーバーからリソース http://demo.aliyun.com/image/example.png をフェッチします。リクエストは両方のルールに一致し、それらの重みは同じですが、作成時刻が早いルールがより高い優先順位を持ちます。この場合、/image ディレクトリのルールが先に作成されたため、有効になります。

HTTP レスポンスヘッダーを使用した CDN のオリジン間リソース共有 (CORS) の設定と重要な注意事項

適切な HTTP レスポンスヘッダーを設定することで、異なるオリジンからのリクエストがご利用のリソースにアクセスできるようにすることができます。詳細については、「オリジン間リソース共有の設定」をご参照ください。

Access-Control-Allow-Origin レスポンスヘッダーを設定した後でも、オリジン間エラーが発生し、設定したレスポンスヘッダーが見つからないのはなぜですか？

Alibaba Cloud CDN で Access-Control-Allow-Origin などのオリジンフェッチレスポンスヘッダーを設定したにもかかわらず、クライアントで依然としてオリジン間の問題が発生し、レスポンスヘッダーが見つからない場合、原因は次のいずれかである可能性があります。

異常なステータスコードのキャッシュルール

• ステータスコード 204、305、404、405、414、424、429、500、501、502、503、および 504 の場合、キャッシュルールは次のとおりです。

  

  1. オリジンサーバーが set-cookie レスポンスヘッダーを返す場合、CDN は応答をキャッシュしません。

  2. オリジンサーバーが Set-Cookie レスポンスヘッダーを返さない場合、応答は CDN コンソールで設定したステータスコードの有効期限に基づいてキャッシュされます。複数のルールがどのように有効になるかについては、「複数ルールの優先順位」セクションをご参照ください。

  3. オリジンサーバーが Set-Cookie レスポンスヘッダーを返さず、CDN コンソールでステータスコードの有効期限を設定していない場合、応答はオリジンサーバーからの Pragma、Cache-Control、または Expires レスポンスヘッダーに基づいてキャッシュされます。

  4. オリジンサーバーが Set-Cookie、Pragma、Cache-Control、または Expires レスポンスヘッダーを返さず、CDN コンソールでステータスコードの有効期限を設定していない場合、応答はデフォルトで 1 秒間キャッシュされます。

• ステータスコード 302、307、および 403 の場合、キャッシュルールは次のとおりです。

  

  1. オリジンサーバーが set-cookie レスポンスヘッダーを返す場合、CDN は応答をキャッシュしません。

  2. オリジンサーバーが Set-Cookie レスポンスヘッダーを返さない場合、応答は CDN コンソールで設定したステータスコードの有効期限に基づいてキャッシュされます。複数のルールがどのように有効になるかについては、「複数ルールの優先順位」セクションをご参照ください。

  3. オリジンサーバーが Set-Cookie レスポンスヘッダーを返さず、CDN コンソールでステータスコードの有効期限を設定していない場合、応答はオリジンサーバーからの Pragma、Cache-Control、または Expires レスポンスヘッダーに基づいてキャッシュされます。

  4. オリジンサーバーが Set-Cookie、Pragma、Cache-Control、または Expires レスポンスヘッダーを返さず、CDN コンソールでステータスコードの有効期限を設定していない場合、応答はキャッシュされません。

• 304 ステータスコードの場合、CDN は応答をキャッシュしません。このステータスコードにキャッシュ期間を設定することはできません。

送信レスポンスヘッダーと受信レスポンスヘッダーの違い

送信レスポンスヘッダーと受信レスポンスヘッダーは、キャッシュアーキテクチャの異なる段階における HTTP ヘッダー情報を表します。

• 送信レスポンスヘッダー：これらのヘッダーは、CDN POP からブラウザなどのクライアントに送信されます。CDN POP がリクエストされたコンテンツをキャッシュに持っている場合、オリジンサーバーに接続することなく、コンテンツを直接クライアントに返します。

• 受信レスポンスヘッダー：これらのヘッダーは、オリジンサーバーから CDN POP に送信されます。CDN POP のキャッシュが期限切れになったり、リクエストがキャッシュミスになったりすると、CDN POP はオリジンサーバーから最新のコンテンツをリクエストします。オリジンサーバーからの応答 (HTTP ヘッダーを含む) が、受信応答です。

送信レスポンスヘッダーと受信レスポンスヘッダーの違いは、適用シナリオと制御するインタラクションにあります。送信レスポンスヘッダーは、クライアントと CDNDCDN POP 間のキャッシュ動作を制御します。受信レスポンスヘッダーは、オリジンサーバーと CDNDCDN POP 間のキャッシュ動作を制御します。これらは、効率的で正確なキャッシュ制御を実現するために、しばしば一緒に使用されます。受信レスポンスヘッダーの詳細については、「受信レスポンスヘッダーの変更」をご参照ください。

ドメイン全体をキャッシュしないように設定する方法

Alibaba Cloud CDN 上のドメイン全体がキャッシュされないようにするには、すべてのパスのキャッシュ TTL を 0 に設定します。次の手順に従います。

1. CDN コンソールにログインします。

2. 左側のナビゲーションウィンドウで、ドメイン名 をクリックします。

3. ドメイン名 ページで、対象のドメイン名を見つけ、操作 列の 管理 をクリックします。

4. ドメインのナビゲーションウィンドウで、キャッシュ設定 をクリックします。

5. キャッシュ有効期限 タブで、追加 をクリックします。

   • タイプ：ディレクトリ を選択します。

   • アドレス：/ を入力します。これはすべてのパスを表します。

   • 有効期限：0 秒 を入力します。

   • 他のパラメーターはデフォルト設定のままにします。

6. OK をクリックして設定を完了します。

CDN はマルチレプリカキャッシングをサポートしていますか？

はい。CDN はデフォルトでマルチレプリカキャッシングをサポートしています。オリジンサーバーは Vary ヘッダーを含めて、CDNDCDN POP が特定のリクエストヘッダーに基づいて異なるレプリカを作成するように指示する必要があります。

たとえば、異なる圧縮タイプをサポートするために、クライアントは Accept-Encoding: gzip を含むリクエストを送信し、オリジンサーバーは gzip 圧縮されたコンテンツを返します。クライアントが Accept-Encoding: br を送信すると、オリジンサーバーは Brotli 圧縮されたコンテンツを返します。これらの異なるバージョンの応答をキャッシュするには、オリジンサーバーはその応答に Vary ヘッダーを追加する必要があります。このヘッダーは、キャッシュシステムにどのリクエストヘッダーを使用してレプリカを区別するかを伝えます。この例では、オリジンサーバーは Vary: Accept-Encoding を設定する必要があります。これは、Accept-Encoding ヘッダーの値に基づいて、異なるキャッシュされたレプリカが保存および提供されることを示します。

CDN を設定してサブディレクトリのホームページにアクセスする方法

ウェブサイトの一般的な慣行として、ユーザーがサブディレクトリにアクセスしたときにデフォルトのホームページを返すことがあります。これを CDN で設定でき、オリジンサーバーに変更を加える必要がなくなります。

たとえば、ホームページファイルが https://www.example.com/cdn/index.html の場合、この方法により、https://www.example.com/cdn または https://www.example.com/cdn/ サブディレクトリにアクセスしてもホームページファイルが返されるようになります。