あめも

初心者インフラエンジニアの仕事や日常の事をそれとなく書いていくブログです

Akamaiを利用した際のCache-Controlの動作を再確認する

Akamaiを経由した際のCache-Controlの動きを再確認してみました。


この説明をするにあたって、下のAkamai公式ブログを参考にしました。
blogs.akamai.com

※勉強途中で、一部間違っている可能性もあります。

Akamaiを使って、画像やJSなどの静的コンテンツを配信しているとします。
f:id:sora_rain:20190130113005p:plain

オリジンサーバーと、Akamaiのキャッシュ設定ともに、Cache-Controlはmax-age=2592000(30日)で設定しているとします。

上記設定の場合、クライアント側にはCache-Control: max-age=2592000のレスポンスヘッダが返され、クライアント側の端末で30日間キャッシュされます。

Akamaiプロパティはそのままで、このオリジンサーバーのCache-Controlを変えた場合はどうなるのでしょうか。

例として、オリジンをGoogleCloudStorageに設定したとします。

GCSに保存されている静的ファイルを一般公開した場合、Cache-Control: public, max-age=3600(1時間)がデフォルトで付与されます。

※ちなみにこの設定は、GCSに保存されているファイルのメタデータを変更すれば良いみたいです。
cloud.google.com

この場合、AkamaiサーバーのTTL(max-age)とオリジンに設定されているCache-Controlを比較し、キャッシュ期間が短い設定をユーザーへ返します。

その結果、こうなります。
f:id:sora_rain:20190204173834p:plain

しかし、オリジンサーバーとAkamaiサーバー間はTTLが30日なので、エンドユーザー側へは初回アクセスから30日間は同じコンテンツが返されます。
f:id:sora_rain:20190204173843p:plain

この設定例はAkamaiとエンドユーザー間の無駄なトラフィックを増やす原因になると思うので、オリジン側のCache-ControlをAkamaiに設定するTTLより大きくするか、AkamaiのプロパティでCache-Controlを上書きすれば良いと思います。

短いCache-Control設定を返す挙動について

キャッシュ期間の短い方をユーザーへ返すという仕様は、考えてみれば一般的な動作でデメリットが少ないと思いました。
もし、長い方を優先してCache-Controlを返した場合、 意図していない長いキャッシュ期間がユーザーへ返される = クライアント側にキャッシュが残ったままコンテンツが更新されないという事になりかねないからです。

最後に

Akamaiの挙動を調べるのは結構楽しかったです。
調べていくうちに、Akamaiのプロパティ配信の仕組みや、エンドユーザーから一番近いエッジサーバーを返す仕組みが知りたいと思いました。