Cloud CDN（コンテンツ配信ネットワーク）は、Google のグローバル エッジ ネットワークを使用して、ユーザーの近くからコンテンツを配信します。これにより、ウェブサイトとアプリケーションが高速化されます。
Cloud CDN は、外部 HTTP(S) 負荷分散と連携してユーザーにコンテンツを配信します。外部 HTTP(S) ロードバランサが、リクエストを受信するフロントエンド IP アドレスとポート、そしてリクエストに応答するバックエンドを提供します。
Cloud CDN コンテンツは、次のようにさまざまな種類のバックエンドから提供されます。
- インスタンス グループ
- ゾーン ネットワーク エンドポイント グループ（NEG）
- サーバーレス NEG: 1 つ以上の App Engine、Cloud Run、Cloud Functions サービス
- 外部バックエンドのインターネット NEG
- Cloud Storage のバケット
Cloud CDN では、こうしたバックエンドが「送信元サーバー」とも呼ばれます。次の図は、VM インスタンス上で稼働している送信元サーバーからのレスポンスがどのように HTTP(S) ロードバランサを通過して Cloud CDN によって配信されるかを示しています。
Cloud CDN の仕組み
ユーザーが外部 HTTP(S) ロードバランサに対してコンテンツをリクエストすると、そのリクエストは、Google のネットワークのエッジの中でユーザーに最も近いエッジにある Google Front End（GFE）に到着します。
ロードバランサの URL マップが Cloud CDN が構成されたバックエンド サービスまたはバックエンド バケットにトラフィックをルーティングする場合、GFE は Cloud CDN を使用します。
キャッシュ ヒットとキャッシュミス
キャッシュは、コンテンツを保存および管理するサーバーのグループであり、対象コンテンツに対する将来のリクエストを高速で処理できるようにします。キャッシュに保存されたコンテンツは、送信元サーバーに保存されているキャッシュ可能なコンテンツのコピーです。
GFE は Cloud CDN のキャッシュを検索し、ユーザーのリクエストに対するレスポンスを見つけると、キャッシュに保存されているそのレスポンスをユーザーに送信します。これは「キャッシュ ヒット」と呼ばれます。キャッシュ ヒットが発生すると、GFE がそのキャッシュキーを基準にコンテンツを検索してユーザーにレスポンスを直接返すので、ラウンド トリップ時間が短くなり、配信元サーバーがリクエストを処理する必要もなくなります。
コンテンツが初めてリクエストされたとき、GFE はキャッシュからリクエストを処理できないと判断します。これは、「キャッシュミス」と呼ばれます。キャッシュミスが発生すると、GFE は近くにあるキャッシュからコンテンツを取得しようとします。この他のキャッシュにコンテンツが保存されている場合、2 番目のキャッシュの GFE は、キャッシュ間のフィルを使用して最初のキャッシュにコンテンツを送信します。そうでない場合、2 番目のキャッシュの GFE が、リクエストを外部 HTTP(S) ロードバランサに転送します。その後、ロードバランサはいずれかの送信元サーバーにリクエストを転送します。キャッシュでコンテンツが受信されると、コンテンツが GFE によってユーザーに転送されます。
次の図は、キャッシュ ヒットとキャッシュミスを示しています。
- VM インスタンス上で稼働している配信元サーバーが、HTTP(S) レスポンスを送信します。
- 外部 HTTP(S) ロードバランサが、レスポンスを Cloud CDN に配信します。
- Cloud CDN が、レスポンスをエンドユーザーに配信します。
キャッシュ下り（外向き）とキャッシュ フィル
このリクエストに対する配信元サーバーのレスポンスがキャッシュ可能な場合、Cloud CDN は以降のリクエストに備えてレスポンスを Cloud CDN キャッシュに保存します。
キャッシュからクライアントへのデータ転送は「キャッシュ下り」と呼ばれます。キャッシュへのデータ転送を「キャッシュ フィル」といいます。次の図に示すように、キャッシュ フィルの送信元は別の Cloud CDN キャッシュである場合も、送信元サーバーである場合もあります。
キャッシュ ヒットの場合、キャッシュからの下り（外向き）帯域幅に対して課金されます。キャッシュミス（キャッシュ間フィルが発生したミスを含む）の場合、キャッシュ フィルの帯域幅に対しても課金されます。つまり、キャッシュ ヒットの費用はキャッシュミスより低くなります。詳しい料金情報については、料金をご覧ください。
URL リダイレクトなし
Cloud CDN は URL リダイレクトを行いません。Cloud CDN のキャッシュは GFE にあります。これは、次のことを意味します。
- Cloud CDN が有効であるかどうかにかかわらず、クライアントがリクエストする URL は同じ URL のままです。
- キャッシュ ヒットの有無にかかわらず、URL は同じ URL のままです。
キャッシュ ヒット率
「キャッシュ ヒット率」とは、リクエストされたオブジェクトがキャッシュから提供される回数の割合です。キャッシュ ヒット率が 60% の場合、リクエストされたオブジェクトがキャッシュから 60% の割合で提供され、送信元から 40% の割合で取得する必要があります。
キャッシュキーがキャッシュ ヒット率に与える影響については、キャッシュキーの使用をご覧ください。トラブルシューティング情報については、キャッシュ ヒット率が低いをご覧ください。
短期間のキャッシュ ヒット率を表示する
短期間（最後の数分）のキャッシュ ヒット率を表示するには:
Google Cloud Console で、[Cloud CDN] ページに移動します。
それぞれの送信元について、キャッシュ ヒット率列を確認します。
n/a は、負荷分散されたコンテンツがキャッシュ内に存在しないか、最近リクエストされていないことを意味します。
長期間のキャッシュ ヒット率を表示する
1 時間から 30 日間のキャッシュ ヒット率を表示するには:
- Google Cloud Console で、[Cloud CDN] ページに移動します。
- [関連付けられているロードバランサ] 列で、ロードバランサの名前をクリックします。
- [モニタリング] タブをクリックします。
- 特定のバックエンドを選択します。
- 時間を選択します。
- ヒット率が n/a でない場合、[モニタリング] タブの下部にキャッシュ ヒット率が表示されます。
キャッシュへのコンテンツの挿入
あるオブジェクトが特定のキャッシュに保存されるのは、リクエストがそのキャッシュを通過し、しかもそのリクエストに対するレスポンスがキャッシュ可能な場合だけです。つまりキャッシュへの保存は事後対応型の操作です。キャッシュに保存されたオブジェクトが他のキャッシュに自動的に複製されることはありません。キャッシュ フィルは、クライアントが開始したリクエストに応じて実行されます。キャッシュに事前に読み込むには、個々のキャッシュでリクエストに応答するしか方法はありません。
送信元サーバーがバイト範囲リクエストをサポートしている場合は、Cloud CDN が単一のクライアント リクエストに対して複数のキャッシュ フィル リクエストを開始することがあります。
キャッシュからのコンテンツの配信
Cloud CDN を有効にすると、キャッシュ可能なすべてのコンテンツが自動的にキャッシュに保存されます。送信元サーバーは HTTP ヘッダーを使用して、どのレスポンスをキャッシュに保存するかを指示します。また、キャッシュ モードを使用してキャッシュへの保存を制御することもできます。
バックエンド バケットを使用する場合の送信元サーバーは Cloud Storage です。VM インスタンスを使用する場合の送信元サーバーは、それらのインスタンスで実行しているウェブサーバー ソフトウェアです。
Cloud CDN は、世界各地のロケーションにあるキャッシュを使用します。キャッシュの特性上、特定のリクエストに対するレスポンスがキャッシュから返されるかどうかを予測することはできません。ただし、キャッシュ可能なコンテンツに対するリクエストが多い場合、通常はそのリクエストに対するレスポンスがキャッシュから返されるはずなので、レイテンシの大幅な短縮、コストの削減、送信元サーバーの負荷の軽減が期待されます。
Cloud CDN がキャッシュに保存するコンテンツと保存期間について詳しくは、キャッシュの概要をご覧ください。
Cloud CDN がキャッシュから配信している内容を確認するには、ログを表示します。
キャッシュからコンテンツを削除する
キャッシュからアイテムを削除するには、キャッシュに保存されたコンテンツを無効にします。詳細については、次の情報をご覧ください。
キャッシュ バイパス
Cloud CDN をバイパスするには、Cloud Storage バケットまたは Compute Engine VM に対してオブジェクトを直接リクエストします。たとえば、Cloud Storage バケット オブジェクトの URL は次のようになります。
https://storage.googleapis.com/STORAGE_BUCKET/FILENAME
エビクションと有効期限
コンテンツをキャッシュから配信するには、コンテンツをキャッシュに保存し、コンテンツの削除や期限切れを防ぐ必要があります。
エビクションと有効期限は異なるコンセプトです。このどちらも、何が配信されるかに影響を与えますが、相互に直接影響を与えることはありません。
エビクション
各キャッシュに保存されるコンテンツの量には上限があります。ただし Cloud CDN は、キャッシュがいっぱいになった後もコンテンツを追加します。保存量の上限に達しているキャッシュにコンテンツを挿入するには、まずスペース確保のために他のいずれかのコンテンツが削除されます。この処理はエビクションと呼ばれます。キャッシュはいっぱいになることが多いので、コンテンツのエビクションも常に行われます。通常、コンテンツの有効期限に関係なく、最近アクセスされていないコンテンツが削除されます。削除されるコンテンツは期限切れの場合もあれば、そうでない場合もあります。有効期限を設定してもエビクションに影響はありません。
人気のないコンテンツとは、しばらくアクセスされていないコンテンツのことです。「しばらく」と「人気のない」は、どちらもキャッシュ内の他のアイテムと比較した場合の相対的な基準です。キャッシュに送信されるトラフィックが増加すると、エビクションで削除されるコンテンツも増加します。
サイズの大きなキャッシュの場合と同様に、コンテンツのエビクションは予測不能であり、リクエストがキャッシュから提供される保証はありません。
有効期限
HTTP(S) キャッシュ内のコンテンツの有効期限を設定できます。有効期限により、エビクションでまだ削除されていないとしても、古いコンテンツはキャッシュから提供されなくなります。
たとえば、撮影されて 1 時間以内の写真を保存する URL の場合、レスポンスの有効期限を 1 時間以内に設定します。こうしないと、古い写真がキャッシュから提供される可能性があります。
有効期限の微調整については、TTL の設定とオーバーライドの使用をご覧ください。
Cloud CDN によって作成されるリクエスト
送信元サーバーがバイト範囲リクエストをサポートしている場合、単一のクライアント リクエストに対して Cloud CDN から複数のリクエストが送信元サーバーに送信されることがあります。バイト範囲リクエストのサポートで説明しているように、Cloud CDN が開始できるリクエストには検証リクエストとバイト範囲リクエストの 2 種類があります。
他の Cloud Platform サービスのデータ ロケーションの設定
Cloud CDN を使用すると、送信元サーバーのリージョンやゾーンとは別のロケーションにデータが保存される可能性があります。これは正常な状態であり、HTTP キャッシュはこのようにしてインターネット上で機能します。Google Cloud Platform 利用規約のサービス固有の規約により、他の Google プロダクトやサービス（この場合は Cloud CDN サービス）と併用される場合、特定の Cloud Platform サービスで使用可能なデータ ロケーションの設定は、それぞれの Cloud Platform サービスの主なお客様データに適用されません。この条件に承諾できない場合には、Cloud CDN サービスを使用しないでください。
Google マネージド SSL 証明書のサポート
Cloud CDN が有効になっている場合は、Google マネージド証明書を使用できます。
Google Cloud Armor と Cloud CDN
Google Cloud Armor と Cloud CDN には、2 種類のセキュリティ ポリシーがあります。
- Edge のセキュリティ ポリシー。これらのポリシーは、Cloud CDN 対応の配信元サーバーに適用できます。CDN ルックアップ前のすべてのトラフィックに適用されます。
- バックエンド セキュリティ ポリシー。これらのポリシーは、動的コンテンツやキャッシュミスに対するリクエスト、または送信元サーバーを宛先とするその他のリクエストにのみ適用されます。
詳細については、Google Cloud Armor のドキュメントをご覧ください。
次のステップ
- HTTP(S) 負荷分散および負荷分散インスタンス用に Cloud CDN を有効にするには、Cloud CDN の使用をご覧ください。
- Cloud CDN を Google Kubernetes Engine と併用するには、Ingress による Cloud CDN の構成をご覧ください。
- GFE の接続拠点を確認するには、キャッシュのロケーションをご覧ください。