キャッシュに保存可能なレスポンスとは、Cloud CDN がキャッシュに保存できる HTTP レスポンスで、すぐに取り出せるので読み込み時間が短縮されます。すべての HTTP レスポンスがキャッシュに保存可能なわけではありません。
キャッシュ モード
キャッシュ モードでは、Cloud CDN がコンテンツをキャッシュに保存するかどうかを決定する要素を制御できます。
Cloud CDN には 3 つのキャッシュ モードがあり、レスポンスがキャッシュに保存される方法、Cloud CDN が送信元から送信されたキャッシュ ディレクティブを遵守するかどうか、キャッシュ TTL の適用方法を定義します。
次の表に使用可能なキャッシュ モードを示します。
| キャッシュ モード | 動作 |
|---|---|
USE_ORIGIN_HEADERS |
有効なキャッシュ ディレクティブと有効なキャッシュ ヘッダーを設定するには、送信元のレスポンスが必要です。これらのディレクティブのないレスポンスは、送信元から転送されます。 これは、 |
CACHE_ALL_STATIC |
no-store または private ディレクティブがない静的コンテンツを自動的にキャッシュに保存します。有効なキャッシュ ディレクティブを設定した送信元のレスポンスもキャッシュに保存されます。 |
FORCE_CACHE_ALL |
レスポンスを無条件にキャッシュに保存し、送信元で設定されたすべてのキャッシュ ディレクティブをオーバーライドします。このモードに構成された共有バックエンドを使用する場合、非公開のユーザー単位のコンテンツ（ダイナミック HTML や API レスポンスなど）はキャッシュに保存しないでください。 |
設定手順については、キャッシュ モードの設定をご覧ください。
静的コンテンツ
静的コンテンツとは常に同じコンテンツのことであり、異なるユーザーがアクセスする場合でも同じものが表示されます。サイトのスタイル設定で使用する CSS、インタラクティビティを追加する JavaScript、動画、画像コンテンツは通常、特定の URL（キャッシュキー）にアクセスするユーザーごとに変化しないため、Cloud CDN のグローバル エッジ ネットワーク上でのキャッシュ保存のメリットが得られます。
すべての静的コンテンツをキャッシュに保存するようにキャッシュ モードを設定すると、Cloud CDN は次のレスポンスを自動的にキャッシュに保存します。
- CSS（
text/css）、JavaScript（application/javascript）、WOFF2（font/woff2）などのすべてのウェブフォントを含むウェブアセット - JPEG（
image/jpg）や PNG（image/png）などの画像 - H.264、H.265、MP4（
video/mp4）などの動画および MP3（image/mpeg）、MP4（audio/mp4）などの音声ファイル - PDF（
application/pdf）などのフォーマットされたドキュメント
次の表に概要を示します。
| カテゴリ | MIME タイプ |
|---|---|
| ウェブアセット | text/css text/ecmascript text/javascript application/javascript |
| フォント | font/* に一致する Content-Type |
| 画像 | image/* に一致する Content-Type |
| 動画 | video/* に一致する Content-Type |
| 音声 | audio/* に一致する Content-Type |
| フォーマットされたドキュメント タイプ | application/pdf と application/postscript |
Cloud CDN は、配信されるコンテンツの MIME タイプを反映した Content-Type HTTP レスポンス ヘッダーを検査します。
次の点にご注意ください。
送信元のウェブサーバー ソフトウェアが各レスポンスで
Content-Typeを設定する必要があります。多くのウェブサーバーは、NGINX、Varnish、Apache などのContent-Typeヘッダーを自動的に設定します。Cloud Console または
gsutilツールを使用してコンテンツをアップロードすると、Cloud Storage によりContent-Typeヘッダーがアップロード時に自動的に設定されます。レスポンスが MIME タイプに基づいてキャッシュ可能であるものの、
privateまたはno-storeのCache-Controlレスポンス ヘッダー、またはSet-Cookieヘッダー（ルールの完全なリストを参照）がある場合は、キャッシュに保存されません。
Cloud CDN では、有効なキャッシュ可能なレスポンスの多くが URL に反映されないため、レスポンスがキャッシュ可能かどうかを判断するために URL パスでファイル拡張子を使用しません。
text/html および application/json のコンテンツ タイプをキャッシュに保存する場合は、1 人のユーザーのデータを誤ってキャッシュに保存して、すべてのユーザーに提供しないようにするために、レスポンスに明示的な Cache-Control ヘッダーを設定する必要があります。
キャッシュに保存可能なコンテンツ
Cloud CDN がキャッシュに保存するのは、このセクションで説明する要件をすべて満たしているレスポンスだけです。この要件の一部は RFC 7234 で規定されています。その他の要件は Cloud CDN 固有のものです。
次の条件をすべて満たしている場合にのみ、Cloud CDN キャッシュにレスポンスを保存できます。
| 属性 | 要件 |
|---|---|
| 提供元 | バックエンドサービス、バックエンド バケット、またはカスタム送信元（Cloud CDN が有効になっているもの） |
| 何に対するレスポンスか | GET リクエスト |
| ステータス コード | 200、203、204、206、300、301、302、307、308、404、405、410、421、451、または 501 |
| キャッシュ ディレクティブ |
|
| 鮮度 |
|
| コンテンツ | 有効な たとえば、レスポンスのサイズに正しく一致する |
| サイズ | 最大サイズ以下である |
Cloud Storage バックエンド バケットの場合、これらの要件を満たすいくつかの方法を以下に示します。
バケットを公開する。これは、公開コンテンツの場合におすすめの方法です。この設定を使用すると、インターネット上のすべてのユーザーが、オブジェクトとそのメタデータ（ACL を除く）を表示および一覧表示できます。公開オブジェクト専用のバケットを作成することをおすすめします。詳細については、推奨されるバケット アーキテクチャをご覧ください。
個々のオブジェクトを公開して読み取り可能にする。この方法はおすすめしません。
デフォルトでは、バケット全体が一般公開されている場合、または個別のオブジェクトが一般公開されており、個別のオブジェクトが Cache-Control メタデータが指定しない場合、Cloud Storage は Cache-Control: public, max-age=3600 ヘッダーをオブジェクトに割り当てます。Cache-Control メタデータを使用することで、さまざまな値を設定できます。
バックエンド バケットを使用して外部 HTTP(S) ロードバランサを構成する方法の例については、バックエンド バケットを使用した Cloud CDN の設定をご覧ください。
最大サイズ
Cloud CDN では、各レスポンスに最大サイズが適用されます。本文のサイズが最大サイズより大きいレスポンスはキャッシュに保存されませんが、クライアントには配信されます。
最大サイズは、送信元サーバーがバイト範囲リクエストをサポートしているかどうかによって異なります。
| 送信元サーバーがバイト範囲リクエストをサポートしている | 送信元サーバーがバイト範囲リクエストをサポートしていない |
|---|---|
| 5 TB（5,497,558,138,880 バイト） | 10 MB（10,485,760 バイト） |
ほとんどの最新のウェブサーバー（NGINX、Apache、Varnish を含む）は、バイト範囲リクエストをサポートしています。
元のヘッダーに基づいたキャッシュに保存できないコンテンツ
レスポンスがキャッシュに保存されるかどうか確認する方法があります。
レスポンスがキャッシュに保存可能なコンテンツの要件を満たしていない場合、つまり次のいずれかに該当する場合、レスポンスはキャッシュに保存されません。
| 属性 | 要件 |
|---|---|
| 提供元 | バックエンドサービス、バックエンド バケット、またはカスタム送信元（Cloud CDN が有効になっていないもの） |
| Cookie | Set-Cookie ヘッダーがある |
Vary ヘッダー |
Accept、Accept-Encoding、Origin 以外の値が設定されている。 |
| レスポンス ディレクティブ | レスポンスに、no-store または private ディレクティブを含む Cache-Control ヘッダーがある（Cache-Control ヘッダーが無視される FORCE_CACHE_ALL キャッシュ モードを使用している場合を除く） |
| リクエスト ディレクティブ | リクエストに Cache-Control: no-store ヘッダーがある |
| サイズ | 最大サイズを超えている |
これらの要件は今後緩和される可能性があり、その場合は Cloud CDN のキャッシュに保存されるレスポンスの種類が増えます。
Cache-Control: no-store または private が存在するものの、コンテンツが引き続きキャッシュに保存されている場合は、次のいずれかが原因です。
- URL 署名が構成されている。
- Cloud CDN キャッシュ モードが、すべてのレスポンスを強制的にキャッシュに保存するように設定されている。
キャッシュ保存の禁止
個人情報が Cloud CDN キャッシュに保存されるのを防ぐには:
- Cloud CDN キャッシュ モードが
FORCE_CACHE_ALLモードに設定されていないことを確認してください。このモードでは、すべてのレスポンスが無条件にキャッシュに保存されます。 - Cloud CDN キャッシュに保存してはならないレスポンスには
Cache-Control: privateヘッダーを含めます。ウェブブラウザのキャッシュを含むすべてのキャッシュに保存してはならないレスポンスには、Cache-Control: no-storeヘッダーを含めます。 - 個人情報へのアクセスを提供する URL に署名しないでください。署名付き URL を使ってコンテンツがアクセスされる場合は、レスポンス内の
Cache-Controlディレクティブの内容に関係なく、コンテンツがキャッシュ対象になる可能性があります。 Authorizationリクエスト ヘッダーを含む送信元（キャッシュ フィル）のリクエストの場合、Cloud CDN は、キャッシュ モードがUSE_ORIGIN_HEADERSまたはCACHE_ALL_STATICに設定されている場合にのみ、publicキャッシュ制御ディレクティブを含むレスポンスをキャッシュに保存します。これにより、ユーザー単位のコンテンツや認証を必要とするコンテンツが意図せずキャッシュに保存されるのを防ぐことができます。FORCE_CACHE_ALLキャッシュ モードには、この制限はありません。
カスタム レスポンス ヘッダーの追加
カスタム レスポンス ヘッダーを使用すると、外部 HTTP(S) ロードバランサがプロキシされたレスポンスに追加するヘッダーを指定できます。カスタム レスポンス ヘッダーを使用すると、クライアント、クライアントの地理的データ、独自の静的レスポンス ヘッダーにキャッシュ ステータスを反映できます。
ヘッダーのリストについては、ヘッダー値に表示できる変数をご覧ください。
手順については、カスタム レスポンス ヘッダーの使用をご覧ください。
キャッシュキー
Cloud CDN キャッシュの各キャッシュ エントリは、1 つのキャッシュキーで識別されます。リクエストがキャッシュに到達すると、リクエストの URI がキャッシュキーに変換され、さまざまなキャッシュ済みエントリのキーと比較されます。一致するキーが見つかると、そのキーに対応するオブジェクトが返されます。
バックエンド サービスの場合、デフォルトで、Cloud CDN は完全なリクエスト URI をキャッシュキーとして使用します。たとえば、https://example.com/images/cat.jpg は cat.jpg オブジェクトを求めるリクエストの完全な URI ですが、この文字列がデフォルトのキャッシュキーとして使用され、文字列が完全に同じリクエストのみが一致します。したがって、http://example.com/images/cat.jpg または https://example.com/images/cat.jpg?user=user1 に対するリクエストは一致しません。
キャッシュキーで使用される URI の部分を変更できます。キーには常にファイル名とパスが含まれている必要がありますが、キャッシュキーをカスタマイズするときには、プロトコル、ホスト、クエリ文字列を任意に組み合わせて含めたり省略したりできます。キャッシュキーのカスタマイズ方法については、キャッシュキーの使用をご覧ください。
| URI の各部分 | カスタマイズ | 同じキャッシュキーを持つ URL の例 |
|---|---|---|
| プロトコル | キャッシュキーからプロトコルを省略します。 |
|
| ホスト | キャッシュキーからホストを省略します。 |
|
| クエリ文字列 | キャッシュキーからクエリ文字列を省略します。 クエリ文字列を部分的に省略または追加します。 |
|
クエリ文字列全体を追加または省略するだけでなく、追加リストと除外リストを使用してクエリ文字列の一部を使用することもできます。
バックエンド バケットの場合、キャッシュキーは、プロトコル、ホスト、クエリ文字列を含まない URI で構成されます。
したがって、特定のバックエンド バケットについて、次の URI はキャッシュ内の同じ 1 つのオブジェクトに解決されます。
http://example.com/images/cat.jpghttps://example.com/images/cat.jpghttps://example.com/images/cat.jpg?user=user1http://example.com/images/cat.jpg?user=user1https://example.com/images/cat.jpg?user=user2https://media.example.com/images/cat.jpghttps://www.example.com/images/cat.jpg
クエリ文字列の追加リスト
Cloud CDN がキャッシュキーに追加するクエリ文字列パラメータを選択できます。たとえば、user の追加リストを作成すると、https://example.com/images/cat.jpg?user=user1&color=blue は https://example.com/images/cat.jpg?user=user1&color=red にも一致する https://example.com/images/cat.jpg?user=user1 のキャッシュキーを作成します。
このオプションを使用するには、クエリ文字列を追加して空でない追加リストを指定する必要があります（除外リストは指定しません）。
クエリ文字列の除外リスト
除外リストを使用すると、Cloud CDN が無視するクエリ文字列パラメータを選択的に制御できます。たとえば、user の除外リストを作成すると、user を除くすべてのクエリ文字列パラメータがキャッシュキーで使用されます。
このように除外リストを構成した状態で https://example.com/images/cat.jpg?user=user1&color=blue と入力された場合、Cloud CDN はキャッシュキー https://example.com/images/cat.jpg?color=blue を作成します。このキーは https://example.com/images/cat.jpg?user=user2&color=blue にも一致しますが、https://example.com/images/cat.jpg?user=user1&color=red には一致しません。
このオプションを使用するには、クエリ文字列を追加して空でない除外リストを指定する必要があります（追加リストは指定しません）。
キャッシュ制御ディレクティブ
次の表に概要を示すように、HTTP キャッシュ制御ディレクティブは Cloud CDN の動作に影響を与えます。
該当なしは、ディレクティブがリクエストまたはレスポンスに適用されないことを示します。
| ディレクティブ | リクエスト | イベントに |
|---|---|---|
no-store |
リクエストに含まれている場合、Cloud CDN はこれに従い、レスポンスをキャッシュに保存しません。 |
この設定は、ルートごとに |
no-cache |
no-cache リクエスト ディレクティブは無視され、クライアントがリクエストを開始する、または送信元に対する再検証を強制する可能性が回避されます。 |
この設定は、ルートごとに |
public |
該当なし |
|
private |
該当なし |
この設定は、ルートごとに |
max-age=seconds
|
max-age リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていないかのように返されます。 |
max-age ディレクティブを含むレスポンスは、定義済みの seconds を上限とする期間キャッシュに保存されます。 |
s-maxage=seconds
|
該当なし |
|
min-fresh=seconds
|
min-fresh リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていないかのように返されます。 |
該当なし |
max-stale=seconds
|
Cloud CDN はこれを適用し、レスポンスのステイルネスが |
該当なし |
stale-while-revalidate=seconds
|
該当なし |
この動作は、バックエンドで |
stale-if-error=seconds
|
stale-if-error リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていないかのように返されます。 |
このレスポンス ヘッダーには効果がありません。
この動作は、ルートで |
must-revalidate |
該当なし |
このディレクティブを含む古くなったレスポンスは配信されません。 |
proxy-revalidate |
このディレクティブを含む古くなったレスポンスは配信されません。 |
|
immutable |
該当なし | 影響なし。これは、レスポンスでクライアントに渡されます。 |
no-transform |
該当なし | Cloud CDN で変換は適用されません。 |
only-if-cached |
only-if-cached リクエスト ディレクティブは無視されます。キャッシュに保存されたレスポンスは、このヘッダーがリクエストに含まれていないかのように返されます。 |
該当なし |
可能な場合については、Cloud CDN が RFC に準拠（HTTP RFC 7234）するよう努めますが、キャッシュ オフロードの最適化、ヒット率または全般的な送信元負荷に対してクライアントが与える可能性がある影響を最小限に抑えることを優先します。
HTTP/1.1 Expires ヘッダーを使用するレスポンスの場合:
Expiresヘッダーの値は、RFC 7231 で定義されている有効な HTTP 日付であることが必要です。- 過去の日付値、無効な日付、または
0の値は、コンテンツがすでに期限切れになっており、再検証が必要であることを示します。 Cache-Controlヘッダーがレスポンス内に存在する場合、Cloud CDN はExpiresヘッダーを無視します。
レスポンスに有効な将来の Expires ヘッダーが存在する場合は、レスポンスがキャッシュに保存され、他のキャッシュ ディレクティブを指定する必要はありません。
HTTP/1.0 Pragma ヘッダーがレスポンスに存在する場合は無視され、そのままクライアントに渡されます。このヘッダーを含むクライアント リクエストは送信元に渡され、レスポンスが Cloud CDN によってどのように処理されるかには影響しません。
Vary ヘッダー
Vary ヘッダーがある場合は、クライアントのリクエスト ヘッダーに応じてレスポンスが異なります。Cloud CDN では、リクエスト URI だけでなく、送信元サーバーがレスポンスに追加する Vary ヘッダーも考慮されます。たとえば、レスポンスで Vary: Accept が指定されている場合、Cloud CDN は、Accept: image/webp,image/*,*/*;q=0.8 が指定されているリクエストと Accept: */* が指定されているリクエストに別々のキャッシュ エントリを使用します。
キャッシュに保存できないコンテンツ セクションの表には、コンテンツをキャッシュに保存できるようにする Vary ヘッダーが一覧表示されます。その他の Vary ヘッダー値は、コンテンツがキャッシュに保存されることを禁止します。
FORCE_CACHE_ALL キャッシュ モードはこの動作をオーバーライドしません。Vary ヘッダーは、複数の送信元サーバー レスポンス間でキャッシュが汚染されるのを回避するうえで重要です。FORCE_CACHE_ALL が存在するために、こうしたレスポンスがキャッシュに保存されると危険な状態になります。
Vary ヘッダーは、圧縮済みコンテンツを配信するときに使用されることもあります。Cloud CDN はレスポンスそのものを圧縮、解凍しませんが、送信元サーバーが圧縮したレスポンスを配信できます。Accept-Encoding リクエスト ヘッダーの値に基づいて、送信元サーバーが圧縮、非圧縮コンテンツのどちらを配信するかを選択する場合は、レスポンスで Vary: Accept-Encoding が指定されていることを確認してください。
有効期間と検証リクエスト
USE_ORIGIN_HEADERS キャッシュ モードの場合、Cloud CDN キャッシュの各キャッシュ エントリには RFC 7234 に従って Cache-Control:
s-maxage、Cache-Control: max-age、Expires ヘッダーで定義された有効期間が存在します。複数のヘッダーが存在する場合には、Cache-Control: s-maxage が Cache-Control: max-age よりも優先され、Cache-Control: max-age が Expires よりも優先されます。
CACHE_ALL_STATIC キャッシュ モードでは、静的コンテンツを保持するバックエンド レスポンスは最新とみなされます。静的ではないコンテンツの鮮度は、元のヘッダーに基づきます。
FORCE_CACHE_ALL キャッシュ モードでは、すべてのバックエンド レスポンスが最新とみなされます。
Cloud CDN がリクエストを受信すると、該当するキャッシュ エントリを参照して有効期間を確認します。キャッシュ エントリが存在し、有効期間が残っている場合、キャッシュからレスポンスを提供します。ただし、有効期間が経過している場合、Cloud CDN はバックエンドのいずれかに接続してキャッシュ エントリの再検証を試行します。これは、レスポンスを配信する前に行われます。ただし、serve-while-stale ベータ版機能を有効にしている場合、再検証は非同期で実行されます。
Cloud CDN は、キャッシュに滞在する日数が 30 日を超えているオブジェクトを再検証します。ユーザーが生成した古いキャッシュ コンテンツは、この方法によって自動的に無効になり、削除されます。max-age または s-maxage の値が 30 日（2,592,000 秒）を超える場合、Cloud CDN はその値を 2,592,000 秒として処理しますが、ダウンストリーム クライアントには、max-age と s-
maxage の値が 30 日を超える場合でも正しい値がそのまま表示されます。
Cloud CDN は、キャッシュ内のレスポンス ヘッダーに含まれる情報を使用して、バックエンドでキャッシュ エントリを検証できます。これは、次の両方に該当する場合に発生します。
- 以前にキャッシュに保存されたレスポンスに
Last-ModifiedまたはETagヘッダーが含まれている。 - クライアント リクエストが、
If-Modified-SinceまたはIf-None-Matchヘッダーを含まないGETリクエストである。
Cloud CDN がこの検証を行う方法は、バイト範囲リクエストを使ってレスポンスがキャッシュされたかどうかによって少々異なります。
- バイト範囲リクエストを使ってレスポンスがキャッシュに保存された場合、Cloud CDN は
If-Modified-SinceまたはIf-None-Matchヘッダー、あるいはこの両方を含む 1 つの別個の検証リクエストを開始します。 - そうでない場合、Cloud CDN は
If-Modified-SinceまたはIf-None-Matchヘッダー、あるいはこの両方をクライアント リクエストに追加し、変更したリクエストをバックエンドに転送します。
キャッシュ内のコピーがまだ最新の状態であれば、バックエンドは 304 Not Modified レスポンスを送信することで既存のキャッシュ エントリを検証できます。この場合、バックエンドから送信されるのはレスポンス ヘッダーのみであり、レスポンスの本文は送信されません。Cloud CDN は、新しいレスポンス ヘッダーをキャッシュに挿入して有効期間を更新し、新しいレスポンス ヘッダーとキャッシュ内のレスポンス本文をクライアントに送信します。
以前にキャッシュに保存されたレスポンスに Last-Modified と ETag のいずれのヘッダーもない場合、Cloud CDN は期限切れのキャッシュ エントリを無視し、クライアント リクエストをそのままバックエンドに転送します。
キャッシュ エントリの有効期間とは、そのキャッシュ エントリが有効である時間の長さの上限です。キャッシュ エントリが期限切れになるまでキャッシュに保存されるという保証はありません。新しいコンテンツの場所を確保する目的で、人気のないコンテンツのキャッシュ エントリが削除される場合もあります。指定された有効期間に関係なく、30 日間アクセスされていないキャッシュ エントリは自動的に削除されます。
詳しくは、エビクションと有効期限をご覧ください。
TTL の設定とオーバーライド
コンテンツを再検証するまでの Cloud CDN の待機時間について、Cloud CDN の動作を微調整できます。
詳細については、TTL の設定とオーバーライドを使用するをご覧ください。
バイト範囲リクエストのサポート
レスポンスが次の条件を満たしている場合、送信元サーバーはバイト範囲リクエストをサポートしていることになります。
- ステータス コード:
200 OKまたは206 Partial Content - ヘッダー:
Accept-Ranges: bytes - ヘッダー:
Content-LengthまたはContent-Range - ヘッダー: 強いバリデータを使用した
ETag - ヘッダー:
Last-Modified
Cloud Storage は、ほとんどのオブジェクトに関してバイト範囲リクエストをサポートしています。ただし、Content-Encoding: gzip メタデータを持つオブジェクトについては、クライアント リクエストの中に Accept-
Encoding: gzip ヘッダーがある場合を除き、バイト範囲リクエストがサポートされません。Cloud Storage オブジェクトが 10 MB を超える場合は、Content-Encoding: gzip メタデータがないことを確認してください。オブジェクトのメタデータの編集方法については、オブジェクトのメタデータの表示と編集をご覧ください。
一般的なウェブサーバー ソフトウェアでも、バイト範囲リクエストがサポートされています。サポートを有効にする方法の詳細については、お使いのウェブサーバー ソフトウェアのドキュメントをご覧ください。バイト範囲リクエストの詳細については、HTTP 仕様をご覧ください。
送信元サーバーがバイト範囲リクエストをサポートしている場合、次のいずれかの条件が当てはまると、Cloud CDN キャッシュは、本来ならばキャッシュ保存可能なレスポンスでも、初回リクエスト時にはキャッシュへの保存を拒否します。
- クライアントがコンテンツの一部分だけをリクエストしたことが理由で、レスポンス本文が不完全である。
- レスポンス本文が 1 MB（1,048,576 バイト）を超えている。
レスポンスが通常のキャッシュ保存の要件を満たしているにもかかわらず、前述の拒否が発生した場合は、送信元サーバーがそのキャッシュキーに対してバイト範囲リクエストをサポートしていることがキャッシュに記録され、送信元サーバーのレスポンスがクライアントに転送されます。
キャッシュミスが発生した場合、キャッシュは、送信元サーバーがバイト範囲リクエストをサポートしているという記録があるかどうかを調べます。そのキャッシュキーでバイト範囲リクエストがサポートされていることがわかれば、クライアント リクエストがキャッシュから外部 HTTP(S) ロードバランサに転送されることはありません。代わりに、コンテンツの不足部分を求めてキャッシュ自体がバイト範囲キャッシュ フィル リクエストを開始します。送信元サーバーからの 206 Partial Content レスポンスで、リクエストされたバイト範囲が返された場合、キャッシュはその範囲を将来のリクエストに備えて保存できます。
キャッシュが 206 Partial Content レスポンスを保存するのは、キャッシュ自体がバイト範囲リクエストを開始し、それに対してこのレスポンスを受け取った場合のみです。送信元サーバーがバイト範囲リクエストをサポートしていることが記録されている限り、キャッシュはそのキャッシュキーについてバイト範囲リクエストを開始できます。1 MB を超える大きなサイズのコンテンツが 2 回目にアクセスされるまでキャッシュに保存されない（初回リクエスト時には拒否される）のは、このようなメカニズムが背景で働いているからです。
リクエストの折りたたみ（結合）
リクエストの折りたたみ（結合とも呼ばれます）によって、同じキャッシュキーの複数のユーザー提供のキャッシュ フィル リクエストは、能動的にエッジノードごとに 1 つの送信元リクエストに折りたたまれます。これにより、送信元の負荷を積極的に軽減できます。この機能は、アイテム リクエスト（直接取得されるレスポンス）とチャンク リクエストの両方に適用されます。その際に、Cloud CDN は Range リクエストを使用して、サイズの大きいオブジェクトをより効率的に取得します。
リクエストの折りたたみはデフォルトで有効になっています。
折りたたまれたリクエストは、次のように動作します。
- 折りたたまれたリクエストは、クライアント側のリクエストと（折りたたまれた）キャッシュ フィル リクエストの両方をログに記録します。
- 折りたたみセッションのリーダー は、元のフィル リクエストを行うために使用されます。
- キャッシュキーに含まれていないリクエスト属性（
User-AgentヘッダーやAccept-Encodingヘッダーなど）は、折りたたまれたセッションのリーダーのみを反映しています。 - 同じキャッシュキーを持たないリクエストは折りたたむことができません。
次の図に、リクエストがどのように結合されるかを示します。
これと比較して、折りたたみが無効になっているリクエスト、または結合できないリクエストの場合、送信元のリクエストとレスポンスの数は、現在キャッシュに保存されていないオブジェクトの取得を試行しているクライアントの数と同じになる可能性があります。
以下のタイプのリクエストでは、折りたたみが常に有効になっています。
- チャンク リクエスト。これにより、元の帯域幅を大幅に削減できます。
- アイテム リクエスト。これにより、元のリクエスト量を削減できます。元の負荷が検討対象ではない広告配信など、レイテンシが重要とされるシナリオにおいてアイテム リクエストを無効にできます。
Cloud Storage バケットを参照するバックエンド バケットの Cloud SDK を使用してアイテム リクエストの折りたたみを無効にするには、次の操作を行います。
gcloud
gcloud beta compute backend-services コマンドまたは backend-buckets コマンドを使用します。
gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
--no-request-coalescing
Cloud SDK を使用してアイテム リクエストの折りたたみを有効にするには、次の操作を行います。
gcloud
gcloud beta compute backend-buckets コマンドを使用します。
gcloud beta compute backend-buckets update BACKEND_BUCKET_NAME \
--request-coalescing
VM グループやカスタム送信元などのバックエンド サービス用に Cloud SDK を使用してアイテム リクエストの折りたたみを有効にするには、次の操作を行います。
gcloud
gcloud beta compute backend-services コマンドを使用します。
gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
--request-coalescing
Cloud CDN によって作成されるリクエスト
送信元サーバーがバイト範囲リクエストをサポートしている場合、単一のクライアント リクエストに対して Cloud CDN から複数のリクエストが送信元サーバーに送信されることがあります。Cloud CDN が作成できるリクエストには、検証リクエストとバイト範囲リクエストの 2 種類があります。
送信元サーバーが特定のキャッシュキーのバイト範囲リクエストをサポートしていることがレスポンスで示されていたものの、そのレスポンスの有効期間が過ぎている場合は、Cloud CDN が検証リクエストを開始します。その目的は、コンテンツが変化していないこと、また送信元サーバーが引き続きそのコンテンツの範囲リクエストをサポートしていることの確認です。送信元サーバーから 304 Not Modified レスポンスが返された場合、Cloud CDN はそのバイト範囲を使用してコンテンツを配信します。そうでない場合、Cloud CDN は送信元サーバーのレスポンスをクライアントに転送します。有効期限を制御するには、Cache-Control と Expires のレスポンス ヘッダーを使用します。
キャッシュミスが発生した場合、Cloud CDN はクライアント リクエストと重複する一連のバイト範囲に対するキャッシュ フィル リクエストを開始します。クライアントからリクエストされたコンテンツの範囲の一部がキャッシュにある場合、Cloud CDN はできる限りキャッシュから配信し、不足している範囲についてのみ、バイト範囲リクエストを送信元サーバーに送ります。
Cloud CDN が開始するバイト範囲リクエストには、それぞれ範囲が指定され、範囲の開始オフセットは 2,097,136 バイトの倍数になります。最後の範囲を除いて、各範囲も 2,097,136 バイトです。コンテンツのサイズがこのバイト数の倍数でない場合、最後の範囲がこれより小さくなります。バイト範囲リクエストで使用されるサイズとオフセットは、将来変更される可能性もあります。
例として、クライアントがコンテンツの 1,000,000 バイト目から 3,999,999 バイト目までをリクエストしたが、キャッシュにはそれが存在しないとします。この例では、Cloud CDN は 2 つの GET リクエストを開始します。1 つはコンテンツの最初の 2,097,136 バイト用、もう 1 つは 2 番目の 2,097,136 バイト用です。つまり、クライアントがリクエストしたのは 3,000,000 バイトだけでも、4,194,272 バイト分のキャッシュ フィルが行われます。
Cloud Storage バケットを送信元として使用するときは、GET リクエストごとに独立したクラス B オペレーションとして料金が発生します。料金は、Cloud Storage によって処理されたすべての GET リクエストについて発生します。これには、Cloud CDN によって作成されたリクエストも含まれます。1 つのレスポンス全体が Cloud CDN キャッシュから提供されるときは、GET リクエストが Cloud Storage に送信されないので、Cloud Storage オペレーションの料金は発生しません。
Cloud CDN によって検証リクエストやバイト範囲リクエストが開始されるときに、クライアント固有のヘッダー（たとえば Cookie や User-Agent）がリクエストに含まれることはありません。
キャッシュのバイパス
キャッシュ バイパスでは、コンテンツが以前にキャッシュに保存された場合でも、特定のリクエスト ヘッダーを含むリクエストによるキャッシュのバイパスが許可されます。
このセクションでは、Pragma や Authorization などの HTTP ヘッダーによるキャッシュのバイパスについて紹介します。この機能は、ユーザーまたはお客様が、送信元のサーバーから最新のコンテンツを常に取得できるようにする必要がある場合に有用です。これは、テスト、ステージング ディレクトリ、スクリプトのセットアップを実施する場合に行うことをおすすめします。
指定されたヘッダーが一致する場合は、FORCE_CACHE_ALL であっても、すべてのキャッシュ モード設定に対してキャッシュがバイパスされます。多数のリクエストに共通するヘッダーが指定された場合は、キャッシュ バイパスによって多数のキャッシュミスが発生します。
始める前に
Cloud CDN が有効になっていることを確認します。手順については、Cloud CDN の使用をご覧ください。
必要に応じて、Cloud SDK を最新バージョンに更新します。
gcloud components update
キャッシュ バイパスの構成
最大 5 つの HTTP ヘッダー名を指定できます。値では大文字と小文字が区別されません。 ヘッダー名は、HTTP ヘッダー フィールドで有効なトークンでなければなりません。追加されたヘッダーのリストに、ヘッダー名を複数回使用することはできません。 有効なヘッダー名に関する規則については、カスタム ヘッダーの仕組みをご覧ください。
Console
- Google Cloud Console で、[負荷分散] ページに移動します。
- 外部 HTTP(S) ロードバランサの名前をクリックします。
- [編集] をクリックします。
- [バックエンドの構成] でバックエンドを選択し、[編集] をクリックします。
- [Cloud CDN を有効にする] が選択されていることを確認します。
- ウィンドウの下部にある [詳細構成] をクリックします。
- [リクエスト ヘッダーでキャッシュをバイパスする] で、[ヘッダーを追加] をクリックします。
- ヘッダー名（例:
Pragma、Authorization）を入力します。 - [更新] をクリックします。
- [更新] をもう一度クリックします。
gcloud
バックエンド バケットには、--bypass-cache-on-request-headers フラグを指定して gcloud beta compute backend-buckets create コマンドまたは gcloud beta compute backend-buckets update コマンドを使用します。
バックエンド サービスには、--bypass-cache-on-request-headers フラグを指定して gcloud beta compute backend-services create コマンドまたは gcloud beta compute backend-services update コマンドを使用します。
gcloud beta compute backend-buckets (create | update) BACKEND_BUCKET_NAME
--bypass-cache-on-request-headers=BYPASS_REQUEST_HEADERS
gcloud beta compute backend-services (create | update) BACKEND_SERVICE_NAME
--bypass-cache-on-request-headers=BYPASS_REQUEST_HEADERS
例:
gcloud beta compute backend-services update my-backend-service
--bypass-cache-on-request-headers=Pragma,Authorization
api
バックエンド バケットには、Method: backendBuckets.insert API 呼び出し、Method: backendBuckets.update API 呼び出し、または Method: backendBuckets.patch API 呼び出しを使用します。
バックエンド サービスには、Method: backendServices.insert API 呼び出し、Method: backendServices.update API 呼び出し、または Method: backendServices.patch API 呼び出しを使用します。
例:
PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/global/backendBuckets
JSON リクエストの本文に次のスニペットを追加します。
"cdnPolicy": {
"bypassCacheOnRequestHeaders": [
{
"headerName": string
}
]
}
キャッシュ バイパスを無効にする
gcloud
バックエンド バケットには、--no-bypass-cache-on-request-headers フラグを指定して gcloud beta compute backend-buckets create コマンドまたは gcloud beta compute backend-buckets update コマンドを使用します。
バックエンド サービスには、--no-bypass-cache-on-request-headers フラグを指定して gcloud beta compute backend-services create コマンドまたは gcloud beta compute backend-services update コマンドを使用します。
gcloud beta compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
--no-bypass-cache-on-request-headers
api
バックエンド バケットには、Method: backendBuckets.insert API 呼び出しまたは Method: backendBuckets.update API 呼び出しを使用します。
バックエンド サービスには、Method: backendServices.insert API 呼び出しまたは Method: backendServices.update API 呼び出しを使用します。
次のいずれかの API 呼び出しを使用します。
POST https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/global/backendBuckets PUT https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET POST https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/global/backendServices PUT https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
JSON リクエストの本文に次のスニペットを追加します。
"cdnPolicy": {
"fields": "bypassCacheOnRequestHeaders"
}
次のステップ
- キャッシュ モードでコンテンツのキャッシュ保存を容易にする方法については、キャッシュ モードの使用をご覧ください。
- HTTP(S) 負荷分散および負荷分散インスタンス用に Cloud CDN を有効にするには、Cloud CDN の使用をご覧ください。
- キャッシュの無効化については、キャッシュ無効化の概要をご覧ください。
- GFE の接続拠点を確認するには、キャッシュのロケーションをご覧ください。