ランタイムの深掘り

サーバーサイド JavaScript の歴史は、長らく Node.js のアーキテクチャと同一視されてきた。しかしエッジコンピューティングの要求する「極小の起動時間」「極めて高い収容密度」「安全なマルチテナント分離」の前に、Node.js の前提構造は大きな足枷となる。

Cloudflare Workers を支える V8 isolate が何を削ぎ落とし、何を残したのかを理解することで、エッジにおける正確な設計判断が可能になる。

プロセスモデルと分離アーキテクチャの根本差

Node.js は、既定では 1 つの OS プロセスに対して 1 つの V8 インスタンス（isolate）を割り当てる。worker_threads を使うと同じプロセスに isolate を増やせるが、isolate ごとに libuv のイベントループが 1 つ付く。その外側には、libuv のスレッドプールとソケットの管理機構が張り巡らされている。この構造は 1 つのプロセスを永続的に常駐させることを前提としており、リクエストごとにプロセスを新設・破棄する運用には向かない。

[Node.js のプロセス構造]
OS プロセス ── libuv (C / スレッドプール / ファイル I/O / ネットワークソケット)
             └── 単一の V8 インスタンス (全リクエストでヒープ・状態を共有)

[Workers の isolate 構造]
ランタイムのプロセス ── 分離境界 (メモリ保護・権限サンドボックス)
                      ├── isolate A (ユーザー A のヒープ / 独立メモリ空間)
                      ├── isolate B (ユーザー B のヒープ / 独立メモリ空間)
                      └── isolate C (ユーザー C のヒープ / 独立メモリ空間)

Cloudflare Workers は、OS プロセスのレイヤーを隠蔽し、V8 isolate 単体を実行の基本単位として扱う。ランタイムの 1 インスタンスは、メモリ空間が互いに分離された数百から数千の isolate を切り替えながら動かせる。

isolate の外のメモリへ触れることは、V8 が防ぐ。Cloudflare はそれに加えて、Linux の namespace と seccomp でプロセスからファイルシステムとネットワークへのアクセスを禁じ、信頼度の異なる Worker を別のランタイムインスタンスに分けている。V8 にもバグはあるため、Cloudflare は修正パッチの公開から本番への配備までを 24 時間未満に収めている。

コンテナと isolate の起動時間

コンテナ（Docker 等）の起動には、コンテナイメージのレイヤー展開、Linux 名前空間（Namespace）の初期化、仮想ネットワークインターフェースの構成、そしてゲストプロセスの起動という一連のステップが要る。Cloudflare Containers では、各インスタンスが専用のカーネルを持つ Firecracker の microVM の中で動き、コールドスタートは 1 〜 3 秒程度のことが多い（イメージの大きさやコードによって変わる）。

これに対し、isolate は動作中のランタイムの中に作るだけで済み、プロセスも仮想マシンも起動しない。Cloudflare は、isolate がコンテナや仮想マシン上の Node プロセスより約 100 倍速く起動できると説明している。ただし Worker のコールドスタートには、スクリプトの取得、コンパイル、トップレベルの実行が含まれる。スクリプトが大きく、トップレベルの処理が重いほど長くなる。起動時間には 1 秒の上限がある。

アーキテクチャの選定境界

Node.js 向けのライブラリを持ち込む際は nodejs_compat 互換フラグを使う。互換日付（compatibility date）が 2026-08-04 以降の Worker では、このフラグが既定で有効になる。Buffer、crypto、events に加えて、process、node:fs、node:http、node:net、node:zlib などが組み込まれており、child_process のように import だけできて動かないモジュールもある。ただし node:fs の実体はメモリ上の仮想ファイルシステムで、書き込める /tmp はリクエストごとの一時領域である。永続的なローカルディスクを前提にした設計は成り立たない。