キャッシュの詳細

キャッシュへの保存

すべての HTTP レスポンスがキャッシュに保存できるわけではありません。Cloud CDN がキャッシュに保存するのは、このセクションで説明する要件をすべて満たしているレスポンスだけです。この要件の一部は RFC 7234 で規定されています。その他の要件は Cloud CDN 固有のものです。

次の条件をすべて満たしている場合にのみ、Cloud CDN キャッシュにレスポンスが保存されます。

  • Cloud CDN が有効になっているバックエンド サービスまたはバックエンド バケットから提供されている。
  • GET リクエストに対するレスポンスである。
  • ステータス コードが 200、203、206、300、301、302、307、410 のいずれかである。
  • Cache-Control: public ヘッダーがある。
  • Cache-Control: s-maxage、Cache-Control: max-age、Expires のいずれかのヘッダーがある。
  • Content-Length、Content-Range、Transfer-Encoding のいずれかのヘッダーがある。
  • サイズが最大サイズ以下である。

バックエンド バケットの場合、これらの要件を満たす方法はいくつかあります。

レスポンスがキャッシュに保存されるかどうか確認する方法もあります。次のいずれかに該当する場合、レスポンスはキャッシュに保存されません。

  • Set-Cookie ヘッダーがある。
  • Vary ヘッダーに Accept、Accept-Encoding、Origin 以外の値が設定されている。
  • Cache-Control: no-store、no-cache、private のいずれかのディレクティブが設定されている。
  • 対応するリクエストに Cache-Control: no-store ディレクティブが設定されている。

これらの要件は今後緩和される可能性があり、その結果として Cloud CDN のキャッシュに保存されるレスポンスの種類が増えます。

Cache-Control: no-store、no-cache、または private が存在している場合、URL 署名が構成されているため、コンテンツがキャッシュに保存されたままになります。レスポンスがキャッシュされるのを防ぐ方法については、キャッシュの禁止セクションをご覧ください。

最大サイズ

Cloud CDN で制限が適用される最大サイズは、送信元サーバーがバイト範囲リクエストをサポートするかどうかによって異なります。

  • 送信元サーバーがバイト範囲リクエストをサポートしている場合は、5 TB（5,497,558,138,880 バイト）
  • 送信元サーバーがバイト範囲リクエストをサポートしていない場合は、10 MB（10,485,760 バイト）

本体のサイズが最大サイズより大きいレスポンスはキャッシュに保存されません。

キャッシュ エントリ

キャッシュキー

Cloud CDN キャッシュのキャッシュ エントリは、キャッシュキーで識別されます。リクエストがキャッシュに保存されるときに、リクエストの URI がキャッシュキーに変換され、キャッシュに保存されているエントリのキーと比較されます。一致するキーが見つかると、そのキーに対応するオブジェクトが返されます。

バックエンド サービスの場合、デフォルトでは、Cloud CDN はキャッシュキーとして完全なリクエスト URI を使用します。たとえば、cat.jpg オブジェクトの特定のリクエストでは https://example.com/images/cat.jpg が完全な URI になります。この文字列がデフォルトのキャッシュキーとして使用されます。文字列が完全に同じリクエストのみが一致します。http://example.com/images/cat.jpg や https://example.com/images/cat.jpg?user=user1 などのリクエストは一致しません。

キャッシュキーで使用される URI の部分を変更できます。ファイルのパスと名前は常にキーに使用されますが、プロトコル、ホスト、クエリ文字列はキャッシュキーをカスタマイズするときに加または省略できます。キャッシュキーのカスタマイズ方法については、キャッシュキーの使用をご覧ください。

  • プロトコル: キーでは、プロトコルを省略できます。プロトコルを省略すると、https://example.com/images/cat.jpg のリクエストは example.com/images/cat.jpg のキャッシュキーを受信します。その後、https://example.com/images/cat.jpg と http://example.com/images/cat.jpg の両方のリクエストが、キャッシュ エントリに一致した件数としてカウントされます。
  • ホスト: キーではホストを省略できます。ホストを省略すると、example.com と example2.com のリクエストはともに同じキャッシュ エントリに一致します。https://example.com/images/cat.jpg のリクエストの後に https://example2.com/images/cat.jpg のリクエストが送信されると、2 番目のリクエストがキャッシュ ヒットになります。
  • クエリ文字列: キャッシュキーからクエリ文字列を省略できます。クエリ文字列を省略すると、https://example.com/images/cat.jpg?user=user1 のリクエストは https://example.com/images/cat.jpg のキャッシュキーを受信します。https://example.com/images/cat.jpg?user=user1 と https://example.com/images/cat.jpg?user=user2 の両方が同じエントリに一致する可能性があります。クエリ文字列を部分的に選択して省略したり、追加したりできます。

クエリ文字列全体を追加または省略するだけでなく、ホワイトリストまたはブラックリストを使用して、クエリ文字列の一部分を使用することもできます。

バックエンド バケットの場合、キャッシュキーはクエリ文字列のない URI で構成されます。したがって、https://example.com/images/cat.jpg、https://example.com/images/cat.jpg?user=user1、https://example.com/images/cat.jpg?user=user2 はすべて同等です。

クエリ文字列のホワイトリスト

Cloud CDN がキャッシュキーに追加するクエリ文字列パラメータを選択できます。たとえば、user のホワイトリストを作成すると、https://example.com/images/cat.jpg?user=user1&color=blue が https://example.com/images/cat.jpg?user=user1 のキャッシュキーを作成します。これは https://example.com/images/cat.jpg?user=user1&color=red にも一致します。このオプションを使用するには、クエリ文字列を追加し、空でないホワイトリストを指定する必要があります（ブラックリストは指定しません）。

クエリ文字列のブラックリスト

ブラックリストを使用すると、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 には一致しません。このオプションを使用するには、クエリ文字列を追加して空でないブラックリストを指定する必要があります（ホワイトリストは指定しません）。

Vary ヘッダー

Cloud CDN では、リクエスト URI だけでなく、送信元のサーバーがレスポンスに追加した Vary ヘッダーも考慮されます。Vary ヘッダーがある場合、クライアントのリクエスト ヘッダーに応じてレスポンスが異なります。たとえば、レスポンスに Vary: Accept が指定されている場合、Cloud CDN は、Accept: image/webp,image/*,*/*;q=0.8 が指定されているリクエストと Accept: */* が指定されているリクエストに別々のキャッシュ エントリを使用します。

Vary ヘッダーは、圧縮済みコンテンツを配信するときに使用されることもあります。Cloud CDN 自身がレスポンスの圧縮や圧縮解除を行うことはありませんが、送信元サーバーによって圧縮されたレスポンスを Cloud CDN が配信することはできます。送信元サーバーが配信するコンテンツを圧縮するかどうかを選択する基準が Accept-Encoding リクエスト ヘッダーの値である場合は、必ずレスポンスで Vary: Accept-Encoding を指定します。

Vary ヘッダーがあるレスポンスがキャッシュに保存されるのは、キャッシュへの保存に記載されている値のいずれかがヘッダーに設定されている場合のみです。

有効期間と検証リクエスト

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 に優先します。

Cloud CDN がリクエストを受信すると、対応するキャッシュ エントリを参照して有効期間を確認します。キャッシュ エントリが存在し、十分な有効期間が残っている場合、キャッシュからレスポンスを提供します。ただし、有効期間が過ぎている場合、Cloud CDN はバックエンドのいずれかに接続してからでなければ、レスポンスを返すことができません。

以前にキャッシュに保存されたレスポンスに Last-Modified または ETag ヘッダー、あるいはこの両方がある場合、Cloud CDN はこれらのヘッダー内の情報を使用することで、バックエンドでキャッシュ エントリを検証できます。Cloud CDN がこの検証を行う方法は、バイト範囲リクエストを使用してレスポンスがキャッシュに保存されたかどうかによって少々異なります。

  • バイト範囲リクエストを使用してレスポンスがキャッシュに保存された場合、Cloud CDN は If-Modified-Since または If-None-Match ヘッダー、あるいはこの両方を組み込んだ別個の検証リクエストを開始します。
  • それ以外の場合、Cloud CDN は If-Modified-Since または If-None-Match ヘッダー、あるいはこの両方をクライアント リクエストに追加し、その変更したリクエストをバックエンドに転送します。

キャッシュ内のコピーがまだ最新の状態であれば、バックエンドは 304 Not Modified レスポンスを送信するという方法で既存のキャッシュ エントリを検証できます。この場合、バックエンドから送信されるのはレスポンス ヘッダーのみであり、レスポンスの本文は送信されません。Cloud CDN は、新しいレスポンス ヘッダーをキャッシュに挿入して有効期間を更新し、新しいレスポンス ヘッダーとキャッシュ内のレスポンス本文をクライアントに送信します。

以前にキャッシュに保存されたレスポンスに Last-Modified と ETag のいずれのヘッダーもない場合、Cloud CDN は期限切れのキャッシュ エントリを無視し、クライアント リクエストを変更せずにバックエンドに転送します。

キャッシュ エントリの有効期間とは、そのキャッシュ エントリが有効である時間の長さの上限です。期限切れになるまでキャッシュ エントリがキャッシュ内に存在するとは限りません。新しいコンテンツを保存するために、人気のないコンテンツのキャッシュ エントリは削除される場合もあります。指定された有効期間に関係なく、30 日間アクセスされていないキャッシュ エントリは自動的に削除されます。

詳しくは、エビクションと有効期限をご覧ください。

バイト範囲リクエストのサポート

レスポンスが次の条件を満たしている場合、送信元サーバーはバイト範囲リクエストをサポートしていることになります。

  • ステータス コードが 200 OK または 206 Partial Content である。
  • Accept-Ranges: bytes ヘッダーがある。
  • Content-Length または Content-Range ヘッダー、あるいはこの両方がある。
  • ETag ヘッダーと強いバリデータ、または Last-Modified ヘッダー、あるいはこの両方がある。

Google 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 回目にアクセスされたときとなります。

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）がリクエストに含まれることはありません。

キャッシュの禁止

個人情報が Cloud CDN キャッシュに保存されるのを防ぐには:

  1. Cloud CDN キャッシュに保存してはならないレスポンスには、Cache-Control: private ヘッダーを含めます。ウェブブラウザのキャッシュを含むすべてのキャッシュに保存してはならないレスポンスには、Cache-Control: no-store ヘッダーを含めます。
  2. 個人情報へのアクセスを提供する URL に署名しないでください。署名付き URL を使用してコンテンツにアクセスしている場合は、レスポンス内の Cache-Control ディレクティブに関係なく、コンテンツがキャッシュ対象になる可能性があります。

次のステップ