LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

CDNキャッシュ戦略とは何か

CDNキャッシュ戦略とは、配信コンテンツの種類ごとにCache-Controlヘッダーの値・キャッシュキーの構成・無効化の手順を定め、CDNエッジでのキャッシュヒット率を高めながら配信性能とオリジンの負荷を最適に保つ設計方針を指します^*1。表面的にはTTL（Time To Live、キャッシュが有効な期間）の数値を決めるだけに見えますが、実際にはヘッダー設計・キャッシュキー設計・無効化運用の3点をセットで詰める必要があります。

この記事は、Amazon CloudFront・Fastly・Cloudflareなど主要CDNに共通する設計の考え方を、特定ベンダーの機能に偏らず整理する構成です。CDNのコスト最適化そのものではなく、配信性能に直結するキャッシュヒット率の設計・改善に焦点を当てます。

Cache-Control・max-age・s-maxageの役割分担

CDNキャッシュ戦略の起点になるのは、オリジンが返すCache-Controlヘッダーです。MDN Web Docsによると、max-age指令は「レスポンスが生成されてからN秒後まで鮮度が保たれる」ことを示す値であり^*1、ブラウザのプライベートキャッシュとCDNなどの共有キャッシュの双方に適用されます。

一方でs-maxage指令は、共有キャッシュでの鮮度保持期間を個別に指定するものです。MDNの定義では「s-maxageディレクティブはプライベートキャッシュでは無視され、共有キャッシュに対してはmax-ageディレクティブやExpiresヘッダーの値より優先される」とされています^*1。つまりブラウザには短いmax-ageで最新性を保たせつつ、CDN側だけ長いs-maxageで長くキャッシュさせる、といった役割分担が可能です。

no-cache指令も誤解されやすい指令です。MDNは「no-cacheはキャッシュに保存すること自体は許すが、再利用の前にオリジンでの検証を要求する」と説明しており^*1、「キャッシュしない」という意味ではありません。完全にキャッシュを禁止したい場合はno-storeを使う必要があります^*1。個人情報を含むレスポンスにはprivate指令を付け、共有キャッシュに乗らないようにする設計が基本です^*1。

さらにstale-while-revalidate指令を使うと、鮮度切れ後もキャッシュが古い応答を返しつつ裏側で再検証を進められます^*1。Fastlyのドキュメントでも同指令をCache-Controlまたは専用のSurrogate-Controlヘッダーから読み取ると説明されており^*2、CDNごとに解釈の優先順位に差があるため、複数CDNを跨ぐ場合はヘッダー設計の統一が欠かせません。

キャッシュキー設計がヒット率を左右する仕組み

キャッシュヒット率を大きく左右するのが、キャッシュキー（cache key）の設計です。キャッシュキーとは、CDNがキャッシュ内のオブジェクトを一意に識別するための識別子であり、同一のキーが生成されたリクエストはキャッシュヒットとして扱われます^*3。

AWS公式ドキュメントによると、CloudFrontのデフォルトのキャッシュキーには「ディストリビューションのドメイン名」と「リクエストされたオブジェクトのURLパス」だけが含まれ、クエリ文字列・Cookie・User-Agentなどのヘッダーはデフォルトでは含まれません^*3。つまりクエリ文字列やCookieが異なっていても、パスが同じであればキャッシュヒットになるということです。

キャッシュキーに含める値は、CloudFrontではキャッシュポリシーで変更できます^*3。ここで注意すべきは、キーに含める値を増やすほど、レスポンスの正確性は上がる一方でオブジェクトの重複が増え、ヒット率が下がりやすくなる点です。公式ドキュメントは「User-Agentヘッダーは数千通りのバリエーションがあり得るため、キャッシュキーに含める候補としては一般的に適さない」と明記しています^*3。同様に、セッション固有の値を持つCookieをキーに含めると、ユーザーごとにキャッシュが分裂してしまいます^*3。

実務では「オリジンが返すレスポンスを変化させる値だけをキーに含める」という原則が有効です^*3。分析用のトラッキングパラメータやリファラーなど、レスポンス内容に影響しない値は、キャッシュキーではなくオリジンリクエストポリシー（オリジンへの転送のみを許可する設定）側で処理するという整理がAWSのガイドでも推奨されています^*3。

オリジンシールドで実現する原点負荷の軽減

キャッシュミス時に発生するオリジンへの同時多発リクエストを抑える仕組みが、オリジンシールド（origin shield）です。AWSの説明では、オリジンシールドは「CloudFrontのキャッシュ階層に追加される層で、オリジンの負荷を最小化し、可用性を高め、運用コストを低減する」機能とされています^*4。

具体的には、複数の地域にまたがるリージョナルエッジキャッシュからのリクエストを1か所に集約することで、同一オブジェクトへのリクエストが重複してオリジンに届く事態を防ぎます^*4。AWS公式は「オリジンシールドを使うと、オブジェクトごとにオリジンシールドからオリジンへの単一のリクエストで取得できる」と説明しており^*4、ピーク時のオリジン保護に有効です。

一方でオリジンシールドの適用が向かないケースも明記されています。AWSは「動的コンテンツがオリジンにプロキシされる場合や、キャッシュ可能性が低いコンテンツ、リクエスト頻度が低いコンテンツには適さない場合がある」と述べています^*4。オリジンシールドはリージョン単位で有効化するため、オリジンとの通信距離が短いリージョンを選ぶ必要があり^*4、設計時にはオリジンの物理的な設置場所とあわせて検討することになります。

Fastlyなど他のCDNにも、同様に単一障害点を作らずミスを集約する仕組みが用意されています。CDNによって呼称や適用範囲が異なるため、導入時は各CDNの該当機能のドキュメントで挙動を確認する必要があります。

キャッシュ無効化（purge/invalidation）の設計

コンテンツを更新したのにキャッシュが古いままだと配信品質を損ないます。この課題に対応する手段が、キャッシュ無効化（invalidation、CDNによってはpurgeと呼ぶ）です。

AWSは、コンテンツを更新する手段として「エッジキャッシュからファイルを無効化する手段」と「別名のバージョン管理されたファイル名で異なるバージョンを配信する手段」の2つを挙げています^*5。さらに「頻繁にファイルを更新する場合は、主にファイルのバージョン管理を使うことを推奨する」としており^*5、その理由として「バージョン管理はファイルを無効化する場合に課金対象とならず、無効化よりコストを抑えられる」ことを挙げています^*5。無効化には課金が発生し得るため、更新頻度が高いファイルには最初からハッシュ付きファイル名などのバージョニングを組み込む設計が合理的です。

キャッシュキー設計と無効化設計は表裏一体です。キャッシュキーを細かくしすぎると、無効化時に対象となるバリエーションが増え、purgeの範囲指定が複雑になります。Cloudflareのドキュメントでは、URL単位のパージ（単一ファイルのパージ）が推奨方法とされ、それ以外にゾーン全体をパージするPurge Everything、タグ単位・ホスト名単位・プレフィックス単位のパージが用意されています^*6。プラン階層によってパージのリクエスト数の上限にも差があり^*6、更新頻度が高いサイトほど、どの単位でパージ運用を組むかを事前に設計しておく必要があります。

静的コンテンツと動的コンテンツの配信分離

ヒット率を高める最も基本的な設計は、静的コンテンツと動的コンテンツを配信経路の設計段階で分離することです。画像・CSS・JavaScript・PDFなどの静的コンテンツは、内容が変わらない限り長いTTLを設定しやすく、ヒット率の底上げに直結します。

これに対して、ログイン状態やユーザー属性で内容が変わる動的コンテンツは、そもそもキャッシュ対象にしない、あるいはprivate指令でブラウザのみに留める設計が基本です^*1。CloudFrontではオリジンやビヘイビア（パスパターンごとの配信設定）を分けることで、静的アセット用のキャッシュポリシーと、動的APIレスポンス用の短TTL設定を共存させられます^*3。

Fastlyの仕組みでも、キャッシュ可否を判断する既定のステータスコードが定められており、200・203・301・302・404・410といった特定のステータスコードのみが既定でキャッシュ対象になり、500系のエラーレスポンスはCache-Controlの値にかかわらずキャッシュされないとされています^*2。エラーレスポンスが誤ってキャッシュされ続ける事態を避けるうえで、この既定動作を理解しておくことが大切です。

設計を誤ると、動的コンテンツが意図せずキャッシュされ、別の閲覧者に他人の情報が表示されるリスクが生じます。逆に静的コンテンツをキャッシュ対象から外してしまうと、オリジンへのリクエストが増え、レイテンシとオリジン費用の双方が悪化します。この切り分けを最初の設計フェーズで固めておくことが、後工程の手直しを避ける近道です。

ヒット率の計測方法と改善の進め方

キャッシュヒット率とは、キャッシュ可能な全リクエストのうち、CDNがキャッシュから応答できた割合を指します。AWSはCloudFrontのCacheHitRateメトリクスを「キャッシュ可能な全リクエストのうち、CloudFrontがキャッシュからコンテンツを配信できた割合。POST・PUTリクエストやエラーはキャッシュ可能なリクエストに含めない」と定義しています^*7。このメトリクスは追加メトリクスの有効化が前提であり、既定では表示されない点に注意が必要です^*7。

ヒット率の改善は、闇雲にTTLを伸ばすだけでは進みません。まず現状のヒット率とミスの発生箇所を可視化し、どのパスパターン・どのコンテンツ種別でミスが集中しているかを特定する必要があります。ミスの内訳を見ずに全体のTTLだけ延ばすと、更新されたコンテンツが反映されないという別の問題を生みます。

改善の実務では、①キャッシュキーの見直し（不要な要素を除外）、②TTL・s-maxageの再設計、③オリジンシールドの導入検討、④静的/動的の配信分離の徹底、という順序で着手すると効果を測定しやすくなります。1つずつ変更してヒット率の変化を確認しないと、どの施策が効いたのかが分からなくなる点も見落としやすいところです。

キャッシュ戦略設計を外注する判断軸

ここまでの設計要素を内製で完結させるには、HTTPキャッシュの仕様理解に加え、CDNベンダーごとの実装差、アプリケーション側のヘッダー制御、監視基盤の構築といった複数領域の知識が要ります。目安として、キャッシュポリシー・オリジンシールド・purge運用の設計とオリジン側ヘッダー実装の調整に、インフラ担当者とアプリケーション担当者が並行して数週間規模の工数を要する場合があります。

キャッシュキー設計を誤ると、個人情報を含むレスポンスが共有キャッシュに乗り、他の閲覧者に配信されてしまうリスクがあります。逆にキャッシュキーを慎重にしすぎるとヒット率が上がらず、オリジン費用や配信遅延の改善効果が出ません。この両極のバランスを取るには、アプリケーションの挙動とHTTPキャッシュ仕様の両方を理解した設計者が必要です。

専門パートナーに依頼する場合は、既存のオリジン構成・アプリケーションのレスポンスヘッダー実装状況を把握した上で、キャッシュポリシー・purge運用・監視の3点セットを一括で設計します。内製で進める場合は、まずCache-Controlヘッダーの棚卸しとキャッシュキーの現状把握から始め、段階的にオリジンシールドやpurge運用の高度化に進む進め方が現実的です。専門的な設計支援を必要とする段階では、キャッシュ戦略の設計・実装・運用監視までを一括して支援できる体制を持つ外部パートナーの活用が、リスクを抑えながら改善を進める選択肢になります。

まとめ：CDNキャッシュ戦略設計の3つの判断軸

本稿では、CDNのキャッシュ戦略をCache-Control・キャッシュキー・無効化運用の3要素から整理しました。要点を3つに集約すると次のとおりです。第一に、max-ageとs-maxageの役割分担を理解し、ブラウザと共有キャッシュで異なる鮮度設定を行うことです。第二に、キャッシュキーに含める要素を必要最小限に絞り、ヒット率と個人情報保護の両立を図ることです。第三に、TTL設計だけでなくpurge運用とヒット率の計測体制まで含めて設計し、更新頻度の高いコンテンツにはバージョニングを併用することです。これら3点を押さえた上で、内製の工数とリスクを見極め、必要に応じて外部パートナーの支援を検討する進め方が、配信性能の改善を着実に前進させます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：MDN Web Docs「Cache-Control」
2. *2　出典：Fastly Documentation「Cache freshness」
3. *3　出典：Amazon Web Services「Understand the cache key」（Amazon CloudFront Developer Guide）
4. *4　出典：Amazon Web Services「Use Amazon CloudFront Origin Shield」（Amazon CloudFront Developer Guide）
5. *5　出典：Amazon Web Services「Invalidate files to remove content」（Amazon CloudFront Developer Guide）
6. *6　出典：Cloudflare, Inc.「Purge cache」（Cloudflare Developer Docs）
7. *7　出典：Amazon Web Services「Types of metrics for CloudFront」（Amazon CloudFront Developer Guide）

Tweet