GOOGLE CLOUD 実践 / 静的配信

GCS + Cloud CDN — 静的配信を API と同じ入口にまとめる

GCS をオリジン、Cloud Load Balancing と Cloud CDN を配信入口にすると、独自ドメイン・エッジキャッシュ・パスルーティングをひとつの構成で扱える。

TL;DR

GCS は静的ファイルの保管場所、Cloud CDN は利用者の近くで返すキャッシュ。
ロードバランサがパスに応じて GCS と Cloud Run を振り分ける。
更新時はキャッシュ制御を設計し、必要なときだけパージする。

01全体像 — 保存・振り分け・エッジ配信

外部 Application Load Balancer は URL map に従い、/static などを GCS backend bucket へ、それ以外を Cloud Run API へ渡せる。

全体像 — 保存・振り分け・エッジ配信 — /static は GCS バックエンドバケット、その他は Cloud Run にルーティングする。

一つの入口を役割で振り分ける

/static/*：CDN有効backend bucket — GCSの静的ファイル
/api/*：serverless NEG — Cloud Run API
URL map：最初に分岐 — 同一ドメインで役割分担

02キャッシュが効く場所

最初の取得は GCS まで進む。次回以降は利用者に近い CDN エッジが返すため、待ち時間とオリジンへのアクセスを減らす。

キャッシュが効く場所 — 初回は GCS、以後は近いエッジのキャッシュから返す流れ。

キャッシュヒットはオリジンを守る

初回：GCSオリジンまで取得 — キャッシュを保存
キャッシュヒット：近いエッジが返す — 低遅延・オリジン負荷減
失効後：オリジンから再取得 — 更新内容を反映

03更新を安全に届ける

内容ハッシュ付きのファイル名なら新旧を安全に共存でき、長いキャッシュを付けやすい。同名ファイルを急いで切り替える場合だけキャッシュパージを使う。

更新を安全に届ける — immutable なアセットと、必要時だけのキャッシュパージを説明する。

更新には2つの手札がある

ハッシュ付き名前：長いキャッシュ — 通常はこちらを使う
同名の緊急更新：キャッシュパージ — 限定して実施
HTMLなど参照元：短めのキャッシュ — 新アセットへ切り替える

結論

GCS は保存、Cloud CDN は配信最適化、GCLB は入口と振り分けを担当する。
静的コンテンツをアプリと同じドメインで安全に配信できる。
キャッシュは「速くする機能」ではなく、更新方法まで含めた設計対象。