コンテンツ配信のベストプラクティス

このページでは、Cloud CDN でコンテンツ配信を最適化して時間短縮するためのベストプラクティスについて説明します。このセクションは、複数の主要分野に分かれています。

Cloud CDN は、キャッシュに保存可能なコンテンツの送信元として外部アプリケーションロードバランサを使用します。外部アプリケーションロードバランサは、1 つのグローバル IP アドレスを使用して、次のタイプのバックエンドからユーザーに静的コンテンツと動的コンテンツの組み合わせを配信できます。

インスタンスグループ
ゾーンネットワークエンドポイントグループ（NEG）
サーバーレス NEG: 1 つ以上の App Engine、Cloud Run、Cloud Run 関数サービス
外部バックエンドのインターネット NEG
Cloud Storage のバケット

Google Cloud とシームレスに統合されているので、Cloud CDN をデプロイしてコンテンツを管理する際にはいくつかの選択肢があります。デプロイを計画、調整する際には、ここに記載されているベストプラクティスに従ってください。詳細については、Cloud CDN を設定するをご覧ください。

キャッシュヒット率を最適化する

次のおすすめの方法は、キャッシュヒット率の最適化に役立ちます。

静的コンテンツをキャッシュに保存する

パフォーマンス改善のベストプラクティスとして Cloud CDN を有効にする場合は、アプリケーションに適したキャッシュモードを選択する必要があります。

キャッシュルールを管理する最も柔軟で一般的な方法は、キャッシュ制御ヘッダーを使用することです。送信元のキャッシュ制御ヘッダーの使用に慣れていない場合は、Cloud CDN が静的コンテンツを自動的にキャッシュに保存できるようにすることをおすすめします。

送信元からの静的レスポンスを自動的にキャッシュに保存するには、--cache-mode=CACHE_ALL_STATIC 設定を使用します（デフォルト）。この設定では、送信元がレスポンスヘッダーでキャッシュディレクティブを指定していない場合、Cloud CDN は一般的な静的コンテンツタイプをキャッシュに保存します。コンテンツがカテゴリに合うようにしてください。そうしないと、コンテンツはキャッシュに保存されません。

ユーザー固有のコンテンツをキャッシュしない

場合によっては、ブラウザがユーザー固有のコンテンツをキャッシュすることがあります。Cloud CDN を使用してユーザー固有のコンテンツをキャッシュしないでください。

カスタムキャッシュキーを使用してキャッシュヒット率を向上させる

パフォーマンスとスケーラビリティを向上させるには、キャッシュヒット率を最適化することが重要です。デフォルトの場合、Cloud CDN は完全なリクエスト URL を使用してキャッシュキーを構築します。キャッシュヒット率を最適化するには、カスタムキャッシュキーを使用して、Cloud CDN が不必要にキャッシュをシャーディングしないようにします。

カスタムキャッシュキーでは、プロトコル、ホスト、クエリ文字列を任意に組み合わせて追加することも、省略することもできます。カスタムキャッシュキーを使用するのは、次のような場合です。

2 つのホストが同じ IP アドレスに解決され、同じサービスに移動します。この例では、ウェブサイト全体が 2 つのホストで同じになります。デフォルトでは、Cloud CDN は HTTP リクエスト内の Host: ヘッダーが異なるため、2 つのコピーをキャッシュに保存します。カスタムキャッシュキーを使用すると、Cloud CDN がリクエストのホスト部分を無視してキャッシュエントリを共有できます。
より具体的な例として、異なるドメインに同じロゴを使用する 2 つのウェブサイトがあるとします。ウェブサイトのコンテンツは異なりますが、どちらのドメインでも会社の同じロゴを使用しており、共有コンテンツを保持する専用のバックエンドサービスを使用しています。ロゴを保持するバックエンドサービスの Cloud CDN を有効化してキャッシュキーをカスタマイズするとき、[ホスト] チェックボックスをオフにすると、キャッシュでドメインが無視されるようになりますが、ロゴはキャッシュに保存されます。
HTTP と HTTPS のどちらで表示されるかにかかわらず、ロゴはキャッシュに保存される必要があります。ロゴを保存するバックエンドサービスのキャッシュキーをカスタマイズするときに、[プロトコル] チェックボックスをオフにすると、HTTP と HTTPS によるリクエストがロゴのキャッシュエントリの一致としてカウントされるようになります。

キャッシュキーをカスタマイズする方法については、キャッシュキーの使用をご覧ください。

パフォーマンスの最適化

次のおすすめの方法は、パフォーマンスの最適化に役立ちます。

HTTP/3 と QUIC プロトコルのサポートを有効にする

HTTP/3 は次世代のインターネットプロトコルです。これは、元の Google QUIC（gQUIC）プロトコルから開発された、QUIC プロトコル上に構築されます。HTTP/3 は、外部 HTTP(S) ロードバランサ、Cloud CDN、クライアントの間でサポートされます。

Cloud CDN のパフォーマンスを向上させるには、必ず HTTP/3 を有効化します。

ネガティブキャッシュを使用する

ネガティブキャッシュにより、一般的なエラーやリダイレクトに対するキャッシュ保存を細かく制御できるようになります。Cloud CDN は、特定のレスポンスコードを検出すると、設定された TTL の間、そのレスポンスをキャッシュに保存します。これにより、オリジンの負荷を軽減し、レスポンスのレイテンシを短縮することで、エンドユーザーのエクスペリエンスを向上させることができます。

セキュリティを最適化する

次のおすすめの方法は、セキュリティの最適化に役立ちます。

Google Cloud Armor を使用する

Google Cloud Armor は Cloud CDN に統合されており、キャッシュに保存されたコンテンツとキャッシュに保存されていないコンテンツまたはキャッシュミスの両方に対して機能します。ウェブアプリケーションのセキュリティを強化するために、可能な限り Google Cloud Armor と Cloud CDN を組み合わせて使用することをおすすめします。

署名付き URL を使用する

署名付き URL を使用している場合は、次の点にご注意ください。

公開コンテンツと非公開コンテンツは別々の Cloud Storage バケットに保存する。
セキュリティのベストプラクティスに従う。

非公開の送信元認証

送信元の認証では、リクエストが、独自に構成されたバックエンドサービスからのみ送信されることが確実に保証されます。また、リクエストで転送中のデータも保護し、リクエストで署名された部分の再利用を防ぎます。

Amazon S3 バケットまたは互換性のあるオブジェクトストアには、非公開の送信元認証を使用することをおすすめします。非公開の送信元認証により、信頼できる接続のみが非公開の送信元のコンテンツにアクセスし、ユーザーはこのようなコンテンツに直接アクセスしないことが保証されます。

さらに、送信元のファイアウォールが送信元へのアクセスを妨げる場合は、IP 許可リストを使用して、リクエストが Cloud CDN または外部アプリケーションロードバランサから送信されるようにします。ただし、他のメディア CDN のユーザーが構成内の送信元を指定してコンテンツにアクセスすることは防止できません。

キャッシュを最適化する

次のおすすめの方法は、キャッシュの最適化に役立ちます。

キャッシュ TTL を最適化する

TTL を設定またはオーバーライドすることで、Cloud CDN がレスポンスをキャッシュに保存する期間と、Cloud CDN がレスポンスを再検証するタイミングを微調整できます。

クライアント向け TTL を定義して、ブラウザキャッシュを最大限に活用することもできます。

詳細については、TTL の設定とオーバーライドを使用するをご覧ください。

時間的制約のあるコンテンツの有効期限を設定する

Cloud CDN キャッシュのコンテンツの各部分には有効期限が関連付けられており、実際の使用法に適した有効期限を設定することが重要です。配信元サーバーはキャッシュサーバーで期限切れになったコンテンツを再送する必要があるため、期限を慎重に選択する必要があります。

有効期限を選択する方法の 1 つは、コンテンツを更新する頻度に基づいてコンテンツを分類することです。たとえば、

ほぼリアルタイムの更新。スポーツイベントや交通情報のライブ配信など。
頻度の高い更新。毎週、毎日、または毎時の気象情報やトップニュースの画像など。
頻度の低い更新。ウェブサイトのロゴ、CSS、JavaScript のファイルなど。

次に、コンテンツカテゴリ別の有効期限を選択します。たとえば、ほぼリアルタイムのスポーツの得点情報の場合、5 秒の有効期限が適切でしょう。また、最新の天気予報に関する情報の場合、1 時間の有効期限が適切でしょう。Cloud Storage に保存されているコンテンツについては、Cache-Control メタデータを使用して有効期限を設定します。コンテンツが Compute Engine によって提供される場合、ウェブサーバーソフトウェアを構成することによって有効期限を制御します。

有効期限は、Cache-Control ヘッダーの max-age と s-maxage の値で指定します。このヘッダーは HTTP 仕様で定義されています。たとえば、次の Cache-Control ヘッダーは、キャッシュの有効期限 72 時間（259,200 秒）を使用して、関連付けられたコンテンツを一般公開して閲覧可能およびキャッシュ可能にします。

  Cache-Control: public, max-age=259200

キャッシングを最大にするには、キャッシングの概要のガイドラインに従います。Cache-Control メタデータフィールドの max-age と s-maxage の値は、次のように連携して動作することに注意してください。

max-age と s-maxage の値は秒単位です。
s-maxage の値は共有キャッシュにのみ適用され、ブラウザのキャッシュには適用されません。
max-age の値は、s-maxage によってオーバーライドされない限り、すべてのキャッシュに適用されます。

変更頻度の低いコンテンツや関連コンテンツとともに変更される必要のあるコンテンツについては、多くの場合、長い有効期限を URL バージョン管理と組み合わせて使用するのが適切です。

バージョニングされた URL を使用してコンテンツを更新する

コンテンツをバージョニングすると、同じコンテンツの異なるバージョンが提供されます。つまり、キャッシュエントリが期限切れになる前にユーザーに新しいコンテンツを表示して、実質的に古いコンテンツを削除します。バージョニングは無料なので、キャッシュ可能なコンテンツを更新するためのデフォルトの方法として使用することをおすすめします。

コンテンツをバージョン管理するには、バージョン番号などのパラメータを URL に追加します。URL にパラメータを含めるには、次のようなさまざまな方法があります。

クエリ文字列の追加: file.ext?v=100

バックエンドバケットの場合、バージョニングに使用されるクエリ文字列は、バックエンドバケットの構成で指定する必要があります。詳細については、Cloud Storage キャッシュキーのクエリ文字列の追加リストをご覧ください。
ファイル名の変更: file.1.0.0.ext または file_v100.ext
パス /v100/file.ext を変更します。

パラメータを追加すると、ファイル名と URL が変更されます。この変更により、キャッシュでは既存のキャッシュエントリが無視されるようになります。

無効化を控えめに使用したコンテンツの削除

無効化すると、キャッシュエントリが期限切れになる前に、Cloud CDN 分散キャッシュサーバーからコンテンツが削除されます。無効化には結果整合性があります。

無効化は控えめに、最後の手段としてのみ使用することをおすすめします。たとえば、法律上の理由や意図しないアップロードのためにコンテンツを削除する必要が生じた場合は、無効化が役立ちます。それ以外の場合は、可能な限りバージョン管理機能を使用するか、コンテンツが正常に期限切れになるまで待つことをおすすめします。Cloud CDN キャッシュサーバーは、アクセス頻度の低いコンテンツを定期的に削除して、新しいコンテンツのスペースを確保します。30 日間アクセスされなかったコンテンツは無条件で削除されます。

キャッシュの無効化にはレート制限があります。

無効化の詳細については、キャッシュ無効化の概要をご覧ください。

アップロードされたファイルの一貫性を最適化する

次のおすすめの方法は、ファイルのアップロードの整合性を最適化するために役立ちます。

既存のファイルの更新を回避する

既存のファイルを更新するのではなく、新しいバージョンをアップロードします。

新しいファイルには、バージョン番号や日付を含めることができる一意の名前を使用します。ファイル名にバージョン番号（file_v2.css など）または日付（file_20230806.js など）を追加すると、Cloud CDN が正しい更新されたバージョンをフェッチできます。ファイル URL にパラメータ（file.css?v=2 など）を追加して新しいバージョンを強制的に取得することはおすすめしません。この方法では、部分的なファイルや不完全なファイルがキャッシュに保存される可能性がある非アトミックな送信元ファイルの更新をキャッシュに保存するリスクに対処できないためです。

依存関係を参照するファイルをアップロードする前に、依存関係の新しいバージョンをアップロードすることが重要です。この方法により、すべての参照が完全な更新済みファイルに確実に設定されるため、部分的に更新されたファイルや切り捨てられたファイルが提供されるリスクを軽減できます。

ファイルにアトミック更新を行う

既存のファイルを更新する必要がある場合は、アトミックに更新します。

アップロードが完了する前にファイルにアクセスしてキャッシュに保存すると、不完全なファイルまたは切り捨てられたファイルとしてキャッシュに保存されることがあります。たとえば、/index.html などのファイルに一意の名前を付けることはできませんが、一意の名前を持つ他のファイルを参照することはできます。

ターゲット名でファイルをアップロードすると、アップロード中にアクセスされたときに、不完全なファイルがキャッシュに保存される可能性があります。代わりに、一時的な名前でファイルをアップロードし、アップロードが完了してからのみ、ターゲット名に名前を変更します。この方法により、参照時にファイルが完全に即座に使用可能になります。

既存のファイルが更新されると、バイト範囲のキャッシュにより、新しいファイルがアップロードされた後も Cloud CDN が以前のファイルの範囲を保持することがあります。Cloud CDN が以前のファイルの範囲をキャッシュに保存している場合、不足しているチャンクのリクエストにより、部分的なレスポンスが返される可能性があります。これは、Cloud CDN が送信元ファイルが変更されたことを検出（etag または last-modified が変更されたため）し、古いコンテンツを削除し、進行中のダウンロードを切断し、エラーを生成するため、クライアントに再試行を求めるためです。この問題を軽減するには、更新中のバイト範囲のキャッシュに保存されているファイルに対して無効化を行います。

モニタリングとロギングを最適化する

次のおすすめの方法は、モニタリングとロギングの最適化に役立ちます。

Cloud CDN のロギングを有効にする

Cloud CDN を管理するおすすめの方法は、すべての Cloud CDN 対応バックエンドに対して、ロギングを必ず有効にすることです。

Cloud CDN のカスタムモニタリングダッシュボードを使用する

高い信頼性とパフォーマンスを確保するため、Cloud CDN に関連するモニタリング指標を定期的に確認することをおすすめします。その出発点としては、Cloud CDN カスタムモニタリングダッシュボードが役に立ちます。

サードパーティのパフォーマンステストの結果を確認する

サードパーティプロバイダからのレポートを確認します。たとえば、Citrix Radar では可用性、レイテンシ、スループットのレポートを提供しています。

コンテンツ配信のベスト プラクティス

キャッシュ ヒット率を最適化する