なぜGoogleのCDNは「速い」のか？―HTTP(S)ロードバランサーとCloud CDNの密接な関係
インフラエンジニアとして現場に立っていると、「キャッシュが効かない」「エッジで謎の挙動をする」といったトラブルに頭を抱えることが一度はあるはずです。特にGCPのCloud CDNは、単なるWebサーバーのフロントに置くプロキシとは一線を画す、Googleの巨大なグローバルネットワークと完全に一体化したシステムです。
今回は、Cloud CDNが外部HTTP(S)ロードバランサー（以下、GCLB）といかにして「密結合」し、あなたのオリジンサーバーをトラフィックの嵐から守っているのか、その深淵を紐解いていきましょう。
—
1. Cloud CDNとGCLBの「不可分な関係」
多くの初心者が誤解しがちなのは、CDNを「ロードバランサーの前に置く別個の箱」だと捉えてしまうことです。しかし、GCPにおいてCloud CDNは、GCLBという巨大なコンポーネントの一部として実装されています。
アーキテクチャの核心
GCLBは、Googleの「フロントエンド（GFE）」と呼ばれる、世界中に散らばる数千のノードで構成されています。Cloud CDNを有効にするということは、GFEに対して「キャッシュせよ」という命令を出すことに他なりません。
1. ユーザーのパケットが最短のGFEに到達
2. GFEがキャッシュの有無を判定
3. ヒットすればそのまま即時返却（オリジン到達せず）
4. ミスすればGCPの高速なプライベートバックボーン網を通ってオリジンへ
この「エッジでの判定」が、物理的な距離をゼロにする魔法の正体です。
—
2. 実践：CDNのキャッシュ挙動をデバッグする
「CDNが効いているか」を判断する際、ブラウザのデベロッパーツールで X-Cache ヘッダーを見るのは基本中の基本です。しかし、CLIで叩くときはもっと正確に情報が見えます。
以下のコマンドを叩いてみてください。
# -I はヘッダーのみを取得、-v で詳細なやり取りを表示
curl -I -v https://your-app.example.com/api/v1/resourceここで注目すべきは Via ヘッダーと Cache-Control です。もし、あなたがキャッシュをコントロールしたい場合、バックエンドのアプリケーションコードで以下のようにヘッダーを制御する必要があります。
Python (FastAPI/Flask) でのキャッシュ制御例
from fastapi import Response
@app.get("/api/v1/resource")
def get_resource():
# 3600秒(1時間)キャッシュさせる指示を出す
# public: CDNもブラウザもキャッシュOK
# s-maxage: CDN（共有キャッシュ）の有効期限
headers = {
"Cache-Control": "public, max-age=60, s-maxage=3600",
"Vary": "Accept-Encoding" # コンテンツ圧縮を考慮してVaryを設定
}
return Response(content="Data", headers=headers)実務のTips:
Vary ヘッダーを軽視してはいけません。Accept-Encoding を忘れると、Gzip非対応のブラウザに圧縮済みのデータがキャッシュされて戻る、といった事故が発生します。
—
3. キャッシュヒットを最大化するための「罠」
実務で最も多い障害は「キャッシュが効かない（キャッシュミスが多すぎる）」というものです。以下のチェックリストを常に意識してください。
① 認証ヘッダーの扱い
Authorization ヘッダーや Set-Cookie が含まれるリクエストは、セキュリティ上の理由からデフォルトではキャッシュされません。APIでCDNを使いたい場合は、Cache-Key のカスタマイズが必要です。
② クエリパラメータの正規化
?utm_source=google のようなパラメータが毎回変わると、CDNは「別のリソース」と見なしてキャッシュを破棄します。Cloud CDNの設定で「クエリ文字列を含めるか否か」を選択できますが、API設計時には必要なパラメータのみに絞る設計が求められます。
③ インバリデーション（キャッシュ削除）
デプロイ後に古いJS/CSSが残ってしまうことはよくあります。Cloud CDNでは、パスを指定した無効化リクエストが可能です。
# gcloudコマンドで特定のキャッシュをパージする
gcloud compute url-maps invalidate-cdn-cache [LOAD_BALANCER_NAME] \
--path "/static/*" \
--global—
4. SRE視点での「守り」の設計
Cloud CDNを入れる真の目的は、「爆速化」だけではありません。オリジンサーバーをDDoSや突発的なバーストから保護することです。
- Negative Caching: 404エラーも一定時間キャッシュさせることで、攻撃者が存在しないパスを乱打してオリジンのCPUを枯渇させる手法を防げます。
- Stale-while-revalidate: キャッシュの有効期限が切れた際、古いデータを返しつつ裏で新しいデータを取得する挙動。これを設定しておくと、オリジンの応答が多少遅延しても、ユーザーには常に高速なレスポンスを提供できます。
—
最後に：クラウドの「中身」を知るということ
Cloud CDNは魔法の箱ではなく、Googleのエンジニアたちが数十年かけて作り上げた「世界最大級のキャッシュネットワーク」の末端を、私たちが少しだけ利用させてもらっているに過ぎません。
「とりあえずCDNをONにする」のではなく、HTTPのRFC（特にキャッシュ関連）を理解し、パケットがどのヘッダーを携えてエッジを通過しているのかを想像しながら設計してください。そうすれば、あなたのインフラはもっと強固で、そして誰よりも速いものになるはずです。
何かトラブルがあれば、まずは curl -v を叩くところから。現場からは以上です。
コメント