Cache Rules と Cache Status のREVALIDATED について
Pages Rules のリタイアメントに伴い、
Transform Rules
Origin Rules と機能を触ってきました。今日は３回目で Cache Rules です。
Cache Rules とは
CDN におけるキャッシュの挙動をカスタマイズします。
キャッシュの対象となるもの、キャッシュする期間、等を調整できるほか、一致するリクエストに対して Cloudflare のキャッシュやその他のルール製品との特定のやり取りをトリガーできます。
例えばデフォルトではCloudflareはHTMLをキャッシュしません。その一方で、トップページ以外のHTMLはそこまで変更されない場合はキャッシュを行いたい場合があります。このような場合に用いる機能です。
さっそくやってみる
まずは以下の記事などを参考にOriginとCDNをセットアップします。
Originはなんでも大丈夫です。
ブラウザのデベロッパーツールを開きながらCloudflare経由でアクセスした場合、以下の通りCache-StatusがDYNAMICとキャッシュがバイパスされていることがわかります。
ではCloudflare側でキャッシュの挙動を変更させていきます。Create ruleをクリックします。
適当な名前を入力します。
以下のように設定変更を行います。
この状態で一度Deployします。
そうすると１回目のアクセスはMISSとなり、２回目のアクセスはHITとなりHTMLもキャッシュされたことがわかります。
Top ページだけキャッシュさせない方法
ファイル拡張子だけの設定では不十分なのでパスで挙動を変更させます。作り方はいくつかありますが例えば以下2のルールの組み合わせです。
ルール1
ルール2
ルール1によりルート(つまりデフォルトindex.html)以外の全てのコンテンツをキャッシュ対象として指定します。念のためルール2で、ルート(index.html)を明示的に除外します。ちなみにルール2が無くても動作しますが、除外したいものは明示的に設定しておいた方がわかりやすいかな？ぐらいです。
例えば以下のコマンドなどでテストが可能です。
sudo mkdir test
cp sudo index.html ./test/index.html
それぞれのindex.htmlで挙動が異なります。
一つ注意点ですが、キャッシュはフルパス単位で行われファイル名やファイルのハッシュ値などでは行われないということです例えば
https://test.com/index.html?test=yyyyy
等であればindex.html?test=yyyyy単位で処理されるため注意が必要です。後ほど Cache Key という項目で詳しく触れたいと思います。
エッジTTLとブラウザTTLの設定変更
キャッシュにはCloudflare側でキャッシュされるものとブラウザが独自にキャッシュするものの２種類があります。
エッジTTLはCloudflareでどれぐらいの期間キャッシュされるか？を意味し、ブラウザTTLはブラウザがどれぐらいそのコンテンツを（実際には読み込まずに）使用するか？です。
TTLの間、オリジンでコンテンツが更新されても古いものが表示されるため適切な時間を設定しておくことが大事です。あまりに短いと今度はオリジンからの通信費用が上がってしまうため、バランスをとる必要がります。この際、拡張子やディレクトリ単位でその挙動を変更させたいケースもあるかと思います。また、ブラウザキャッシュはブラウザがその通り動作するとは保証されませんので、努力目標ぐらいのコントロールしかできません。
例えば以下の通り設定した場合、
キャッシュされたコンテンツのアクセスが５秒を過ぎるたびにREVALIDADEDというステータスとなります。
デフォルトではmax-age=14400としてクライアントから14400秒のリクエストを出していますが、Cloudflare側の設定でそれを5秒に上書きしています。
同様にブラウザキャッシュのTTLもこれで書き換えが可能ですが、先ほど記載した通りこちらはブラウザの挙動をコントロールすることは可能なものの、保証はされていないため注意が必要です。
Cache Key
Cloudflare がコンテンツをキャッシュを行う際に、コンテンツを一意に判断する仕組みがCache-Keyです。以下の組み合わせで行われます。
1.フルパス（含むクエリーストリング）、2.CORS用にクライアントから送付されるオリジンヘッダー、3.x-http-method-override, x-http-method, x-method-override, x-forwarded-host, x-host, x-forwarded-scheme, x-original-url, x-rewrite-url, forwarded の値
Origin Rules では Cache Key の以下の3つの値を書き換えることが可能です。
- Cache by device type - デバイスごとにキャッシュの挙動を変更します
- Cache deception armor - Web キャッシュ デセプション攻撃 に対するキャッシュの保護
- クエリーストリング - クエリーストリングを無視する、もしくは一部としてキャッシュを行うかどうか
例えば以下の設定を行った場合
https://cachetest.a.harunobukameda.com/?foo=bar
https://cachetest.a.harunobukameda.com/?foo=bar1
https://cachetest.a.harunobukameda.com/?foo=bar2
これらのキャッシュの挙動は一緒になります。ただしクエリーストリングを無視した結果がユーザーに戻ることに気を付けてください。世の中には意図的にダミーのクエリーストリングをリクエストに付与して、機密情報を搾取するWebキャッシュデセプション攻撃というものが存在していますが、その対策に役立ちます。
Caching on Port
Webサーバにはメンテナンス用の専用ポートが存在しているケースがあります。普通に443からアクセスすると一般ユーザー扱い、8443からアクセスすると管理者扱いでメンテナンス画面にログインできる、といったものです。この場合443へのアクセスのみをキャッシュしたいケースがあります。
その他にもここに複数のキャッシュ挙動をコントールする機能が備わっています。こちらにまとまっていますので見てみて下さい。
Discussion