このページでは、Cloud CDN で TTL オーバーライドを変更する方法について説明します。TTL オーバーライドを使用すると、Cloud CDN によってコンテンツが再検証までにキャッシュに保存される期間を詳細に制御できます。
次の表に、TTL 設定の概要を示します。
| デフォルト TTL | 最大 TTL | クライアント TTL | |
|---|---|---|---|
| 構成の理由 | 更新頻度の低いコンテンツのキャッシュ ヒット率を向上させる | 送信元のヘッダーの指定よりも高い頻度で Cloud CDN がコンテンツを再検証する | クライアントが Cloud CDN に対してコンテンツの再検証をより頻繁に行うようにする |
| 使用するタイミング | 正常なレスポンスの場合、次のいずれかに該当する:
|
以下のすべてに該当する:
|
次のいずれかに該当する:
|
| デフォルト値 | 3,600 秒（1 時間） | 86,400 秒（1 日） | 3,600 秒（1 時間） |
| 許容最大値 | 31,622,400 秒（1 年） | 31,622,400 秒（1 年） | 31,622,400 秒（1 年） |
| 注 | 最大 TTL の値以下でなければならない--default-ttl=0レスポンスを送信元で再検証する |
最大 TTL 以下でなければならない |
始める前に
キャッシュ モードについて確認します。
Cloud CDN が有効になっていることを確認します。手順については、Cloud CDN の使用をご覧ください。
必要に応じて、次のコマンドで Google Cloud CLI を最新バージョンに更新します。
gcloud components update
デフォルトの TTL を設定する
デフォルトの TTL をオーバーライドして、Cloud CDN が送信元のコンテンツを再検証する頻度を下げることで、更新頻度の低いコンテンツのキャッシュ ヒット率を向上させることができます。ただし、アクセス頻度の少ないオブジェクトが、定義された TTL の前にキャッシュから除外される場合があります。
キャッシュ モードが FORCE_CACHE_ALL の場合、デフォルトの TTL は、すべてのレスポンスに設定されている TTL（送信元のヘッダーで TTL が設定されているレスポンスを含む）を上書きします。このモードでは、デフォルトの TTL はクライアントに表示されます。これは、Cloud CDN がクライアントに配信されるレスポンスの public 属性と max-age 属性を設定するためです。
CACHE_ALL_STATIC モードの場合、有効な TTL（max-age、s-max-age、または Expires ヘッダー）がないレスポンスに対して送信元から提供されたキャッシュ内のコンテンツにデフォルトの TTL が適用されます。CACHE_ALL_STATIC モードの場合、デフォルトの TTL でクライアントに配信される Cache-Control ヘッダーは変更されません。CACHE_ALL_STATIC モードで Cache-Control ヘッダーを変更するには、クライアント TTL を設定する必要があります。
送信元のヘッダー（USE_ORIGIN_HEADERS）を使用するようにキャッシュ モードを設定すると、Cloud CDN は max-age または s-max-age の送信元のディレクティブ、または Expires ヘッダーを代わりに使用するため、デフォルトの TTL 値は適用されず、設定できません。
コンソール
- Google Cloud コンソールの [ロード バランシング] ページに移動します。
- 外部 HTTP(S) ロードバランサの名前をクリックします。
- [編集] をクリックします。
- [バックエンドの構成] でバックエンドを選択し、[編集] をクリックします。
- [Cloud CDN を有効にする] が選択されていることを確認します。
- キャッシュ モードが [静的コンテンツをキャッシュする（推奨）] または [すべてのコンテンツを強制的にキャッシュする] であることを確認します。キャッシュ モードが [Cache-Control ヘッダーに基づいて送信元の設定を使用する] の場合、TTL 値をオーバーライドすることはできません。
- [デフォルトの有効期間] で値を選択します。
- [保存] をクリックします。
gcloud
バックエンド サービスの場合は、--default-ttl フラグを指定して gcloud compute backend-services
create または gcloud compute backend-services
update コマンドを使用します。
バックエンド バケットの場合は、--default-ttl フラグを指定して gcloud compute backend-buckets
create または gcloud compute backend-buckets
update コマンドを使用します。
gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
--default-ttl=DEFAULT_TTL
gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
--default-ttl=DEFAULT_TTL
DEFAULT_TTL を 31,622,400 秒（1 年間）以下の値に置き換えます。
API
バックエンド バケットの場合は、Method: backendBuckets.insert または Method: backendBuckets.update API 呼び出しを使用します。
バックエンド サービスの場合は、Method: backendServices.insert または Method: backendServices.update API 呼び出しを使用します。
次のいずれかの API 呼び出しを使用します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
JSON リクエストの本文に次のスニペットを追加します。
"cdnPolicy": {
"defaultTtl": DEFAULT_TTL
}
DEFAULT_TTL を 31,622,400 秒（1 年間）以下の値に置き換えます。
最大 TTL を設定する
最大 TTL は、送信元から配信されるキャッシュ コンテンツに関して Cloud CDN 内で許可される TTL の上限を指定します。
次のいずれかに該当する場合に、レスポンスの TTL に対して最大 TTL によって上限が設定されます。
- レスポンスは、
max-ageまたはs-maxageを最大 TTL 値よりも高い値に設定することを試みます。 - 今後、レスポンスには
cdnPolicy.maxTtl秒を超えるExpiresヘッダーが含まれます。
最大 TTL の設定は、クライアントに送信される max-age の値を変更しません。詳細については、最大クライアント TTL のオーバーライドをご覧ください。最大 TTL の設定は、Cloud CDN がコンテンツのキャッシュへの保存を試行する時間の長さにのみ影響します。
この設定は、キャッシュ モードが CACHE_ALL_STATIC の場合にのみ使用されます。最大許容値は 31,622,400 秒（1 年）です。ただし、アクセス頻度の少ないオブジェクトが、定義された TTL の前にキャッシュから除外される場合があります。
FORCE_CACHE_ALL では、TTL は常にデフォルトの TTL に設定されます。最大 TTL の設定はできません。
コンソール
- Google Cloud コンソールの [ロード バランシング] ページに移動します。
- 外部 HTTP(S) ロードバランサの名前をクリックします。
- [編集] をクリックします。
- [バックエンドの構成] でバックエンドを選択し、[編集] をクリックします。
- [Cloud CDN を有効にする] が選択されていることを確認します。
- キャッシュ モードが [静的コンテンツをキャッシュする（推奨）] になっていることを確認します。
- [最大有効期間] で値を選択します。
- [保存] をクリックします。
gcloud
バックエンド サービスの場合は、--max-ttl フラグを指定して gcloud compute backend-services
create または gcloud compute backend-services
update コマンドを使用します。
バックエンド バケットの場合は、--max-ttl フラグを指定して gcloud compute backend-buckets
create または gcloud compute backend-buckets
update コマンドを使用します。
gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
--max-ttl=MAX_TTL
gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
--max-ttl=MAX_TTL
MAX_TTL を 31,622,400 秒（1 年間）以下の値に置き換えます。
API
バックエンド バケットの場合は、Method: backendBuckets.insert または Method: backendBuckets.update API 呼び出しを使用します。
バックエンド サービスの場合は、Method: backendServices.insert または Method: backendServices.update API 呼び出しを使用します。
次のいずれかの API 呼び出しを使用します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
JSON リクエストの本文に次のスニペットを追加します。
"cdnPolicy": {
"maxTtl": MAX_TTL
}
MAX_TTL を 31,622,400 秒（1 年間）以下の値に置き換えます。
クライアント TTL をオーバーライドする
すべてのキャッシュ モードで、Cloud CDN は Cache-Control ヘッダーをクライアントに渡します。
クライアント TTL を使用すると、ブラウザまたはクライアントに送信される内容に最大 TTL を設定できるため、クライアントは送信元の再検証を必要とすることなく、より高い頻度で Cloud CDN に対してコンテンツの再検証を実施できます。これにより、必要に応じて Cloud CDN 内でコンテンツを無効にできます。クライアントの TTL が期限切れになると、ブラウザは直ちにコンテンツが無効になったことを検出できます。
FORCE_CACHE_ALL モードでは、Cloud CDN は通常、プロキシ キャッシュ用に内部で使用するのと同じ max-age をクライアントに渡します。ただし、クライアント TTL が指定されており、その値がより小さい場合は、代わりにクライアントの TTL が max-age ディレクティブ内でクライアントに渡されます。同様に、CACHE_ALL_STATIC モードでは、クライアント TTL が送信元サーバーによって指定された任意の max-age のクランプとして機能し、ブラウザまたはクライアントに送信される max-age の値が構成済みのクライアント TTL を超えることはありません。送信元で max-age が指定されない場合は、小さい方の Cloud CDN の TTL とクライアントの TTL 値が、ブラウザまたはクライアントに送信される max-age として使用されます。
送信元のレスポンスに Expires ヘッダーがある場合は、それが削除され、適切な TTL の Cache-Control: max-age ディレクティブに置き換えられます。エラー レスポンスでは、ネガティブ キャッシュ TTL が設定されていなければ Cache-Control ヘッダーも削除されます。
クライアント TTL はブラウザまたはクライアントに送信される情報の最大値として扱われるため、それ以外の場合に送信される max-age の値を増やすためには使用できません。ブラウザやクライアントに送信される max-age の値が予想より低い場合は、送信元から返されるレスポンスの max-age ディレクティブ値を大きくするか、デフォルトの TTL 設定またはネガティブ キャッシュ設定を適切に調整します。
通常、クライアントの TTL 値は、実用的な上限として約 1 日に設定することをおすすめします。1 日の設定では、ブラウザは少なくともその頻度で確認して、Cloud CDN で発生している可能性があるキャッシュ無効化を知ることができます。クライアント TTL には、送信元と構成された TTL を許可する一手段としてより大きな値（最大 1 年）を設定し、クライアントに送信される内容を完全に制御できます。これは、ブラウザで Cloud CDN に対する確認がより頻繁に行われないようにする場合に有用です。
コンソール
- Google Cloud コンソールの [ロード バランシング] ページに移動します。
- 外部 HTTP(S) ロードバランサの名前をクリックします。
- [編集] をクリックします。
- [バックエンドの構成] でバックエンドを選択し、[編集] をクリックします。
- [Cloud CDN を有効にする] が選択されていることを確認します。
- キャッシュ モードが [静的コンテンツをキャッシュする（推奨）] または [すべてのコンテンツを強制的にキャッシュする] であることを確認します。キャッシュ モードが [Cache-Control ヘッダーに基づいて送信元の設定を使用する] の場合、TTL 値をオーバーライドすることはできません。
- [クライアントの有効期間] で、1 年以内の値を選択します。
- [保存] をクリックします。
gcloud
バックエンド サービスの場合は、--client-ttl フラグを指定して gcloud compute backend-services
create または gcloud compute backend-services
update コマンドを使用します。
バックエンド バケットの場合は、--client-ttl フラグを指定して gcloud compute backend-buckets
create または gcloud compute backend-buckets
update コマンドを使用します。
gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
--client-ttl=CLIENT_TTL
gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
--client-ttl=CLIENT_TTL
CLIENT_TTL を 31,622,400 秒（1 年間）以下の値に置き換えます。
API
バックエンド バケットの場合は、Method: backendBuckets.insert または Method: backendBuckets.update API 呼び出しを使用します。
バックエンド サービスの場合は、Method: backendServices.insert または Method: backendServices.update API 呼び出しを使用します。
次のいずれかの API 呼び出しを使用します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
JSON リクエストの本文に次のスニペットを追加します。
"cdnPolicy": {
"clientTtl": CLIENT_TTL
}
CLIENT_TTL を 31,622,400 秒（1 年間）以下の値に置き換えます。
複雑な URL パスに基づいてオーバーライドする
TTL は、複雑な URL パスやサフィックス（ファイル拡張子）に基づいて微調整できます。TTL を構成するには、グローバル外部 HTTP(S) ロードバランサの柔軟なパターン マッチング演算子と routeRules 内の変数を使用します。
次の routeRules のサンプルは、ウェブサービスで動画に使用するファイルの TTL を微調整する方法を示しています。routeRules セクションは、動画プレイリスト マニフェストのリクエストをパッケージャ バックエンドに送信し、短い TTL を適用するように構成されています。同様に、動画セグメントは Cloud Storage バックエンドを使用し、より長い TTL を適用するように構成されています。
- description: "manifest routing"
matchRules:
- pathTemplate: "/videos/**.m3u8"
pathTemplate: "/videos/**.mpd"
service: packager-lb
priority: 1
routeAction:
corsPolicy:
maxAge: 300
allowOrigins: ["https://video.example.com"]
cdnPolicy:
cacheMode: "CACHE_ALL_STATIC"
defaultTtl: 6s
- description: "segment routing"
matchRules:
- pathTemplate: "/videos/**.m4s"
pathTemplate: "/videos/**.ts"
service: storage-bucket
priority: 2
routeAction:
cdnPolicy:
cacheMode: "FORCE_CACHE_ALL"
defaultTtl: 86400s
- description: "fallback route"
matchRules:
- prefixMatch: "/"
service: api-vm-group
priority: 3
ワイルドカードと構文の詳細については、ルートルールのパス テンプレートのワイルドカードとパターン マッチング演算子をご覧ください。
次のステップ
- 古いコンテンツを配信するで、古いコンテンツを配信する理由を確認する。