Cloud Service
Cloud CDN
Google のグローバルエッジでコンテンツをキャッシュ配信する CDN。外部 Application Load Balancer に紐づけて有効化し、低遅延・オリジン負荷削減を実現。AWS の Amazon CloudFront に相当。
- 1.Googleのエッジでキャッシュし、ユーザー近くから高速配信するCDN。
- 2.オリジンの負荷と下りコストを下げ、遅延とスパイクを吸収する。
- 3.独立製品ではなく外部ALBに--enable-cdnで有効化する機能。
解決する課題
物理的に遠いユーザーへも、オリジンに毎回アクセスさせずに高速配信できます。
- 遠いユーザーにも 低遅延でコンテンツを届けたい
- オリジン(Cloud Storage / GCE / GKE バックエンド)の 負荷と下り(egress)コストを下げたい
- 急なトラフィック増(スパイク)を エッジで吸収し、バックエンドを守りたい
- Google のグローバルネットワーク(プライベートバックボーン)で 安定した配信を行いたい
主要概念と用語
- 外部 Application Load Balancer(外部 ALB): Cloud CDN を有効化する前提となるグローバル L7 ロードバランサ。CloudFront の「ディストリビューション」に近い設定の入れ物
- バックエンドサービス / バックエンドバケット: オリジンの定義。
backend-services(GCE インスタンスグループ・NEG・ハイブリッド)とbackend-buckets(Cloud Storage バケット)があり、それぞれに--enable-cdnを付けてキャッシュを有効化 - エッジ(PoP / Point of Presence): Google が世界中に持つキャッシュ拠点。さらに内側に エッジキャッシュ階層(tiered/2 段キャッシュ) を持つ
- キャッシュモード:
CACHE_ALL_STATIC(静的のみ自動キャッシュ=既定)/USE_ORIGIN_HEADERS(オリジンのCache-Controlに従う)/FORCE_CACHE_ALL(応答コードに関わらず強制キャッシュ) - キャッシュキー: キャッシュの一意性を決める要素。プロトコル・ホスト・クエリ文字列・指定ヘッダ・Cookie の含有可否を
cache-key-policyで制御 - TTL(
default/max/clientTTL): キャッシュ保持時間。オリジンヘッダを上書き/クランプできる - キャッシュ無効化(Cache Invalidation): パスやホストを指定して即時にキャッシュを破棄する操作
- 署名付き URL / 署名付き Cookie: バックエンド単位の鍵で限定配信(CloudFront の署名付き URL/Cookie 相当)
- キャッシュフィル: エッジがオリジンから取得してキャッシュを埋める通信。Cache Fill 料金の対象
仕様・制限・クォータ
- 有効化には外部 ALB が必須。Cloud CDN 単体では使えず、必ずロードバランサのバックエンドに紐づける
- HTTP/2・HTTP/3(QUIC)対応、Gzip / Brotli の動的圧縮に対応
- TLS 証明書は Google マネージド証明書またはセルフマネージド証明書を ALB 側に設定(CloudFront のように特定リージョン固定の制約はない)
- キャッシュ可能なオブジェクトの最大サイズは既定で数 GB 規模(レンジリクエスト対応)。
Cache-Control: private/no-store/Set-Cookie付き応答は原則キャッシュ対象外 - キャッシュ無効化はパスパターン単位。1 回の無効化は最終的に全エッジへ伝播するまで数分かかる。プロジェクトあたりの無効化レートにはクォータがある
- ステータスコードのうち
200/203/204/206/300/301/308/404/405/410/421/451/501などが既定でキャッシュ可能
内部の仕組み
ユーザーのリクエストは、Google の Anycast IP によって最寄りのエッジ PoP に吸い込まれます。エッジにキャッシュがあれば即返し(キャッシュヒット)、無ければ上位のキャッシュ階層、最終的にオリジン(バックエンド)へ取りに行き(キャッシュフィル / オリジンフェッチ)、以後キャッシュします。キャッシュの単位は キャッシュキー(プロトコル・ホスト・パス・クエリ・ヘッダ等)で決まり、TTL の間は再利用されます。
- エッジ間は 2 段キャッシュ(tiered caching) になっており、末端 PoP がミスしても上位キャッシュでヒットすればオリジンまで到達しない。これによりオリジンの負荷とコールドキャッシュ時の遅延を抑える
- レンジリクエストやキャッシュフィルは Google のプライベートバックボーン経由で行われ、パブリックインターネットの不安定さを避ける
TTL が長いと古いまま配信され続けます。即時反映したいなら キャッシュ無効化(gcloud compute url-maps invalidate-cdn-cache)、または **ファイル名にハッシュを付けて別 URL にする(cache busting)**運用が定番。無効化は伝播に数分かかるため、頻繁な更新にはハッシュ運用の方が確実です。
設計パターン / ベストプラクティス
- バックエンドバケット(Cloud Storage)+ Cloud CDN で静的サイト/メディアを安全・安価に配信
- 静的アセットは
Cache-Control: public, max-age=...をオリジンで明示し、USE_ORIGIN_HEADERSモードで意図どおりに制御。動的 API はキャッシュしない(パス/ホストルールで分離) - ハッシュ付きファイル名(
app.[hash].js)+長いmax-ageで cache busting。無効化に頼らない - Cloud Armor(WAF)を同じ外部 ALB に適用し、エッジ前段で L7 攻撃・地域制限・レート制限を防御
- 限定配信は 署名付き URL / 署名付き Cookie(バックエンド単位の鍵)
- クエリ文字列を含めるかをキャッシュキーで厳選し、不要なパラメータでキャッシュが分裂(ヒット率低下)しないようにする
運用・監視
- Cloud Monitoring / Cloud Logging で監視。ロードバランサのログに
cacheHit(ヒット/ミス)・cacheLookupなどの CDN フィールドが記録される - 主要指標: キャッシュヒット率、エッジ応答レイテンシ、オリジンフェッチ回数、4xx/5xx、Cache Fill のバイト数
- ヒット率が低いときは、キャッシュキー(不要なクエリ/ヘッダの混入)、TTL の短さ、
Cache-Control/Set-Cookieでキャッシュ不可になっていないかを点検 - 無効化の実行履歴・状態は
gcloud compute url-maps describeや Cloud Logging の監査ログで追跡
コスト
Cloud CDN の料金は大きく キャッシュ egress(エッジ→ユーザー)・キャッシュフィル(オリジン→エッジ)・キャッシュ無効化/HTTP・HTTPS リクエストに分かれます。CloudFront と異なり恒常的な「無料 1TB」枠はなく、地域別の従量課金が基本です。
| 課金要素 | 内容 | コスト最適化のポイント |
|---|---|---|
| キャッシュ egress(配信) | エッジからユーザーへ転送した GB(送信先リージョンで単価が異なる) | ヒット率を上げ、配信そのものを圧縮で削減 |
| キャッシュフィル | オリジンからエッジへ取得した GB(リージョン内 < 大陸間 で単価差) | TTL を適切に長くしフィル回数を減らす/2段キャッシュ活用 |
| HTTP / HTTPS リクエスト | 処理したリクエスト数(10,000 件単位) | クエリ分裂を抑えてリクエスト/フィルを削減 |
| キャッシュ無効化 | 無効化リクエストごとに課金 | ハッシュ付きファイル名で無効化自体を避ける |
オリジンが Cloud Storage / GCE の場合、CDN でヒットすればその分 オリジン側の egress コストも下がる点が効きます。
セキュリティ
- HTTPS 強制: 外部 ALB に HTTP→HTTPS リダイレクトを設定し、TLS は Google マネージド証明書で運用
- 署名付き URL / 署名付き Cookie で限定配信。鍵はバックエンド(サービス/バケット)単位で管理し、有効期限を短く保つ
- Cloud Armor を同じ ALB に適用して DDoS(L3/L4 は Google のインフラ側で吸収)・L7 攻撃・地域/IP 制限・レート制限を実施
- Cloud Storage バックエンドは 公開せず、署名付き URL もしくは IAM で必要範囲のみに限定する
個人情報やユーザー固有の応答に、Cache-Control: public を付けたまま Cloud CDN でキャッシュするのは重大事故のもと。あるユーザー向けの応答が別ユーザーへ配信される「キャッシュポイズニング/情報漏洩」につながります。ユーザー固有・認証必須の応答には必ず Cache-Control: private(または no-store)を付け、キャッシュ対象から外すこと。
関連サービス・比較(AWS との対応)
Cloud CDN は機能的には Amazon CloudFront に対応しますが、「独立サービスか/ロードバランサの一機能か」という設計思想が大きく異なります。
| 観点 | Cloud CDN (GCP) | Amazon CloudFront (AWS) |
|---|---|---|
| 位置づけ | 外部 ALB に有効化する CDN 機能(--enable-cdn) | 独立した CDN(ディストリビューション) |
| オリジン定義 | バックエンドサービス / バックエンドバケット | オリジン(S3 / ALB / 任意 HTTP) |
| 静的オリジン安全公開 | バックエンドバケット + 署名付き URL / IAM | S3 + OAC(非公開のまま) |
| 限定配信 | 署名付き URL / 署名付き Cookie | 署名付き URL / 署名付き Cookie |
| 即時反映 | キャッシュ無効化(url-maps invalidate-cdn-cache) | Invalidation |
| 前段の WAF/DDoS | Cloud Armor | AWS WAF / Shield |
| エッジ処理 | 標準では軽量。高度な処理は Media CDN / 別途関数で | CloudFront Functions / Lambda@Edge |
| 証明書 | Google マネージド証明書(リージョン制約なし) | ACM 証明書(us-east-1 のものを使用) |
動画ストリーミングなど大規模メディア配信に最適化したい場合、GCP には Cloud CDN とは別に Media CDN(YouTube インフラ基盤)があります。Web/静的・動的配信の汎用は Cloud CDN、メディア配信特化は Media CDN、と覚えると整理しやすいです。
ハンズオン / CLI例
# 1) 静的サイト用に Cloud Storage バケットを CDN 有効のバックエンドバケットとして登録
gcloud compute backend-buckets create static-backend \
--gcs-bucket-name=my-static-assets-bucket \
--enable-cdn \
--cache-mode=CACHE_ALL_STATIC \
--default-ttl=3600 \
--max-ttl=86400
# 2) 既存のバックエンドサービス(GCE/GKE オリジン)で Cloud CDN を後から有効化
gcloud compute backend-services update web-backend \
--global \
--enable-cdn \
--cache-mode=USE_ORIGIN_HEADERS
# 3) キャッシュキーからクエリ文字列を除外してヒット率を上げる
gcloud compute backend-services update web-backend \
--global \
--no-cache-key-include-query-string
# 4) デプロイ後、最新を即反映(キャッシュ無効化)。url-map 名を指定
gcloud compute url-maps invalidate-cdn-cache my-url-map \
--path "/*"
# 5) バックエンドの CDN 設定を確認
gcloud compute backend-services describe web-backend \
--global \
--format="yaml(cdnPolicy, enableCDN)"
Google Cloud Service
Cloud CDNを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
ネットワーキング
比較で見る軸
クラウド: Google Cloud / カテゴリ: ネットワーキング / 難易度: intermediate
導入後に効く点
オリジンの負荷と下りコストを下げ、遅延とスパイクを吸収する。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- Google Cloud
- カテゴリ
- ネットワーキング
- 難易度
- intermediate
- 関連資格
- —
- 設計柱
- performance / cost / reliability / security
判断チェックリスト
- 自社の用途が「ネットワーキング / performance」に近いか確認する。
- 強みである「Googleのエッジでキャッシュし、ユーザー近くから高速配信するCDN。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
他クラウドの同等サービス
役割が近いサービスです。設計の置き換えや比較検討の参考に。