第36章: プロセス間通信(IPC)とオーケストレーション(Queues / Workflows)
UNIXオペレーティングシステムにおいて、単機能で軽量なプロセス群を結合して巨大な処理を実現する根幹の仕組みが IPC(Inter-Process Communication:プロセス間通信) です。パイプ(|)、共有メモリ、シグナル、メッセージキューなどがこれにあたります。
Cloudflare OS においても、独立して動作する数万・数百万のWorkersプロセスを疎結合に結びつけ、堅牢なデータパイプラインや多段バッチ処理を構築するためのIPCプリミティブが完備されています。
本章では、CloudflareのIPC中核技術である Service Bindings、Cloudflare Queues、そして長期実行ステートマシンを実現する Cloudflare Workflows のアーキテクチャを解読します。
1. OSのIPCとCloudflareの通信プリミティブの対比
| 従来のOS概念 | 役割 | Cloudflare OSの対応技術 | 特徴 |
|---|---|---|---|
| UNIXドメインソケット | 同一マシン内の高速ローカルプロセス間通信 | Service Bindings | ネットワークスタックをバイパスし、メモリ間ゼロコピーでWorkerを相互呼び出し |
| メッセージキュー (IPC Queue) | プロセス間の非同期メッセージバッファリング | Cloudflare Queues | 流量制御(バックプレッシャー)、自動リトライ、デッドレターキュー(DLQ) |
| cron / systemd timer | 定期実行スケジューラ | Cron Triggers | 分散クロノスによるミリ秒精度の定期ジョブ起動 |
| プロセス管理デーモン / cronタスク | 長時間処理・状態遷移・失敗時レジューム | Cloudflare Workflows | 各ステップの状態を自動永続化し、数時間〜数日に及ぶワークフローを確実に完走 |
2. Service Bindings:ネットワークスタックをパススルーするゼロコピー通信
Worker AからWorker Bを呼び出す際、パブリックインターネットを経由してHTTPSリクエストを送信すると、DNS解決、TLSハンドシェイク、HTTPシリアライズのオーバーヘッドが発生します。
Service Bindings は、同一データセンター内のV8 Isolates間でメモリ参照を直接受け渡すような超高速IPCを提供します。
sequenceDiagram
autonumber
participant Client as 外部クライアント
participant Gateway as API Gateway (Worker A)
participant Auth as 内部認証サービス (Worker B)
participant Billing as 課金エンジン (Worker C)
Client->>Gateway: HTTPSリクエスト
Note over Gateway,Auth: Service Bindings (ゼロコピー・内部呼び出し)
Gateway->>Auth: c.env.AUTH_SERVICE.fetch() (レイテンシ < 1ms)
Auth-->>Gateway: トークン検証結果
Gateway->>Billing: c.env.BILLING_SERVICE.fetch() (レイテンシ < 1ms)
Billing-->>Gateway: 残高引当完了
Gateway-->>Client: HTTP 200 OK
# wrangler.toml (Worker Aの設定)services = [ { binding = "AUTH_SERVICE", service = "auth-microservice" }, { binding = "BILLING_SERVICE", service = "billing-microservice" }]3. Cloudflare Queues:背圧制御と耐障害性をもつメッセージキュー
大量のトラフィックが急増した際、バックエンド(外部APIやデータベース)のパンクを防ぐバッファとして機能します。
export default { async fetch(req: Request, env: Env): Promise<Response> { const payload = await req.json();
// キューへエンキュー(OSのwrite()やmsgsnd()に相当) await env.LOG_QUEUE.send(payload, { contentType: 'json' });
return new Response('Accepted', { status: 202 }); }};export default { async queue(batch: MessageBatch<any>, env: Env): Promise<void> { // 複数メッセージをバッチ処理 for (const message of batch.messages) { try { await processEvent(message.body); message.ack(); // 正常処理の確認応答 } catch (err) { message.retry(); // 失敗時の自動リトライ } } }};4. Cloudflare Workflows:エッジ上の分散ステートマシン
数秒でタイムアウトするステートレスなFaaSの弱点を克服するのが Workflows です。
処理のステップごとに状態が自動的に永続化(チェックポイント)されるため、ノード障害やタイムアウトが発生しても、最後に成功したステップから瞬時に再開(Resume)できます。
import { WorkflowEntrypoint, WorkflowStep, WorkflowEvent } from 'cloudflare:workers';
type OrderParams = { orderId: string; amount: number; userId: string };
export class OrderProcessingWorkflow extends WorkflowEntrypoint<Env, OrderParams> { async run(event: WorkflowEvent<OrderParams>, step: WorkflowStep) { const { orderId, amount, userId } = event.payload;
// ステップ1: クレジットカード決済 (失敗時は3回リトライ) const payment = await step.do( 'charge-credit-card', { retries: { limit: 3, delay: '5 seconds', backoff: 'exponential' } }, async () => { return await externalPaymentApi.charge({ userId, amount }); } );
// ステップ2: 外部の在庫引当完了を待機 (最大24時間スリープ可能) await step.sleep('wait-for-warehouse', '1 hour');
// ステップ3: 配送指示と完了メール送信 await step.do('send-fulfillment-email', async () => { await sendShippingEmail(userId, orderId); return { status: 'SHIPPED' }; }); }}5. まとめ:OSとしての協調動作
Cloudflare OS上でのモダンなアプリケーションは、以下のように協調動作します:
- Service Bindings で同期的なマイクロサービス呼び出しを最速化(同期的IPC)。
- Queues でスパイクを平滑化し、非同期バッチ処理へ安全に配送(非同期的バッファ)。
- Workflows で数日間に及ぶビジネスロジックの耐久性とトランザクション整合性を保証(オーケストレーション)。
これらすべてが単一のCLI(wrangler)と同一の言語ランタイム(TypeScript)でシームレスに結合されます。
💡 用語解説コラム
[!NOTE] IPC(Inter-Process Communication:プロセス間通信) 複数のプロセス間でデータやメッセージをやり取りするためのOSの機能。共有メモリ、パイプ、シグナル、メッセージキューなどがある。Cloudflare OSでは、Service Bindingsが「共有メモリ/ローカルソケット」に、Cloudflare Queuesが「OSメッセージキュー」に相当します。
[!NOTE] 耐久的実行(Durable Execution) 障害やノード再起動、ネットワーク切断が発生しても、コードの実行状態(コールスタック、変数、進行度)を永続化し、中断した箇所から正確に再開する実行モデル。Cloudflare Workflowsがこれをエッジ上でネイティブに実現しています。