Cloudflareのキャッシュについて理解する

なぜCloudflareのキャッシュが速度改善に繋がるのか？

Webサイトの表示速度を決めるもの

通常、ブラウザがWebサイトから何かのデータを取得する時には、

// リクエスト
(1)ブラウザ
↓
(2)インターネット
↓
(3)オリジンサーバー
↓
(4)インターネット
↓
(5)ブラウザ
// データ受信完了

という順番でデータを転送します。

ページ表示に関する速度は、回線速度に依存するように思えますが、CSSやJavascriptなどのページレンダリングブロックを除けば、ほとんどのケースで、

• オリジンサーバーのレスポンススピード
• オリジンサーバーとアクセス元の端末の物理的距離

で決まります。

例えば、オリジンサーバーレスポンスが100msだとしても、サーバーと端末の距離が遠いと物理的距離がボトルネックになります。例えば、日本からアメリカサーバーにアクセスすると、概ね300msくらいかかるイメージです。

Webサイトでは100msの速度改善する追求する世界ですので、この遅延は無視できません。大手サービスでは、サーバーを本国でなくてなるべく近い地域に点在させて速度を改善させています。

ワンクリックで世界中のエッジサーバーから配信できるのがCloudflareのキャッシュ機能

自分でオリジンサーバーを世界中に点在させなくても、世界中のサーバーからコンテンツ配信できるのがCloudflareのCDNサービスです。

Cloudflareのキャッシュ機能は、世界中にあるCloudflareのエッジサーバーにリクエストデータを保存（キャッシュ）させて、アクセス元からもっとも近いサーバーからキャッシュしたコンテンツを配信することで、高速レスポンスを実現しています。

オリジンサーバーの場所は一箇所のままで、世界中にコピーサーバーを設置できるようなイメージです。

Cloudflareのキャッシュが効いている場合は、下記のような流れになります。

// リクエスト
(1)ブラウザ
↓
(2)インターネット
↓
(3)エッジサーバー // キャッシュしているか、キャッシュ対応ルートかをチェックしてから、レスポンスを決める
↓
(4)インターネット
↓
(5)ブラウザ
// データ受信完了

(3)のCloudflareのエッジサーバーがやっていることは、文字通りプロキシで、リクエストをどう処理するかを判定します。

Cloudflareのエッジサーバーのキャッシュを返す設定になっていればそのままオリジンサーバーにはアクセスさせずにエッジサーバーのキャッシュを返します。

Cloudflareのエッジサーバーがキャッシュを返さないと判断した場合は、そのままオリジンサーバーにリクエストを投げて返ってきたレスポンスをそのままブラウザへプロキシします。

Cloudflareがキャッシュするルール

Cloudflareがサーバーのコンテンツをキャッシュするのは4つの条件があります。

• Cloudflareのネームサーバーを使っている
• Cloudflareのプロキシを利用している
• Cloudflareのキャッシュ対象ファイルである
• オリジンサーバーのブラウザキャッシュTTLが0以上である

この全ての条件が揃っていないとCloudflareはコンテンツをキャッシュしません。

また、Cloudflareの機能である「Page Rule」でキャッシュに関する設定が追加されている場合は、Page Ruleが優先され上書きされます。

Cloudflareのネームサーバーを使っていて、Cloudflareプロキシを利用している

Cloudflareプロキシを利用している状態は、ドメインのネームサーバーがCloudflareかつDNSレコード設定でプロキシをオンにしている状態です。

Cloudflareのキャッシュ対象ファイルである

Cloudflareのキャッシュ対象ファイルは、下記の拡張子のファイルになります。

• bmp
• ejs
• jpeg
• pdf
• ps
• ttf
• class
• eot
• jpg
• pict
• svg
• webp
• css
• eps
• js
• pls
• svgz
• woff
• csv
• gif
• mid
• png
• swf
• woff2
• doc
• ico
• midi
• ppt
• tif
• xls
• docx
• jar
• otf
• pptx
• tiff
• xlsx

これ以外の、例えば.htmlや.jsonファイルはキャッシュされません。ただし、Page Ruleでキャッシュする設定を追加することは可能です。

オリジンサーバーのブラウザキャッシュTTLが0以上である

最後の条件である「オリジンサーバーのブラウザキャッシュTTLが0以上である」というのが実はキーポイントです。

厳密には、オリジンサーバーがコンテンツのレスポンスを返す際に、

• Cache-Controlがpublicに設定されている
• max-ageが0より大きい or Expiresヘッダーが未来になっている

という条件です。どちらも欠けてはいけません。

Cloudflareがキャッシュしてくれないという場合は、このケースが多いでしょう。オリジンサーバーでのブラウザキャッシュTTLの設定漏れです。

また、ホスティングサービスによっては、ブラウザキャッシュTTLを設定できない場合もあるので、その場合は、Page RuleでブラウザキャッシュTTLを追加します。

Cloudflareエッジサーバーのキャッシュ保存ルール

Cloudflareのエッジサーバーでのキャッシュ期間は、基本的には「オリジンWebサーバーからのキャッシュヘッダー」になります。

例えば、画像ファイルのレスポンスヘッダーのキャッシュ設定が1年であれば、Cloudflareのエッジサーバーでのキャッシュも1年になります。

例外ケースは、

• Page RuleでCache Everythingを有効にしているURL
• Page RuleでEdge キャッシュ TTLを0以上にしているURL

この二つがマッチした場合、エッジサーバーのキャッシュTTLはPage Ruleで設定したものになり、かつオリジンサーバーのレスポンスからCookieを削除します。

なお、Page RuleでCache Everythingを設定しない場合、Edge キャッシュ TTLの設定は有効になりません。

また、Cache EverythingにマッチしないURLは、通常通り「オリジンWebサーバーからのキャッシュヘッダーが尊重」されます。

Cloudflareのエッジサーバーキャッシュを削除（クリア）する方法

これは二つ方法があります。

• 管理画面から削除
• APIから削除

簡単なのは、管理画面からの削除で、管理画面の「Caching」メニューから「構成」タブをクリックして、キャッシュをパージブロックで任意のボタンを押すだけです。

APIの場合は、任意のプログラムから、

https://api.cloudflare.com/client/v4/zones/:identifier/purge_cache

に対して、必要なパラメータをつけてDELETEリクエストを送ります。

この時にPage Ruleのようなルートマッチは使えないので、管理画面と同じく「個別ファイル指定」か「全て削除」になります。

Cloudflareのキャッシュについて見てきました。

こうして詳しく見てみると、とても理にかなった仕組みなっていることがわかります。また、単純にプロキシをオンにしただけでは細かいキャッシュ設定が出来ないということでもあるので、CloudflareをCDNとして使っている場合は、しっかりと仕組みを理解した上で設定を見直すようにしましょう。