Cloudflare Workers は、世界中のエッジロケーションでコードを走らせるサーバーレス基盤だ。「ユーザーに物理的に近い場所で実行される」ことが他のサーバーレスとの本質的な違いで、リクエスト変換やルーティング、軽い API ゲートウェイのような用途で遅延が目に見えて縮む。
設計の前提を理解する
Workers は通常の Node.js ランタイムではなく、V8 アイソレートという軽量な実行環境で動く。起動が速くコールドスタートがほぼ無視できる代わりに、CPU 時間に上限がある。重い計算や長時間のバッチには向かず、リクエストを受けて素早く返す処理が本領だ。
ストレージは Workers 単体では持たず、用途で使い分ける。
- KV: 読み取りが速い結果整合性のキーバリュー。設定値やキャッシュ向き
- D1: SQLite ベースのリレーショナル DB
- R2: S3 互換のオブジェクトストレージ。下り転送料がかからない
AWS Lambda との使い分け
同じサーバーレスでも Lambda とは守備範囲が違う。Lambda は実行時間やメモリの上限が大きく、重いバッチや既存の Node エコシステムをそのまま動かす用途に強い。Workers は実行は軽量に制限される代わりに、エッジ分散と起動の速さで勝つ。「特定リージョンで重い処理を回す」なら Lambda、「世界中のユーザーに近い場所で軽い処理を返す」なら Workers、という切り分けが現実的だ。
料金とつまずき
無料枠は日間 10 万リクエスト。有料は月額基本料にリクエスト数と CPU 時間の従量が乗る。最初のつまずきは「普通のサーバーのつもりで書くと動かない」ことで、ファイルシステムや一部の Node API が使えない。npm パッケージも、Node 固有 API に依存するものはそのまま動かないことがある。Wrangler CLI でローカル実行を試しながら、エッジ環境の制約に合わせて書く前提で臨むとよい。
標準的な Node.js のコードは動かないことがある
Workers は V8 の隔離環境で動くため、Node.js のランタイム API をすべて使えるわけではない。ファイルシステムへのアクセスや一部のネイティブモジュールに依存したライブラリは動かない。互換性のための仕組みは用意されているが、既存の Node.js アプリをそのまま移植する発想だと詰まる。Web 標準の API（fetch、Web Crypto、Streams）で書かれたコードほど素直に動く。
制限されるのは CPU を実際に使った時間で、外部 API の応答待ちのような待機時間は含まれません。つまり重い計算処理には向かない一方、外部への問い合わせを束ねるような用途には向きます。この違いを理解しないと、なぜ制限に引っかかるのかが分からなくなります。
エッジで動くことの副作用
リクエストが世界中のエッジで処理されるため、実行場所が固定されない。データベースが特定リージョンにある構成だと、エッジからそこまでの往復が毎回発生し、かえって遅くなることがある。Workers の利点を活かすには、エッジ側で完結できる処理（認証チェック、リダイレクト、キャッシュ制御、A/B 振り分け）に寄せるか、エッジ near のデータストア（KV、D1、R2）と組み合わせる設計が要る。