TL

Cloud Service

Media CDN

大規模な動画・メディア配信を高いキャッシュ効率で実現する Media CDN。YouTube と同じグローバルエッジ基盤を使い、深いキャッシュ階層と豊富なエッジ機能でオリジン負荷と遅延を抑える。AWS の CloudFront 上位構成に相当。

中級パフォーマンス効率コスト最適化信頼性セキュリティ
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.YouTube と同じエッジ基盤を使う、大規模メディア配信特化の CDN。
  • 2.Network Services の EdgeCacheService として構成し、深いキャッシュ階層で高ヒット率を狙う。
  • 3.汎用の Cloud CDN と別製品。動画・ライブ・大容量配信に向く。

解決する課題

大量の同時視聴や大容量ファイルを、オリジンに負荷をかけずに低遅延で届けたい、というのが核心です。

  • 動画ストリーミング(VOD / ライブ)や大容量ダウンロードを 世界中へ低遅延で配信したい
  • 視聴の急増(人気コンテンツ・ライブイベント)でも オリジンを守りつつ高いキャッシュヒット率を保ちたい
  • エッジで トークン認証・リクエスト書き換え・ルーティングなどの処理をまとめて行いたい
  • Google のグローバルバックボーンと、YouTube 級のキャッシュ容量を持つエッジを使いたい

主要概念と用語

  • EdgeCacheService: Media CDN の中心リソース。ホスト名・ルーティング(パスマッチャ)・TLS などをまとめた配信の入れ物。Cloud CDN でいう外部 ALB 構成に相当する
  • EdgeCacheOrigin: オリジンの定義。Cloud Storage、GCE/GKE のバックエンド、あるいは任意の外部 HTTP オリジンを指定し、フェイルオーバ用のセカンダリオリジンも持てる
  • EdgeCacheKeyset: 署名付きリクエスト(短期トークン)の検証に使う公開鍵のセット。限定配信の鍵管理単位
  • ルート / パスマッチャ: ホストとパスに応じてオリジンやキャッシュ挙動を振り分けるルール。ヘッダ書き換えやリダイレクトもここで定義
  • キャッシュ階層(多段キャッシュ): 末端のエッジ PoP の内側に上位キャッシュを持つ深い階層構造。末端がミスしても上位でヒットすればオリジンに到達しない
  • キャッシュキー: キャッシュの一意性を決める要素。ホスト・パス・クエリ・指定ヘッダの含有可否を細かく制御できる
  • キャッシュモード / TTL: オリジンヘッダ準拠・強制キャッシュなどのモードと、保持時間(default / max / client TTL)の上書き
  • キャッシュ無効化(cache tag / パス): パスや キャッシュタグを指定して即時にキャッシュを破棄する操作。タグ単位の一括破棄に対応

仕様・制限・クォータ

  • 構成は **Network Services API(EdgeCacheService / EdgeCacheOrigin / EdgeCacheKeyset)**で行う。Cloud CDN のように外部 ALB のバックエンドへ機能を足すのではなく、独立したリソース群として定義する
  • HTTP/2・HTTP/3(QUIC)対応。大容量ファイルのレンジリクエストやレジューム可能なダウンロードに最適化されている
  • オリジンは Cloud Storage / GCE・GKE バックエンド / 任意の外部 HTTP オリジンを指定でき、セカンダリオリジンによるフェイルオーバを構成できる
  • キャッシュタグによる無効化に対応し、関連オブジェクトをまとめて破棄できる。無効化は全エッジへ伝播するまで時間がかかる
  • TLS は Google マネージド証明書またはセルフマネージド証明書を EdgeCacheService に設定する
  • リージョン・プロジェクト単位の各種**クォータ(サービス数・ルート数・無効化レートなど)**があり、大規模利用時は事前の上限緩和申請を検討する

内部の仕組み

ユーザーのリクエストは Anycast IP で最寄りのエッジ PoP に吸い込まれます。エッジにキャッシュがあれば即返し(キャッシュヒット)、無ければ上位のキャッシュ階層、最終的にオリジン(EdgeCacheOrigin)へ取りに行き(キャッシュフィル / オリジンフェッチ)、以後キャッシュします。Media CDN は YouTube 配信に使われるものと同じエッジ基盤の上に構築されており、非常に大きなキャッシュ容量と深い階層を持つのが特徴です。

  • 末端 PoP がミスしても 多段キャッシュの上位でヒットすればオリジンまで届かない。人気コンテンツほどオリジン負荷が下がり、ヒット率が上がる
  • レンジリクエストやキャッシュフィルは Google の プライベートバックボーン経由で行われ、パブリックインターネットの不安定さを避ける
  • ルーティングやヘッダ書き換え・トークン検証は エッジ側で実行されるため、オリジンに到達する前に認可・整形を済ませられる
Cloud CDN との一番の違い

Cloud CDN は外部 ALB に有効化する「機能」ですが、Media CDN は独立したリソース群として構成する「製品」です。深いキャッシュ階層と大きな容量により、動画やライブ、大容量配信で高いヒット率とスケールを狙えます。汎用 Web 配信は Cloud CDN、メディア特化は Media CDN と覚えると整理しやすいです。

設計パターン / ベストプラクティス

  • Cloud Storage をオリジンにした VOD 配信。セグメント(HLS / DASH)に長い TTL を付けてヒット率を最大化する
  • ライブ配信では マニフェストは短い TTL、セグメントは長い TTL と分けて、鮮度とヒット率を両立する
  • 限定配信は 署名付きリクエスト(短期トークン)+ EdgeCacheKeyset。鍵をローテーションし、トークンの有効期限は短く保つ
  • オリジンには セカンダリオリジンを設定してフェイルオーバ耐性を確保する
  • キャッシュキーから不要なクエリ・ヘッダを除外し、**キャッシュ分裂(ヒット率低下)**を防ぐ
  • デプロイ後の即時反映は無効化に頼らず、**ファイル名へのハッシュ付与(cache busting)**を基本とし、緊急時のみキャッシュタグ/パス無効化を使う

運用・監視

  • Cloud Monitoring / Cloud Logging で監視する。リクエストログに キャッシュヒット/ミス・ステータス・転送バイト数・オリジンフェッチなどが記録される
  • 主要指標: キャッシュヒット率、エッジ応答レイテンシ、オリジンフェッチ回数、4xx/5xx 率、キャッシュフィルのバイト数
  • ヒット率が低いときは、キャッシュキーへの不要なクエリ/ヘッダ混入、TTL の短さ、オリジンの Cache-ControlSet-Cookie でキャッシュ不可になっていないかを点検する
  • 無効化の実行状態や設定変更は API のオペレーション/監査ログで追跡する

コスト

Media CDN の料金は大きく キャッシュ egress(エッジ→ユーザー)キャッシュフィル(オリジン→エッジ)リクエスト数キャッシュ無効化に分かれます。送信先リージョンや帯域階層で単価が異なり、大規模・長期コミットでは割引が用意される場合があります。具体的な単価は変動するため、最新の公式料金で確認してください。

課金要素内容コスト最適化のポイント
キャッシュ egress(配信)エッジからユーザーへ転送した転送量(送信先リージョンで単価差)ヒット率を上げ、配信量そのものを抑える
キャッシュフィルオリジンからエッジへ取得した転送量TTL を適切に長くしフィル回数を減らす/多段キャッシュ活用
リクエスト処理したリクエスト数クエリ分裂を抑えてリクエストとフィルを削減
キャッシュ無効化無効化操作ごとに課金ハッシュ付きファイル名で無効化自体を避ける

オリジンが Cloud Storage / GCE の場合、エッジでヒットすればその分 オリジン側の egress コストも下がる点が効きます。

セキュリティ

  • HTTPS 強制: EdgeCacheService に TLS を設定し、Google マネージド証明書で運用する
  • 署名付きリクエスト(短期トークン)+ EdgeCacheKeyset で限定配信を実現する。鍵は keyset 単位で管理し、定期的にローテーションする
  • Cloud Armor を併用し、エッジ前段で L7 攻撃・地域/IP 制限・レート制限を防御する。L3/L4 の DDoS は Google のインフラ側で吸収される
  • Cloud Storage オリジンは 公開せず、必要範囲のみに IAM で限定する
アンチパターン

ユーザー固有・認証必須の応答に Cache-Control: public を付けたままキャッシュするのは重大事故のもとです。あるユーザー向けの応答が別ユーザーへ配信される情報漏洩につながります。ユーザー固有の応答には必ず Cache-Control: private(または no-store)を付け、キャッシュ対象から外してください。

関連サービス・比較

Media CDN は汎用 CDN の Cloud CDN とよく比較されます。どちらも Google のエッジで配信しますが、構成方法と最適化対象が異なります。

観点Media CDNCloud CDN
位置づけ独立リソース群(EdgeCacheService)外部 ALB に有効化する機能(--enable-cdn)
得意領域大規模メディア・動画・大容量配信汎用 Web の静的/動的配信
エッジ基盤YouTube と同じ大容量エッジGoogle のエッジ PoP
オリジン定義EdgeCacheOrigin(CS/バックエンド/外部)バックエンドサービス/バックエンドバケット
限定配信署名付きリクエスト+ EdgeCacheKeyset署名付き URL/署名付き Cookie
即時反映キャッシュタグ/パス無効化キャッシュ無効化
前段の WAF/DDoSCloud ArmorCloud Armor
使い分けの補足

動画ストリーミングや大容量配信で高いヒット率とスケールが要るなら Media CDN、Web サイトや API などの汎用配信なら Cloud CDN が基本です。両者は排他ではなく、用途ごとに使い分けられます。

ハンズオン / CLI例

# 1) オリジン(EdgeCacheOrigin)を作成。Cloud Storage バケットを指定
gcloud network-services edge-cache-origins create vod-origin \
  --origin-address=gs://my-media-bucket

# 2) EdgeCacheService を YAML で定義(ルーティングとキャッシュ挙動)
cat > media-service.yaml <<'EOF'
name: vod-service
routing:
  hostRules:
    - hosts:
        - media.example.com
      pathMatcher: main
  pathMatchers:
    - name: main
      routeRules:
        - priority: 1
          matchRules:
            - prefixMatch: /
          origin: vod-origin
          routeAction:
            cdnPolicy:
              cacheMode: CACHE_ALL_STATIC
              defaultTtl: 3600s
EOF

# 3) サービスを作成
gcloud network-services edge-cache-services import vod-service \
  --source=media-service.yaml

# 4) デプロイ後、キャッシュタグを指定して即時に無効化
gcloud network-services edge-cache-services invalidate-cache vod-service \
  --cache-tags=release-2026-06

# 5) サービス設定を確認
gcloud network-services edge-cache-services describe vod-service

Google Cloud Service

Media CDNを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

ネットワーキング

比較で見る軸

クラウド: Google Cloud / カテゴリ: ネットワーキング / 難易度: intermediate

導入後に効く点

Network Services の EdgeCacheService として構成し、深いキャッシュ階層で高ヒット率を狙う。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Google Cloud
カテゴリ
ネットワーキング
難易度
intermediate
関連資格
設計柱
performance / cost / reliability / security

判断チェックリスト

  • 自社の用途が「ネットワーキング / performance」に近いか確認する。
  • 強みである「YouTube と同じエッジ基盤を使う、大規模メディア配信特化の CDN。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

ネットワーキングperformancecostreliabilitysecurity