😊

Cloudflare WorkersでSSRができると何が嬉しいか

4 min read 4

Next.jsの対抗馬となりそうなReactのフレームワークでRemixのv1.0がリリースされました。

https://remix.run/

個人的にRemixでいちばん魅力を感じているのはCloudflare WorkersでSSRができるという点です(現状ではNext.jsをCloudflare Workers上でSSRするのは難しい)。これがなぜ嬉しいのかと言うと、パフォーマンスを出しつつ、低コストで運用でき、大量のアクセスに対しても低コストでスケールできそうだからです。

そもそもSSRをする必要ある?

ほとんどのWebサービスはSSRなしでSPAとしてビルドし、Cloudflare PagesやGitHub Pagesに静的ファイルをのせて動かせば十分だと思います。

例えば僕が先日作った個人開発のサービスもReact on Cloudflare Pagesの完全なSPAですが、SSRが必要な要素はまったくありません。

https://zenn.dev/catnose99/articles/eb0e7a51876920

更新頻度が少ないブログのようなものであれば、その都度ビルドするJAMstackの構成で良いと思います。
ただ、ユーザーが投稿できるWebサービスで、ページごとにOGPの設定を切り替えたり、SEO対策を突き詰めたりしたいといったときにはSSRをしたくなることがあります。

そのような「なんやかんやでSSRしたい」そして「SSRのパフォーマンスも意識したい」「コストも抑えたい」というときの選択肢としてRemix on Cloudflare Workersはとても魅力的だと思います。

以下で詳しく書いていきます。

  • 個人開発者目線が強めです。
  • 以下で書いている理由はほぼCloudflare Workersの魅力です。RemixをNuxtやSvelteKitに置き換えても同じことが言えると思います。

1. コールドスタートを抑えるために必要なコストを削減できる

自分は個人開発でいろいろとサービスを作るのが好きなのですが、サービスの構成を考えるときに最も気にかけるのがコスト面です。

個人開発あるあるですが、リリース後にあまり使ってもらえなかったとき、アクティブに開発はしないもののサービスは継続して提供する(つまり放置)ということになりがちです。このようなケースのために、ランニングコストは抑えつつアクセスがあればスムーズにサービスを提供できる形にしておくのがベストです。

例えばアクセスが少ないアプリケーションをHerokuの無料プランで動かす場合、リクエストを受けてからインスタンスが起動し、その結果レスポンスが遅くなる、といった問題にハマったりします。定期実行でリクエストを送ることでスリープモードに入らせないといったテクニックもありますが、設定が面倒ですし、そのぶんだけ無料枠が削られてしまいます。

Cloudflarew Workersでは、公式ブログ(Eliminating cold starts with Cloudflare Workers)に書かれているようにコールドスタートがありません。

1日に10回しかアクセスがないサービスでもコールドスタートによる心配する必要がないというわけです。

2. スケールしてもコストが削減できる

Cloudflare Workersは料金がかなり良心的です。

無料プランでも10万リクエスト/日まで無料で使用できます。実装によりますが、ユーザーが1回サービスにアクセスしたときに1〜3回Workersが走る程度であれば、無料でも相当な数のアクセスを捌くことができると思います。

個人開発者は「流行るか分からないしマネタイズは後回しでとりあえずリリースしちゃおう」みたいなことをやりがちです。そして、ごく稀に想像していた100倍以上アクセスがあるといったことが起きます。だいたいのケースではこのようになりませんが、このような「想像の100倍使われてる〜〜〜」という夢を見て、個人開発をする人は多いと思います。

思ったより使われちゃったパターンに遭遇したときにもCloudflare Workersをメインで(適切に)使っていれば、きっとクラウド破産は避けられると思います。

3. キャッシュが柔軟にやりやすい

Cloudflare WorkersではKVというキーバリューストアの機能を簡単に使用できます。KVでは最大25MBまでの値を高速で読み書きができ、一時的にキャッシュしておきたいHTTPレスポンスや、消えてしまっても構わないようなデータを格納する用途で使うことも可能です。

エッジでSSRをしても外部APIからデータをフェッチしていてはパフォーマンスのメリットは薄れてしまいますが、KVにデータを格納することでAPIリクエストの頻度を減らせるケースもありそうです。

また、静的なページについてはCache-controlヘッダをセットしてCloudflareに長期間キャッシュさせることもできます。Cloudflare Workersならこのあたりのキャッシュ周りの設定を柔軟にできるのが嬉しいです。

Cloudflare Workers + Remix + Supabase は個人開発ではかなり良さそう

Cloudflare Wokersのドキュメントでは(JavaScriptクライアント経由で)SupabaseのPostgreSQLにアクセスする例が紹介されています。

Build data-driven applications with Workers and PostgreSQL

WorkersとSupabaseの組み合わせは低コストでちょっとしたWebサービスを作るには有力な選択肢になりそうです。

Workersでアプリケーションを動かして、SupabaseのPostgreSQLでデータを永続化して、Supabase Authでログイン機能をつけて…というイメージです。PostgreSQLへのアクセスが遅ければクエリの結果をKVにキャッシュすることもできます。

Cloudflare Workersでフルスタックなアプリケーションを動かすときに気をつけた方が良さそうなこと

さて、ここまで良い話ばかりを書いてきましたが、ひとつ大きな懸念点があります。それはCloudflare Workersの厳しい制限です。

https://zenn.dev/catnose99/articles/d1d16e11e7c6d0

中でも

  • scriptのサイズは1MBが上限 [1]
  • scriptは最大30個まで [2]

という点については、サイズの大きいライブラリを使ったり、中〜大規模なアプリを作ればすぐに超えてしまう気がします。例えばfirebase-adminはサイズが結構大きいのですが、Workers上でも使えるのか疑問です(誰か試した人がいれば教えてください)。

個人開発のサービスであっても、リリース後もガンガン機能をつけていきたいのであればCloudflare Workersではすぐに限界がきて移行を強いられるかもしれません。

現時点では「機能が少なくやることは単純だけど大量のアクセスがあるかもしれない」というサービスを作るときに上で挙げたような構成を検討するのが良いかと思います。

(仮に自分がZennのようなサービスを1から作るとしたら、Remix on Cloudflare Workersというスタックにはしないと思います)

脚注
  1. 今後上限が上がりそうです(下のコメント欄を参照) ↩︎

  2. 有料プランなら100までに増加したようです🎉 (下のコメント欄を参照) ↩︎

この記事に贈られたバッジ

Discussion

>scriptのサイズは1MBが上限
>scriptは最大30個まで
先週の発表でScriptは100個までという発表を行いました。
そして2MB以上を利用したい場合は申請ベースでEarly access可能:Link

https://blog.cloudflare.com/workers-now-even-more-unbound/

情報ありがとうございます。すでに申請ベースでサイズ上限が可能というのはとても嬉しいニュースです。script数についてこちらが気になってるのですが、何かご存知でしょうか。

https://twitter.com/catnose99/status/1463475727668416514

回答が遅くなり申し訳ありません。Productチームに確認を行いましたが、script数の100まではWorkers有料プランをご利用の場合となります。Documentに関しては更新状況を確認してますので、少しお待ちいただけますでしょうか?
尚、QiitaさんのほうでAdvent calendarを方を行っておりますので、もしよろしければ、こちらの記事をAdvent calenderに投稿いかがでしょうか? 
Advent calender: Link

ご確認までいただき、ありがとうございます。
なるほどですね。ドキュメントが更新され次第、この記事とLimitに関する記事に修正を加えようと思います。

Cloudflare Workersについては他にも色々と書けそうなので別記事での参加を検討してみます。ありがとうございます。

ログインするとコメントできます