この記事の内容について
この記事ではFastlyを利用した際にオブジェクトが思った通りキャッシュされない場合のよくある原因と確認すべき内容について説明します。
オブジェクトに設定されているTTLを確認する手順については以下のサイトを参照して下さい。
http://qiita.com/AtsushiFukuda/items/fb20f8a410b47396d83a
特に記載がない限り本記事の記載内容はデフォルト設定での挙動となります。
Fastlyの正式なサポート情報は https://docs.fastly.com/ を参照して下さい。
キャッシュを行わない条件
Fastlyサーバーでは以下の条件の場合はキャッシュを行いません。
- HTTPリクエストのMethodがGETかHEAD以外の場合（例POST, PUT, DELETEなど)
- オリジンからのHTTPレスポンスにSet-Cookieが含まれている。
- オリジンからのレスポンスにCache-Control: private が含まれている
（Cache-Control: no-store, no-cache はキャッシュ対象となります）
まずはキャッシュされないリクエストが上記の条件に合致していないかを確認しましょう。
Varyヘッダー
Cacheに影響を与えるヘッダーとしてはVaryヘッダーがあります。Varyヘッダーとは簡単にいうとFastlyサーバーなどのサーバーに「同じURLでもVaryヘッダーに指定されているヘッダーの内容が異なれば別オブジェクトとして取り扱いなさい」というオリジンサーバーからの命令となります。
VaryがあってもFastlyサーバーにキャッシュ自体は行われますが、例えばオリジンからのレスポンスにVary: User-Agentというヘッダーが含まれる場合、同一のURLに対するリクエストでも、ChromeやFireFox、iPhoneのSafariなど、User-Agentが異なる場合は別々のオブジェクトとしてキャッシュが保持されます。
ここで注意が必要なのは、例えば同じChromeであってもブラウザのバージョンや適用しているパッチが違えばUser-Agentの値が異なるため別のオブジェクトとしてキャッシュされます。
そのため不用意にVaryを利用すると、キャッシュ効率が悪くなり、結果としてキャッシュヒット率の低下、オリジンオフロード率の低下とCDNサービスを適用するメリットが低下してしまいます。
Varyを利用する場合は、最小限のパターンを持つリクエストヘッダーをVaryに含めることがポイントとなります。
一般的にVaryにAccept-Encodingのみが指定されている場合は問題になることは少ないですが、それ以外のヘッダーがVaryに指定されている場合はキャッシュが効率的に行えていない可能性を疑ってみる必要があります。
特にWordPressやDrupalなどをCMSとして利用している場合、無条件でVaryにCookieなどが含まれている場合があるので注意が必要です。
オリジン側で本当に必要なヘッダー情報のみをVaryに指定するか、Fastlyサーバー側でVaryヘッダーの内容を無視するような設定を追加するなどの対処を検討しましょう。
VaryヘッダーがFastlyサーバー上の挙動に及ぼす影響については英文になってしまいますが
https://www.fastly.com/blog/best-practices-for-using-the-vary-header
のサイトに詳しく記載されています。
FastlyサーバーのTTLの選択ロジック
Fastlyサーバーはオリジンサーバーからのレスポンスに含まれるCache-Controlヘッダーなどの値の内容に基づいてキャッシュするオブジェクトに設定するTTLを決定します。
TTLの設定に関連するヘッダーは何種類かあるのですが、以下の様な優先順位で適用するTTLが決定します。
-
Set-CookieまたはCache-Control: privateを含む場合 → キャッシュしない -
Surrogate-Control: max-age=ヘッダーに指定したTTL -
Cache-Control: s-maxage=ヘッダーに指定したTTL -
Cache-Control: max-age=ヘッダーに指定したTTL -
Expires:ヘッダーに指定したTTL - Fastly設定上で指定されたFallback TTL(Default TTL)
つまりSet-CookieやCache-Control: privateが存在する場合はSurrogate-ControlやExpiresヘッダーが存在していてもキャッシュが行われません。
Surrogate-Control:max-age=120とCache-Control: max-age=60のふたつのヘッダーが存在する場合はSurrogate-Controlヘッダーが優先されますので、TTLとしては120秒が適用されることになります。
意図しないTTLが適用されている場合は上記の優先順位も確認して下さい。
クエリストリングやSSLリクエストのキャッシュについて
Fastlyサーバーはデフォルトの設定ではリクエストされたHostとPathとクエリストリングをキャッシュされたオブジェクトを判断するための情報として利用します。
つまり以下のURLでいうと太字の部分がキャッシュを識別するキーとなります。
http://www.sample.com/aaa.html?id=111
http://www.sample.com/aaa.html?id=222
そのため上記のURLはそれぞれ別のページとしてキャッシュされます。
またキャッシュを行う際にSSLとNon−SSLは考慮されません。そのため以下のURLは同じオブジェクトとして扱われます。
http://www.sample.com/aaa.html?id=111
https://www.sample.com/aaa.html?id=111
SSLとNon-SSLで返却されるオブジェクト内容が異なる場合、SSLかどうかを示すヘッダーをVaryに設定することで問題を回避することが出来ます。
Varyにヘッダーを追加する手順は以下のページをご確認下さい。
https://docs.fastly.com/guides/vcl/manipulating-the-cache-key
404レスポンスなどの取り扱い
Fastlyは404 Not Found レスポンスも指定されたTTLの期間キャッシュを行います。
Fastlyがデフォルトでキャッシュを行うHTTPのレスポンスコードは以下の通りです。
| Code | Message |
|---|---|
| 200 | OK |
| 203 | Non-Authoritative Information |
| 300 | Multiple Choices |
| 301 | Moved Permanently |
| 302 | Moved Temporarily |
| 404 | Not Found |
| 410 | Gone |
404レスポンスなど、特定のレスポンスコードの場合に通常とは異なるTTLを設定する手順は以下のページをご確認下さい。
https://docs.fastly.com/guides/basic-configuration/overriding-caching-defaults-based-on-a-backend-response
以上がキャッシュされているはずのオブジェクトがキャッシュされていないようにみえる場合のよくある原因です。
もちろんここで説明した以外のものが原因でキャッシュが正常に行われていないケースもありますが、思っている通りキャッシュされていないように思えるときはまずはこれらの内容を確認して見てください。