Cloudflare WorkersかVercelか｜128MB制約で選ぶ用途

Cloudflare Workersは短いグローバルAPIやストリーミングによるファイル配信に向くが、重いNext.jsのSSRではメモリが選択を左右する。無料・有料プランともisolate当たりの上限はCloudflareの制限表にある128MBで、複数のリクエストが同じisolateを使う場合もある。ファイルや大きなJSONを一括で読み込む処理では、応答速度を比べる前に必要なメモリを見極めたい。

重いSSRやNode.jsへの依存が強い処理には、Vercel Functionsが有力だ。Vercel Functionsの公式制限では、Fluid computeのメモリ上限はHobbyで2GB、ProとEnterpriseで4GB。実行時間は既定で300秒、ProとEnterpriseでは通常最大800秒に設定できる。一方、関数のリクエストまたはレスポンス本文には4.5MBの上限があるため、ファイル配信では経路を分けて考える必要がある。

メモリと実行時間は別の制限

Workersのメモリ上限はリクエストごとの専用枠ではない。JavaScriptのヒープに加えてWebAssemblyが使う領域も含まれ、同じisolateが並行して処理するリクエストの影響を受ける。大量のデータを展開するSSRやファイル変換では、処理時間が短くてもメモリを使い切る可能性がある。応答本文を保持せず順に流す構成なら、大きなファイルを扱っても必要なメモリを抑えやすい。

WorkersのCPU時間はコードが実際に計算した時間であり、外部APIやデータベースからの返答待ちは含まれない。有料プランのHTTP処理では既定のCPU時間を長く設定できるが、これは処理全体の経過時間とは違う。HTTPリクエストには一律の経過時間上限がなくても、クライアントが切断すると関連する処理は中断されうる。長い待機を伴う応答と、接続が終わった後も完了させたい仕事は、同じ設計では扱えない。

VercelもFluid computeでは、外部サービスを待つ時間をActive CPUとして計上しない。ただし、確保したメモリの時間は料金に関係し、関数の経過時間には上限がある。長い外部API待ちでは「CPUをほとんど使わない」ことだけで決めず、クライアントが待てる時間、関数のタイムアウト、待機中のメモリ費用を合わせて見る必要がある。

Next.jsではNode.js互換性とキャッシュ運用が効く

Next.jsを既存の構成に近い形で動かすなら、Vercel FunctionsのフルNode.jsランタイムが有利になりやすい。VercelのNext.js比較によると、WorkersではOpenNext Cloudflareアダプターがビルド成果物をworkerd向けに変換し、Node.js APIは互換レイヤーを通る。アプリケーションコードの多くを共有できても、利用するnpmパッケージやNext.js機能の対応状況まで同一になるわけではない。

たとえば、依存パッケージが特定のNode.js APIを使う場合、Workers側の実装状況が動作を左右する。互換レイヤーには完全な実装だけでなく、部分的な実装や機能を持たない代替実装もある。サーバー側のライブラリが多いアプリでは、移行前にパッケージ単位で確認する作業が増える。軽いAPIでも、必要な機能がWorkersのランタイムで動くことが前提だ。

キャッシュにも構成の差がある。VercelではISRや画像最適化をプラットフォームの機能として使える。WorkersでISRを運用する場合は、R2を使う増分キャッシュや再検証の仕組みをアダプターと周辺サービスで設定する。すでにR2、D1、Durable Objectsを利用しているアプリなら同じ基盤にまとめられるが、既存のNext.jsサイトを移す場合は、その構成作業も選択の費用に含めたい。

SSRの順位は測定時期と構成で変わる

RailwayのSSR計測は、先行するテストでCloudflareがVercelより約3～5倍遅かった後、Cloudflare側の改善を経て一部のテストで優位が入れ替わった経緯を記している。Railway自身の測定でも、Next.jsではVercelが1089ms、Cloudflareが1274msだった一方、React SSRではCloudflareが163ms、Vercelが168msだった。同じ「SSR」でも、フレームワークと実装が変われば順位は変わる。

この測定は、素数計算などを含む負荷の高いページを動的に描画したものだ。測定クライアントは米国西部のAWS上に置かれ、Vercelの関数も同じ地域に配置された。日本の利用者から遠隔地のデータベースを参照するアプリや、キャッシュが効いたページの応答時間を直接示す数値ではない。利用者に近い実行地点が効く短いAPIと、データベースとの往復が多いSSRでは、優先する距離も違う。

四つの処理で選択がどう変わるか

用途を分けると、メモリ、互換性、待機時間、転送経路のどれが先に制約になるかが見える。次の選択は処理内容を基準にした出発点であり、外部サービスの配置や依存パッケージによって変わる。

短いグローバルAPIはWorkersを優先。認証確認、ルーティング、軽いデータ整形のように、保持するデータが小さく、利用者が複数地域にいる処理に合う。ただし毎回同じ地域のデータベースを呼ぶなら、利用者に近い実行地点だけでは往復時間を減らせない。データの置き場所が応答時間を支配するなら、関数をデータ側に寄せる配置も候補になる。
重いNext.jsのSSRはVercelを優先。複雑な描画、大きな依存パッケージ、メモリを多く使う変換では、選べるメモリとフルNode.jsランタイムが効く。軽いSSRならWorkersも候補だが、必要なNext.js機能、npmパッケージ、ISRの構成を含めて比べるべきだ。キャッシュされた応答と毎回生成するページを混ぜて速度を比べると、配置の効果を読み違える。
長い外部API待ちは、接続と費用で選ぶ。クライアントとの接続を保ち、計算量が小さい応答なら、待機をCPU時間に含めないWorkersの仕組みが合う。Vercelでも待機中のActive CPUは増えないが、メモリの確保時間と関数の経過時間上限が残る。応答後も確実に続ける必要がある処理は、HTTPリクエストとは別に、両社のワークフローなどを検討する。
大容量ファイル配信はWorkersとR2を優先候補にする。オブジェクトストレージから本文をストリーミングすれば、ファイル全体をisolateのメモリに載せずに済む。Vercelでもストレージから直接配信する経路は検討できるが、関数を大きな本文の通り道にするとペイロード上限が問題になる。配信と、アップロード後に内容を一括解析する処理は、必要なメモリが異なる。

ファイルの「大容量」は、そのまま実行時メモリの大きさを意味しない。配信では本文を順に送り出せても、画像変換や圧縮のために全体を読み込むならメモリを消費する。また、受信するファイルの上限と送信する本文の上限は別だ。ファイルを扱う処理では、保存先だけでなく、関数が本文をどの段階で保持するかが基盤選びを決める。

料金はCPU、待機、保存先を合わせて見る

CloudflareのWorkers料金表では、有料プランの最低料金は月額5米ドルで、月間1000万リクエストと3000万CPUミリ秒を含む。超過分はリクエスト数とCPU時間で計算され、Workersの実行経過時間やデータ転送には追加料金がない。R2を組み合わせる場合は転送帯域の料金はかからない一方、保存容量や操作の料金を別に見積もる必要がある。

Vercel FunctionsのFluid computeでは、呼び出しに加えてActive CPUと確保したメモリの時間が費用の軸になる。同じ呼び出し回数でも、すぐに計算して終わるAPIと、外部サービスを長く待つAPIの費用構造は異なる。メモリを増やせることは重いSSRの余裕につながるが、割り当てを増やしたまま長く実行する設計ではメモリの費用も増える。

配置と料金は切り離せない。各地の利用者へ短い応答を返す処理では、Workersのグローバル配置が生きやすい。一方、SSRが同じデータベースへ何度も問い合わせるなら、関数をそのデータに近づけるほうが応答時間に効く場合がある。処理ごとの必要メモリ、実際のCPU時間、待機時間、ファイルの転送経路を並べると、速度だけでは見えない選択の差がはっきりする。