キャッシュ・コントロールで高速化と情報の正確さを両立する

ここまで見てきたように、Webサイトの表示を速くするためには、「CDNでキャッシュさせる」のが非常に有効です。特にCloudflare CDNを利用すれば、キャッシュ以外の機能も同時に利用できるようになるなど、運用上のメリットも大きいものであることが分かりました。

ただし、これまでにも触れたように、なんでもかんでもキャッシュすれば良いというものではありません。 キャッシュを強く効かせることによる弊害も意識してCache Rules（キャッシュ・ルール）を設計する必要があるのです。繰り返しになりますが、キャッシュの運用が不適切だと、以下のような問題が発生する可能性があります。

• オリジンサーバーで更新した画像の表示が反映されない
• 終了したキャンペーンが表示され続ける
• ECサイトの商品情報に古い価格や在庫が表示される
• 最悪の場合、利用者の個人情報を誤って共有してしまう

こうした問題を未然に防ぐには、以下のような点に注意して、慎重にキャッシュを設計する必要があります。

• 誰に同じ情報を返してよいか（全員か、特定の人か）
• 何を保存し、何を保存しないのか
• どのくらいの期間だけ保存するのか
• 更新時にどう新しい情報へ切り替えるのか

適切にキャッシュが設計されたCDNを利用することによって、速さと情報の正しさを両立させることができるようになります。

キャッシュ設計で、速さと情報の正しさを両立させる

復習になりますが、キャッシュとは、サーバーから取得したデータのコピーを一時的にCDNに保存し、次回以降のユーザーからのアクセスに対して、CDNからすばやく返すための仕組みです。これは例えるなら、よく使う資料を、毎回遠くの書庫まで取りに行くのではなく、コピーを取って手元の棚に置いておくようなイメージです。

ところが、実際にユーザーがWebサイトを閲覧する場合、「キャッシュ」はCDNだけにあるわけではありません。CDNを利用しない場合でも、必ず介在することになるのは、ブラウザに内蔵されたブラウザ・キャッシュです。ブラウザ・キャッシュは、ユーザーが利用するパソコンやスマートフォンのストレージ、あるいはメモリ中にあります。そこに蓄積されたデータは、サーバーどころか、ネットワークにアクセスする必要もなく参照できるので、非常に高速なレスポンスが得られます。

こうした点まで考慮すると、ユーザーの上流のデータの保存場所としては、少なくともブラウザのキャッシュ、CDNのエッジキャッシュ、オリジンサーバーと３ヶ所あることになります。

できるだけユーザーに近い場所からデータを返せれば、ネットワークの上流にある保存場所にアクセスする必要もなく、高速化が可能となります。それにより、表示速度を改善するだけでなく、オリジンサーバーへの負荷も減らすことができるのです。

ここで注意したいのは、保存しているデータは、元のデータそのものではなく、あくまでコピーされたデータだということです。その場合、元のデータが更新されても、古いデータのコピーがキャッシュとしてそのまま残っていれば、ユーザーには古い情報が表示されてしまうことになります。そのためキャッシュ設計では、「速く返せるか」だけではなく、「古いキャッシュが残っていても問題ないか」、そして「すべてのユーザーに対して同じ内容を返してよいか」までを考える必要があります。以下、そうした点に配慮しながらキャッシュのルールを設計する際に注意すべき点を詳しく見ていきましょう。

※ オリジンサーバーとは、元のWebサイトやデータが置かれている本番サーバーのこと

※ エッジキャッシュとは、利用者に近いCloudflareの拠点にデータのコピーを保存する仕組み

「全員に同じ情報」でよければキャッシュする

キャッシュを設計する際、最初に確認すべきなのは「その情報を誰に見せるか」ということです。「すべてのユーザーに対して同じ内容を表示してよいデータ」であれば、積極的にキャッシュを活用できます。たとえば、下記のようなものがそれに該当するでしょう。

• 会社のロゴ
• 商品の画像
• ページのレイアウト情報を保持するCSS
• ページ内で実行するJavaScriptプログラム
• Webフォント
• 関連資料などのPDF
• その他、一般公開されている動画や資料

Cloudflareでは、画像、CSS、JavaScript、PDF、フォントなど、特定のファイル拡張子を持つコンテンツは、標準的にキャッシュ対象としています。

一方、HTMLやJSONは、標準ではキャッシュしません。それらについても、キャッシュするファイルの拡張子を登録して、キャッシュするように変更することは可能です。ただし、ここで重要なのは、ファイル形式、拡張子だけで、キャッシュするかどうかを判断してはいけないということです。

ひとくちに画像と言っても、頻繁に差し替えるECの日替わりのセール画像やキャンペーン画像なら、更新方法を細かく検討する必要があります。逆にHTMLでも、全員に同じ内容を表示するページであれば、条件によってはキャッシュを効かせることもできます。

次に、通常はキャッシュすべきでない、あるいは少なくとも慎重に扱う必要のあるデータについて見ていきましょう。

※出典： Cloudflare Docs: Default Cache Behavior

ログイン後の情報や価格、在庫は慎重に扱う

一般的に慎重に扱うべきデータとは、利用者や条件、状況によって、時間とともに内容が変化する可能性のある情報です。たとえば、以下のようなものが考えられます。

• ログイン後のマイページ
• ショッピングカート
• 決済画面
• 会員情報
• 利用者ごとに異なる価格
• 在庫情報
• 管理画面
• 利用者ごとに内容が変わるAPIレスポンス

たとえば、あるユーザー向けの情報をキャッシュし、そのコピーを別のユーザーに返してしまったりすると、個人情報や機密情報の漏えいにつながる可能性も出てきます。情報漏洩とまではいかなくても、たとえばECサイトで、価格変更後に古い価格を表示してしまったり、売り切れた商品なのに、在庫があるように見えてしまったりすれば、クレームなど事業上の問題に発展してしまうでしょう。

とはいえ、技術的には、こうした情報をまったくキャッシュできないわけではありません。以下のような点に注意しつつ、個人に関する情報や、時間の経過とともに変化していく情報をキャッシュするという選択も考えられます。

• 情報や利用者ごとにキャッシュを分ける
• 保存時間を短くする
• 更新時に確実にキャッシュを削除する

こうした細かく高度な設計によって、キャッシュを極限まで活用できる場合もあるでしょう。ただし、その分だけ設計と運用が複雑になってしまうことは避けられません。まずは、「全員に一定期間同じ内容を返せる情報と、利用者や時間によって変化する情報を分ける」。これがキャッシュ設計の基本であり出発点です。

※ APIとは、Application Programming Interfaceの略で、ここではシステム同士がデータや機能をやり取りするためのインターフェースのこと

どのくらいの期間保存するかを決める

次に考えるべきことは、キャッシュを保持する時間の長さです。ここで使われるのがTTLという概念です。TTLとは、Time To Liveの略で、キャッシュしたデータをどのくらいの期間、有効なものとして扱うかを示す「生存時間」のことです。

たとえば、ほとんど変更しない会社ロゴなら、かなり長い期間キャッシュしても問題にならないでしょう。これはそれだけTTLが長いということになります。

一方で、以下のような情報は、一般的にTTLが短くなると考えられます。

• 期間限定のキャンペーン
• 頻繁に更新するニュース
• 商品の価格情報
• 商品の在庫情報

このような情報を長時間キャッシュすると、古い情報が残るリスクが高まります。重要なのは、すべてのコンテンツに同じTTLを設定するのではなく、それぞれの情報の更新頻度を考慮し、古い状態をどこまで許容できるかによって個別にTTLを決めることです。

Cloudflareでは、Cloudflareのネットワーク上で保存するEdge Cache TTLと、利用者のブラウザで保存するBrowser Cache TTLを分けて扱い、別々に設定することが可能です。

※出典： Cloudflare Docs: Edge and Browser Cache TTL

更新したら、新しい情報へどう切り替えるか？

キャッシュ設計においては、保存する方法と同じくらい、更新する方法が重要です。Webサイトを運用していれば、以下のような変更は、日常的に発生するでしょう。

• 画像を差し替える
• 会社情報を修正する
• キャンペーンを開始、終了する
• CSSを更新する

そのような際に、キャッシュに古いコピーが残っていると、新しい情報がすぐには表示されないことがあります。Cloudflareには、保存されているキャッシュを削除するPurge（パージ）という機能があります。URLを指定することで特定のキャッシュだけを削除することも、まとめてすべてを削除することも可能です。

Cloudflareでは、すべてのキャッシュを一括削除する方法より、必要なファイルだけを指定して削除する方法を推奨しています。すべてを削除してしまうと、その後しばらくの間、アクセスがオリジンサーバーへ集中し、一時的にせよ、負荷が高まる可能性があるためです。

※出典： Cloudflare Docs: Purge Cache

エッジキャッシュをPurgeしても、ブラウザにキャッシュが残ることがある

もうひとつ、Web担当者が知っておくべきことは、エッジキャッシュとブラウザキャッシュとの違いです。それらは、それぞれ独立したキャッシュなので、CloudflareのエッジキャッシュをPurgeしたとしても、すでにユーザーのブラウザに保存されたデータまでは削除されません。

そのため、オリジンサーバーや、Cloudflareのエッジキャッシュ上では新しい画像に切り替わっているのに、ユーザーのパソコンやスマートフォンには古い画像が表示され続ける、ということも起こり得ます。

このような問題は、Cloudflare（CDN）側の設定だけでは解決しません。キャッシュの更新の設計では、「Cloudflareにどのくらいの期間保存するのか」と、「ブラウザ側にどれくらいの期間保存させるのか」を分けて考える必要があります。さらに、保存期間だけではなく、更新時には、「何をどのように新しい情報へ切り替えるか」までを決めておくことが重要です。

※出典： Cloudflare Docs: Set Browser Cache TTL

設計を設定に落とし込むCache Rules

CloudflareはCache Rulesを設定する機能を備えています。Cache Rulesは、ファイルやデータごとのURLなどの条件に応じて、以下のような挙動を設定するものです。

• キャッシュ対象にするか
• キャッシュを回避するか
• Cloudflare側でどのくらいの期間保存するか
• ブラウザ側でどのくらいの期間保存するか

また、オリジンサーバーから送られるCache-Controlという情報を使って、ブラウザやCDNに対して、キャッシュ方法を指示することも可能です。

ここで注意したいのは、「Cache Rulesから考え始めない」、ということです。それ以前に、各々のデータについて、以下のような事項を整理しておく必要があります。

• 誰が見ても同じ情報か
• どのくらいの頻度で更新するか
• 古い情報をどこまで許容できるか
• 更新したとき、いつ新しい情報へ切り替えるか

このような判断が先にあり、それをCloudflareの設定へ落とし込むために、Cache Rulesがあると考えるのです。つまり、機能から考えるのではなく、情報の性質から考える、ということになります。この順番が重要なのです。

キャッシュは、保存することだけでなく、その内容をパージ（削除）することまで含めて設計する必要があります。ここを怠ると、キャッシュ導入直後は問題なく見えても、その後の「サイト更新時」になって初めてトラブルが表面化することになるでしょう。キャッシュの設計は、Webサイトの運用ルールの一部として考えるべきことなのです。

※ Cache-Controlは、ブラウザやCDNにデータを保存してよいか、どれくらいの期間保存するか、などをHTTPヘッダーとして伝える

※出典： Cloudflare Docs: Cache Rules

DOMOの視点

キャッシュは高速化のためだけの設定ではなく、情報をどこで管理するかの設計を含めて考える必要があります。DOMOとしてキャッシュを見るとき、最初に確認したいのは、どこまで強くキャッシュを効かせるかではありません。

最初に整理すべきは、以下のようなポイントです。

• この情報は全員に同じか
• いつ更新されるのか
• 古い状態がどこまで許されるのか
• 事業成果に近い重要な情報か
• 更新時に誰が確認するのか

たとえば広告LPでは、表示速度は非常に重要でしょう。しかし、キャンペーン終了後も古い内容が表示され続けたりすれば、速さ以前に、そのサイト、ひいては企業に対する信頼性の問題になります。ECサイトでも、商品画像はキャッシュを活用しやすい一方で、価格、在庫、カート、会員情報は同じ考え方では扱えません。キャッシュは、強くすればするほどよいものではありません。速く返せばよいという情報と、常に正しさを優先すべき情報を分けること。Cloudflareを使った高速化では、この仕分けが設計の中心になります。

まとめ

キャッシュは、Webサイトを速くするための有効な仕組みです。ただし、キャッシュ設計の本質は速度だけではありません。以下の４点を整理して運用することが非常に重要です。

• 何を保存するか
• どのくらいの期間保存するか
• 誰に同じ情報を返してよいか
• 更新時にどう新しい情報へ切り替えるか

まずは画像、CSS、JavaScript、フォント、PDFなど、全員に同じ内容を返しやすいものから考えましょう。次に、HTML、API、ログイン後のページ、価格や在庫情報などについて、情報の性質とリスクを確認したうえで判断します。

CloudflareのCache Rulesは、その判断を実際の設定へ落とし込むための機能です。キャッシュを設定することから始めるのではなく、情報を分類することから始める。それこそが、安全にWebサイトを高速化するための基本なのです。

覚えておきたい用語

• キャッシュ： 取得したデータのコピーを一時保存し、次回以降すばやく返す仕組み
• オリジンサーバー： 元のWebサイトやデータが置かれている本番サーバー
• エッジキャッシュ： 利用者に近いCloudflareの拠点に保存されるキャッシュ
• ブラウザキャッシュ： 利用者のブラウザに保存されるキャッシュ
• HTML： Webページの構造を作るための言語
• JSON： システム間でデータをやり取りするときによく使われる形式
• API： システム同士がデータや機能をやり取りするための接続口
• TTL： キャッシュしたデータを新しいものとして扱う期間
• Edge Cache TTL： Cloudflareのネットワーク上でキャッシュを保持する期間を制御する設定
• Browser Cache TTL： 利用者のブラウザでキャッシュする期間を制御する設定
• Cache Rules： Cloudflareでキャッシュ対象や保存方法などを条件ごとに設定する機能
• Cache-Control： ブラウザやCDNにキャッシュ方法を伝えるHTTPヘッダー
• Purge： Cloudflareに保存されたキャッシュを削除する操作