Cache Response Rulesの紹介

本日、Cache Response Rulesを発表できることを嬉しく思います。これは、オリジンサーバーが応答した後、Cloudflareがコンテンツをキャッシュする前に実行される新しいルールタイプです。Set-Cookieや誤ったCache-Controlのような、オリジン側で変更や削除が難しいヘッダーによって、本来なら簡単にキャッシュされるべきコンテンツがオリジンへ戻されてしまうのを見て苛ついたことがあるなら、Cache Response Rulesがまさにその修正であり、まさに適切なタイミングで適用されます。

いつ、どのようにキャッシュの判断がなされるか

CDNのキャッシュとオリジンサーバーは対として機能します。目標は可能な限りキャッシュから応答し、エッジが応答できない場合にのみオリジンへ戻ることです。キャッシュヒット率の改善は、この役割分担を正しく行うことから生まれます。

キャッシュを確認すべきでないときに確認すると、本来ミスするルックアップを無駄にします。
逆に確認が少なすぎると、エッジが吸収すべきトラフィックをオリジンが処理してしまい、パフォーマンスの利得が失われます。

重要なのは、オリジンがキャッシュを指示することです。オリジンがキャッシュ可能なアセットを返すと、そのレスポンスヘッダーによってCloudflareにどれくらいの期間それを提供してよいか、いつどのように再検証するか、あるいはそもそもキャッシュするかどうかが伝えられます。キャッシュは常にオリジンが許す範囲でしか効率的になれません。オリジンが間違えると、キャッシュは飾り物になり、オリジン側のインフラコストが急増します。

多くのキャッシュ適格性の問題はリクエスト時には決まらず、オリジンが応答した後に表面化します。例えば、訪問者が /static/app.js を要求したとします。Cloudflareはキャッシュを確認し、ミスするとそのリクエストをオリジンに転送します。オリジンはファイルを返しますが、そのレスポンスヘッダーのどこかにひそかにSet-Cookieヘッダーが含まれていることがあります。本来は全てのCloudflareデータセンターでキャッシュされるべきアセットが、これによってキャッシュ不適格になってしまいます。

この問題は訪問者ごと、サイトごと、同じ誤ったヘッダーを持つケースで積み重なり、キャッシュヒット率が低下し、オリジンの帯域が漏れ出し、パフォーマンスが損なわれ、インフラコストが高騰します。

同様の問題にはいくつかのバリエーションがあります。

オリジンが Cache-Control: no-cache を送っているが、実際にはCDNで安全にキャッシュできるアセットである場合。
オリジンがブラウザ向けの正しい指示を送っているが、それがCloudflareに対しては適切でない場合。
オリジンがETag（リソースの特定バージョンを示す識別子）を付けているが、それが過度に厳格で、条件付きリクエストごとに再検証が発生してしまう場合（revalidation thrash）。

特に大規模なチームでは、オリジンのレスポンスを管理する担当とCDNを管理する担当が別々であることが多く、ワンラインのヘッダー変更が数週間にわたる調整になることがあります。これらの問題はリクエスト時には解決できません。Cloudflareが /app.js にSet-Cookieを見たとき、リクエストフェーズは終わっており、レスポンスはすでに進行中だからです。

そこで私たちは、適切な箇所に修正を入れました。レスポンスがオリジンから返った直後、Cloudflareがコンテンツをキャッシュする前に動作するのがCache Response Rulesです。このタイミングであれば、オリジンを変更できない場合でも、不要なヘッダーの除去やキャッシュ挙動の調整を行い、期待されるキャッシュヒット率を取り戻すことができます。

（この記事は続きがあります）

Introducing Cache Response Rules

要約

Summary

Key Points

翻訳

Cache Response Rulesの紹介

いつ、どのようにキャッシュの判断がなされるか