Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

FastlyのTTL設定に関する問題のよくある原因

More than 1 year has passed since last update.

この記事の内容について

この記事では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が決定します。

  1. Set-CookieまたはCache-Control: privateを含む場合 → キャッシュしない
  2. Surrogate-Control: max-age=ヘッダーに指定したTTL
  3. Cache-Control: s-maxage=ヘッダーに指定したTTL
  4. Cache-Control: max-age=ヘッダーに指定したTTL
  5. Expires:ヘッダーに指定したTTL
  6. Fastly設定上で指定されたFallback TTL(Default TTL)

つまりSet-CookieCache-Control: privateが存在する場合はSurrogate-ControlやExpiresヘッダーが存在していてもキャッシュが行われません。

Surrogate-Control:max-age=120Cache-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


以上がキャッシュされているはずのオブジェクトがキャッシュされていないようにみえる場合のよくある原因です。

もちろんここで説明した以外のものが原因でキャッシュが正常に行われていないケースもありますが、思っている通りキャッシュされていないように思えるときはまずはこれらの内容を確認して見てください。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away