コンテンツにスキップ

第34章: コンピュート&スケジューラ(workerdとV8)

Cloudflare OSにおいて、プログラムを実行する「CPU」とタスクを割り振る「カーネルスケジューラ」の役割を果たしているのが、オープンソースのJavaScript/WebAssemblyランタイム workerd です。


1. workerd の設計思想:なぜNode.jsではないのか?

従来のサーバーサイド開発では Node.js が主流でしたが、Cloudflare Workers はあえて Node.js を使わず、ブラウザと同じ Web標準API(Fetch, Streams, Web Crypto) をベースにした workerd を独自開発しました。

比較項目従来の Node.js / DockerCloudflare OS (workerd)
起動時間(コールドスタート)数百ms 〜 数秒0ms 〜 5ms 以下
メモリ消費量(1インスタンス)30MB 〜 100MB以上数KB 〜 数MB
並行実行モデル1プロセス / 1コンテナ単一プロセス内で数万個のIsolateが共存
基盤API独自API (fs, http, net)Web標準API (fetch, crypto, ReadableStream)

単一の物理サーバー内で、数万ユーザーのコードを相互に安全に分離しながら、圧倒的な密度とスピードで並行実行できます。


2. スケジューラの仕組み:CPU時間 vs Wall Clock時間

Cloudflare OSでの課金や制限を理解する上で最も重要なのが 「CPU時間」「Wall Clock(実経過時間)」 の違いです。

【リクエスト処理のタイムライン】
[ 開始 ] ──(計算: 2ms)──> [ fetch()外部API待機: 300ms ] ──(JSON解析: 3ms)──> [ 終了 ]
│<────────────────────── Wall Clock 時間: 305ms ───────────────────────>│
│<─── CPU時間: 5ms ───>│ │<─── CPU時間 ───>│
  • CPU時間: 実際にWorkerのコード(JavaScript/Wasm)がCPUコアを専有して計算を行った時間。
  • Wall Clock時間: 外部APIやデータベース、R2のレスポンスを待っているネットワーク待機時間を含めた全体の経過時間。

[!TIP] 無料枠・課金の真実
Cloudflare Workersの「CPU時間制限(無料枠10ms、有料プラン50ms〜)」は、外部通信の待ち時間(Wall Clock時間)を含みません。 そのため、外部APIの応答に5秒かかっても、Worker内の計算処理が5ms以内であれば無料枠の範囲内で安全に動作します。


3. ctx.waitUntil による非同期バックグラウンド処理

Cloudflare OSのスケジューラは、レスポンスをクライアントに返却した後でも、バックグラウンドで処理を継続させる ctx.waitUntil を提供しています。

export default {
async fetch(req: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
// 1. クライアントへは即座に応答を返す(UX最優先)
const response = new Response("受付完了", { status: 200 });
// 2. ログ集計や通知処理はレスポンス返却後に非同期でバックグラウンド実行
ctx.waitUntil(
sendAnalyticsToDatabase(req)
);
return response;
}
};

これにより、ユーザー体感速度を1ミリ秒も落とすことなく、後続タスクをスケジューラに委譲できます。


💡 用語解説コラム

[!NOTE] workerd (ワーカーディー)
Cloudflareが開発・公開しているオープンソースの分散Web標準ランタイム。Cloudflare Workers本番環境とローカル開発環境(Wrangler dev / Vitest)の両方で同一のバイナリが動作します。

[!NOTE] Wall Clock Time (実経過時間)
壁の時計が刻む実際の時間。ネットワーク待機やI/O待ち時間を含みます。Cloudflare OSではCPU時間とWall Clock時間が明確に分離してスケジューリングされます。