概要
- 表題の通りなのです。備忘のためと、私みたいに時間を無駄に溶かす人が一人でも少なくなれば良いと思うため記載する。
前提
- 記事内ではCloudfrontを用いて、S3に格納してあるindex.htmlを配信する例を用いて書いてある
- 署名付きURL配信やAPI Gatewayなどの異なるオリジンのを配信する場合は、本記事記載の内容が適切でない可能性がある
Cloudfrontのおさらい
キャッシュがヒットしない場合
- 下キャプチャの通り、キャッシュがヒットしない場合は、エッジサーバーを経由してS3があるオリジンサーバーまでリクエストが送信される。
- ヒットしない例
- 初回リクエスト時
- キャッシュの条件に一致していないなど
- ヒットしない例
キャッシュがヒットする場合
- キャッシュがヒットする場合は、エッジサーバーから応答が返る仕組み。(レイテンシーの低減が期待できる)
キャッシュがヒットしているかしていないか判断する方法
- ブラウザのネットワークタブを見ればわかる
-
X-Cache
の値がMiss from cloudfront
になっていたら、Cloudfrontがキャッシュとして保持していない(つまりキャッシュがヒットしていない)状態
-X-Cache
の値がHit from cloudfront
になっていたら、Cloudfrontがキャッシュとして保持している(つまりキャッシュがヒットしていいる)状態
-
- ヒットしていない
- ヒットしている
本題
- Cloudfrontは オリジンの内容が更新されたからといって、ホスト側かリクエストされた内容が同じだった場合、
X-Cache
の値がHit from cloudfront
となり、更新後のオリジンの内容がレスポンスされない可能性がある(Cloudfront側のキャッシュ設定とかにもよるかもしれない) - ただ、細かい話は一旦置いておき、もしオリジンの内容を更新してもCloudfrontで
X-Cache
の値がHit from cloudfront
となってしまい、キャッシュされた内容が返され続ける状況を抜けるための方法を記載する
Cloudfrontにてキャッシュを削除する
- 手順
- 以上、ブラウザを更新してネットワークタブを確認して、
X-Cache
の値がMiss from cloudfront
になっていることを確認する
まとめ
- まとめてみると簡単なことだが、知らないと一生ブラウザのスーパーリロードをやり続けるハメになる。ブラウザのキャッシュとCloudfrontのキャッシュが別物ということを頭で理解しておく必要があるため、今回書いてみました。誰かの参考になれば幸いです。
- Cloudfrontのキャッシュについてもう少し詳しく知りたいという方は、こちらのサイトが非常によくまとまっていてわかりやすいので、一読いただけると良いかと思います。