どんな場面で検討するか
画像・教材・企業サイトを遠方から速く配信し、オリジンへの集中アクセスを減らしたい場合。API 等の入口にも使えるが、公開データと利用者固有のデータでキャッシュ方針を分ける必要がある。
組織で使う条件
キャッシュヒット・誤キャッシュ・エラー・オリジン到達を監視し、版付き資産の更新と切戻しを管理する。CDN のキャッシュが成功しても中身が最新とは限らない。 配信経路を通さないオリジンへの直接アクセス、Cookie・認証トークンのログ出力を確認する。公開 URL と機密経路を一覧で管理する。
採用前に試すこと
- 非公開オリジンから静的資産を配信し、初回と再取得のキャッシュ・ハッシュ・直接アクセスを確認する。
- A / B の注文 API と未認証要求を交互に送信し、キャッシュ無効化・認証情報の転送を試す。
- 版付き資産で更新と旧版への戻しを行い、地域・アクセス量・プラン別の費用を見積る。
合格と判断する条件
- 全資産のハッシュが一致し、2 回目の配信が設計したキャッシュ経路を通る。直接オリジンの許可範囲が想定どおり。
- 別利用者の注文が表示される事象が 0 件。未認証アクセスは拒否され、私的応答を共通キャッシュから返さない。
- 更新後の URL で新版ハッシュ、戻し後の URL で旧版ハッシュを確認でき、古いキャッシュを最新として表示しない。
見落としたくない点
- 利用者ごとに異なる機密応答を、共通キャッシュ設定のまま置かない。必要なら該当経路をキャッシュ対象から外し、別利用者間の混入試験を行う。 CloudFront の最小 TTL が 0 より大きいと、オリジンの no-cache・no-store・private 指示でもその間保存され得る。動的 API は転送・認証・キャッシュの仕様を確認してから採用する。
- 利用者ごとに異なる機密応答を、共通キャッシュ設定のまま置かない。必要なら該当経路をキャッシュ対象から外し、別利用者間の混入試験を行う。
- CloudFront の最小 TTL が 0 より大きいと、オリジンの no-cache・no-store・private 指示でもその間保存され得る。動的 API は転送・認証・キャッシュの仕様を確認してから採用する。
根拠となる資料
Low-Latency Content Delivery Network (CDN) – Amazon CloudFront