CDN キャッシュは『更新フロー』が決め手
基本的なキャッシュは多くのチームが使えるが、即時更新・タグベースパージ等の高度な運用で差がつきます。本記事では編集部の視点で、深掘りした使い方を公開情報をもとに整理します。CDN/Edge 実践 もご参考に。
Surrogate Key (Tag-based パージ)
(1) レスポンスヘッダにタグ付与。(2) 1リクエストで関連キャッシュ全パージ。(3) Fastly/Cloudflare 対応。(4) 例：user-123, product-456 等。(5) 大規模サイトで威力。記事更新→関連リスト全パージが一発で。
Stale While Revalidate (SWR)
(1) 古いコンテンツも提供しつつバックグラウンド更新。(2) レスポンス時間ゼロに近い。(3) Cache-Control: stale-while-revalidate=86400。(4) Cloudflare/Vercel 対応。(5) 急なトラフィック対応。コンテンツ更新フローと整合確認必須。
Stale If Error
(1) Origin 障害時に古いコンテンツ返却。(2) SLA 向上。(3) Cache-Control: stale-if-error=86400。(4) SWR と併用可能。(5) ユーザー体験を守る最後の砦。バックアップ&DR もご参考に。
キャッシュキーの設計
(1) URL + クエリ + Cookie + 一部Header。(2) Vary ヘッダ：複数バリアント。(3) カスタムキャッシュキー：Cloudflare 等。(4) ユーザー識別を含めるか。(5) cardinality 管理：爆発回避。
パージ戦略
(1) URL パージ：個別。(2) Tag (Surrogate Key)：関連一括。(3) Full purge：緊急時のみ。(4) 非同期パージ：API 経由。(5) CMS ライフサイクル統合。Webhook 設計 もご参考に。
Edge 側の演算
(1) Cloudflare Workers：エッジで動的処理。(2) Vercel Edge Functions。(3) 地域別レスポンス。(4) A/Bテスト：エッジで分岐。(5) 認証：エッジで簡易検証。サーバーレス実践 もご参考に。
失敗しがちなパターン
(1) キャッシュキー過剰：HIT 率低下。(2) 古いコンテンツ放置：パージ未整備。(3) 個人情報キャッシュ。(4) cache miss storm：同時 origin 攻撃。(5) SWR 期間設定ミス。対策は、(1)cardinality 管理、(2)Surrogate Key、(3)private 指定、(4)edge dedupe、(5)用途別に短中長、です。