【検証】RemixとCloudflare Pagesを組み合わせるとどうなる？

Remixを通じてWebを学ぶ 第11回

　Remixで作成したWebサイトでは、通信時のHTTPヘッダーを細かく設定できます。この特性はCloudflareのCDNキャッシュと相性が良く、設定次第では高速なWebサイトを構築できます。Cloudflare PagesとRemixを組み合わせた場合に、どんな設定をするとキャッシュがどのような挙動になるのか、検証してみましょう。

対象読者

• Reactの基本を修めている方
• 通信回線が弱いユーザーにも高速に表示できるサイトを作りたいエンジニア
• WebブラウザとNode.jsという異なるランタイムをそれぞれキャッチアップするのが辛くなってきたエンジニア

前提環境

　筆者の検証環境は以下の通りです。

• macOS Sonoma 14.6.1
• Node.js 22.6.0
• NPM 10.8.2
• Remix 2.10.3

CloudflareのCDNサーバーとは

　前回までに、Remixで作成したWebサイトをCloudflare Pagesにデプロイする方法、Cloudflare向けのRemixプロジェクトがどのようなファイル構成になっているのかを解説しました。今回は応用編として、Cloudflareの得意分野であるCDNとの連携による、キャッシュの活用方法を解説します。

　Cloudflareは、世界中に分散されたサーバーを使って、WebサイトのコンテンツをキャッシュするCDN（Content Delivery Network）というネットワークを提供しています。図1はCloudflareの公式サイトで紹介されているCDNの仕組みの図です。

図1：CloudflareのCDN（出典元：「CDNとは | CDNの仕組みとメリット」）

　世界中のユーザーが直接アクセスするサーバーは、ユーザーから一番近いCDNサーバーになっていますね。このCDNサーバーにコンテンツの有効なキャッシュが保存されている場合、元々のコンテンツ提供元のサーバー（オリジンサーバー）にアクセスすることなくユーザーにコンテンツを配信できるのです。キャッシュがない場合は、CDNサーバーがオリジンサーバーにアクセスすることでコンテンツを取得し、必要であればキャッシュした上で、ユーザーに配信します。なお、CloudflareのCDNサーバーの所在地については、詳しくは非公開ですが、地域だけは公開されています。

　日本国内のCDNサーバーは、2024年8月現在、東京、大阪、福岡、那覇の4箇所に設置されているようです。東日本のみなさんは東京のCDNサーバーにアクセスすることになると思いますが、西日本のみなさんは居住地によって接続先が異なりそうです。

CDNサーバーのキャッシュ

　Cloudflareの世界観では、CDNサーバーがキャッシュを持つ、というのはどういうことなのか、もう少し解説しておきましょう。まずは、CDNサーバーを挟まない場合の、シンプルな構成の通信について想定してみます（図2）。

図2：CDNサーバーを挟まない通信

　各クライアントが1つのオリジンサーバー（多くの場合、アプリケーションサーバーやAPIサーバーと呼ばれるもの）に直接アクセスする場合、クライアントがリクエストを送信するたびに、オリジンサーバーはその都度レスポンスを返します。

　この場合、リクエストの数だけオリジンサーバーに負荷がかかるため、大量のリクエストがあるとオリジンサーバーがダウンしやすくなります。また、オリジンサーバーが地理的に遠い場所にある場合、レスポンスの遅延が発生しやすくなります。では、CDNサーバーがあるとどうなるのでしょうか。まずは、サーバーの関係を図示してみましょう（図3）。

　

図3：CDNサーバーを挟んだ構成

　図3は、図1で図示されていたものを単純化した形です。クライアントからのリクエストを地理的に最も近いCDNサーバーが受け取り、CDNサーバーがオリジンサーバーにリクエストを送信します。もしCDNサーバーがオリジンサーバーに常にリクエストを送る場合、オリジンサーバーにかかる負荷の総量は図2と変わりません。ここからがCDNサーバーのキャッシュが活きてくる場面となります。

　図3のリクエストの後、レスポンスとしてCDNサーバーがオリジンサーバーからコンテンツを取得した時点で、所定のルールに従って、CDNサーバーはコンテンツを一時的に保存します（図4）。この保存したコンテンツのことをキャッシュと呼びます。

図4：CDNサーバーがコンテンツを保存する

　その後、所定のルールの下で有効なキャッシュがある条件下で、別のクライアントから同じコンテンツにアクセスがあった場合、CDNサーバーはオリジンサーバーにアクセスすることなく、保存されたキャッシュを利用してクライアントにコンテンツを配信します（図5）。

図5：CDNサーバーがキャッシュを利用してコンテンツを配信する

　どこかのCDNサーバーにデータがキャッシュされると、他のCDNサーバーにもコピーされて共有されます。そのため、キャッシュが有効である限り、どのCDNサーバーにアクセスしても同じコンテンツが返されるようになります。Webサイトが行う通信のうち、キャッシュが返される割合が多いほど、オリジンサーバーにアクセスする回数が減って負荷が下がったり、クライアントから見た表示速度が向上することが期待できます。

キャッシュにはルールが必要

　キャッシュは、高速化や負荷の低減といった文脈では便利なものですが、同時に取り扱いが難しいものでもあります。たとえば、ブログなどで誤った画像を公開してしまったら、その画像はすぐに差し替えますよね。

　しかし、CDNサーバーに画像データを1年間キャッシュするようなルールを設定していた場合、オリジンの画像だけを差し替えても、CDNサーバーは古い画像を配信し続けることになります。

　ここまでの解説で、何度か「所定のルール」や「有効なキャッシュ」という言葉を使ってきました。キャッシュという分野では、ただキャッシュと使うことよりも、一度設定したキャッシュがいつまで有効であるか、どの条件下でキャッシュを利用するか、といったルールを設定することのほうが重要なのです。

　Cloudflareでは任意のオリジンサーバーに対してCDNキャッシュを設定できるため、キャッシュの設定を細かく制御するためのCloudflare Cacheというサービスを提供しています。ファイルのパスや、Cookie内のパラメータの有無などに応じて、細かくルールが決められます。Cloudflareのキャッシュについて、より細かい挙動を知りたくなったら、公式ドキュメントを参照するとよいでしょう。