Cloudflare Service Bindings：遅延0msマイクロサービス

従来のマイクロサービスが支払う隠れた税金：ネットワークホップ

モノリシック（Monolithic）アーキテクチャを独立したサービス（Auth、Payments、Users、Notificationsなど）に分離するマイクロサービス（Microservices）アーキテクチャは、現代のバックエンド設計の標準となりました。各サービスの独立したデプロイ、個別のスケーリング、そして関心の分離（Separation of Concerns）は大いなるメリットをもたらします。

しかし、従来のマイクロサービスアーキテクチャは内部サービス同士で通信する際、深刻なパフォーマンスおよびコストの税金を支払っています。

[API Gateway] 
      | -- (HTTP REST / gRPC 呼び出し) --> DNSルックアップ + TLSハンドシェイク + TCP RTT (15~50ms)
      v
[Auth Service]
      | -- (内部 HTTP REST 呼び出し) --> APIトークン認証 + JSONエンコーディングオーバーヘッド (15~50ms)
      v
[Payment Service]

1. ネットワークレイテンシ（Network Hop）：サービスを分離するたびにDNSルックアップ、TLSハンドシェイク、TCP往復時間が追加され、レイテンシが最小10ms〜50msずつ累積します。
2. 二重課金およびEgress手数料：内部サービス間のHTTP通信も個別のリクエスト（Request）およびデータアウトバウンド（Egress）料金として請求されます。
3. セキュリティの複雑性：内部サービスが外部インターネットに露出しないよう、API Key、OAuthトークン、mTLS、VPCゲートウェイを複雑に管理する必要があります。

Cloudflare Workers Service Bindingsと**Native RPC (WorkerEntrypoint)**は、この3つの問題を一度に解決する次世代サーバーレスオーケストレーション技術です。

Service Bindingsを使用すると、2つ以上の独立したWorkersサービスが通信する際、ネットワークホップが完全に消失し、同一のサーバーレスV8メモリ隔離空間（Isolate）内部でレイテンシ0ms（Sub-millisecond）のインプロセス（In-Process）直接呼び出しが行われます。

この記事では、Service Bindingsのアーキテクチャ原理から、2025/2026年の標準であるWorkerEntrypoint RPCの実践コード、非公開（Private）サービス隔離セキュリティ、そしてベンチマークまで詳細に解説します。

Service Bindings vs 従来のREST/gRPCの比較

Service Bindingsの内部動作原理：In-Process Zero-Hop

Cloudflareは世界300以上のデータセンターにエニキャスト（Anycast）ネットワークを構築しています。

ユーザーからのリクエストが届くと、API Gateway WorkerとバックエンドのAuth Workerが同一のCloudflareエッジデータセンターサーバー（V8エンジン）内で実行されます。この時、2つのサービスをService Bindingsで接続すると、ネットワークカードを経由せずV8 C++メモリレベルで直接マッピングされます。

+-------------------------------------------------------------------------+
| Cloudflare エッジサーバー（単一V8 Engineランタイム）                        |
|                                                                         |
|  [API Gateway Worker]                                                   |
|           |                                                             |
|           |  (Service Binding: Zero Network Hop / 0ms Memory Call)      |
|           v                                                             |
|  [Auth Worker] ----------> [Payment Worker (WorkerEntrypoint RPC)]       |
|                                                                         |
+-------------------------------------------------------------------------+

1. HTTP/TCPプロトコルオーバーヘッド 0：HTTPメソッド・ヘッダーのパース、TLS暗号化、TCPパケット組み立てのプロセスが省略されます。
2. 100%非公開の内部サービス：auth-serviceやpayment-serviceはインターネット公開URL（Route）を持つ必要がありません。外部の入り口であるapi-gatewayを通じてのみ内部への進入が許可されます。
3. 独立したデプロイパイプライン：サービスは内部メモリで接続されますが、コードベースとWranglerデプロイパイプラインは100%独立して分離されており、チームごとに自由にデプロイ可能です。

ステップ1：Native RPC (WorkerEntrypoint) の定義

2025/2026年のCloudflare Workersは、過去のfetch(request)送信方式の代わりに、TypeScript Classメソッドを直接呼び出す**Native RPC (WorkerEntrypoint)**を公式サポートしています。

1. 決済サービス（payment-service）の実装

まず、独立した内部決済マイクロサービスを実装してみましょう。WorkerEntrypointを継承したクラスのpublicメソッドがそのままRPCインターフェースとなります。

// services/payment-service/src/index.ts
import { WorkerEntrypoint } from "cloudflare:workers";

export interface PaymentRequest {
  orderId: string;
  amount: number;
  currency: string;
}

export interface PaymentResponse {
  success: boolean;
  transactionId: string;
  processedAt: number;
}

// WorkerEntrypointを継承して外部RPCメソッドを公開
export class PaymentService extends WorkerEntrypoint {
  // RPCメソッド 1: 決済承認演算
  async processPayment(req: PaymentRequest): Promise<PaymentResponse> {
    console.log(`[PaymentService] Processing order: ${req.orderId} for amount: ${req.amount}`);

    // 内部決済承認演算（DB照会および暗号化）
    const transactionId = `tx_${crypto.randomUUID().slice(0, 8)}`;
    
    return {
      success: true,
      transactionId,
      processedAt: Date.now(),
    };
  }

  // RPCメソッド 2: 返金処理
  async refundPayment(transactionId: string): Promise<boolean> {
    console.log(`[PaymentService] Refunding transaction: ${transactionId}`);
    return true;
  }
}

// 公開HTTPハンドラーを持たない純粋な非公開サービスの場合
export default {
  async fetch() {
    return new Response("Unauthorized - Internal RPC Service Only", { status: 403 });
  },
};

payment-serviceのwrangler.jsonc設定：

// services/payment-service/wrangler.jsonc
{
  "$schema": "../../node_modules/wrangler/config-schema.json",
  "name": "payment-service",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01",
  "compatibility_flags": ["nodejs_compat"]
  // routesの登録なし！ -> 外部インターネットから絶対直接アクセス不可
}

2. 認証サービス（auth-service）の実装

// services/auth-service/src/index.ts
import { WorkerEntrypoint } from "cloudflare:workers";

export interface UserSession {
  userId: string;
  role: "admin" | "user";
  isValid: boolean;
}

export class AuthService extends WorkerEntrypoint {
  // トークン検証RPCメソッド
  async verifyToken(token: string): Promise<UserSession> {
    if (!token || !token.startsWith("Bearer ")) {
      return { userId: "", role: "user", isValid: false };
    }

    const rawToken = token.replace("Bearer ", "");
    // JWTまたはKVセッション検証ロジック
    if (rawToken === "secret-admin-token") {
      return { userId: "usr_admin_01", role: "admin", isValid: true };
    }

    return { userId: "usr_regular_99", role: "user", isValid: true };
  }
}

export default {
  async fetch() {
    return new Response("Access Denied", { status: 403 });
  },
};

ステップ2：API GatewayでのService Bindings接続およびRPC呼び出し

次に、外部からのリクエストを受け取る公開メインサービス（api-gateway）で、上で作成した2つのマイクロサービスをService Bindingsでバインドし、RPCを呼び出してみましょう。

api-gatewayのwrangler.jsonc設定

services配列を宣言してバインディング名と対象のWorkerサービス名を接続します。

// services/api-gateway/wrangler.jsonc
{
  "$schema": "../../node_modules/wrangler/config-schema.json",
  "name": "api-gateway",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01",
  "compatibility_flags": ["nodejs_compat"],

  // Service Bindings宣言
  "services": [
    {
      "binding": "AUTH_SERVICE",
      "service": "auth-service"
    },
    {
      "binding": "PAYMENT_SERVICE",
      "service": "payment-service"
    }
  ]
}

api-gatewayエントリポイントの実装（Hono.jsベース）

// services/api-gateway/src/index.ts
import { Hono } from "hono";
// 型安全性のために各サービスのWorkerEntrypointクラス型をインポート
import type { AuthService } from "../../auth-service/src/index";
import type { PaymentService } from "../../payment-service/src/index";

type Env = {
  Bindings: {
    // ServiceBinding型定義
    AUTH_SERVICE: Service<AuthService>;
    PAYMENT_SERVICE: Service<PaymentService>;
  };
};

const app = new Hono<Env>();

// 決済リクエストルート
app.post("/api/v1/checkout", async (c) => {
  const authHeader = c.req.header("Authorization") ?? "";
  
  // 1. Auth Service RPCの直接呼び出し（ネットワークホップ0ms！）
  // fetch()の代わりにc.env.AUTH_SERVICE.verifyToken()メソッドをそのまま実行
  const session = await c.env.AUTH_SERVICE.verifyToken(authHeader);

  if (!session.isValid) {
    return c.json({ error: "Unauthorized access" }, 401);
  }

  const body = await c.req.json();

  // 2. Payment Service RPCの直接呼び出し（レイテンシ0msおよび型サポート）
  const paymentResult = await c.env.PAYMENT_SERVICE.processPayment({
    orderId: body.orderId,
    amount: body.amount,
    currency: "USD",
  });

  return c.json({
    message: "Checkout successful",
    user: session.userId,
    payment: paymentResult,
  });
});

export default app;

c.env.AUTH_SERVICE.verifyToken()が通常のTypeScript関数と同じように呼び出されている点に注目してください！fetch()も、JSON bodyのパースコードも不要で、ネットワークシリアライズのレイテンシは完全にゼロです。

ステップ3：ローカル開発およびマルチサービス・テスト（wrangler dev）

Cloudflare Wrangler v3/v4は、複数の独立したWorkerサービスをローカルで同時に起動し、Service BindingsをテストできるMulti-Worker Dev Modeをサポートしています。

ローカルテストコマンド

# 1. Terminal A: auth-service実行
cd services/auth-service
npx wrangler dev

# 2. Terminal B: payment-service実行
cd services/payment-service
npx wrangler dev

# 3. Terminal C: api-gateway実行（ローカルでService Bindingsが自動接続される）
cd services/api-gateway
npx wrangler dev

api-gatewayへHTTP POSTリクエストを送信すると、ローカルのターミナルA、B、Cで各サービスがインプロセス（In-Process）でわずか0.1msで相互作用する様子を確認できます。

ベンチマーク：従来のHTTP REST vs Service Bindings RPC

同一の3段階マイクロサービス連鎖呼び出し（Gateway -> Auth -> Payment）時における応答速度とリソース使用量をベンチマークしました。（10,000回リクエスト平均）

実践アーキテクチャパターン：Service Bindingsモジュール化パターン

Service Bindingsを活用すると、大型エンタープライズモノレポ（Monorepo）やドメイン駆動設計（DDD）のアーキテクチャを容易に構築できます。

my-enterprise-app/
├── package.json
├── node_modules/
└── services/
    ├── api-gateway/       (公開エントリポイント / Hono.js)
    ├── auth-service/      (認証 & セッション RPC)
    ├── billing-service/   (Stripe & 決済 RPC)
    ├── email-service/     (Resend / メール送信 RPC)
    └── ai-agent-service/  (Llama 3 / Workers AI RPC)

各サービスチームは自身のservices/xxxフォルダ内で独自に開発およびテスト（npx wrangler deploy）を進め、API Gatewayチームは必要なサービスのBindingのみをwrangler.jsoncに取り込んで安全にオーケストレーションします。

結論：遅いマイクロサービスの時代を終わらせる

これまでマイクロサービスアーキテクチャは、「開発の利便性を得る代わりにパフォーマンスとネットワークコストを妥協する」というトレードオフの上に成り立ってきました。

Cloudflare WorkersのService Bindingsと**WorkerEntrypoint RPC**はこの矛盾を完全に解決します。

1. レイテンシ0ms：ネットワークホップが消失し、単一V8エンジンメモリ上で直接呼び出されます。
2. コスト$0：マイクロサービス間の内部データ移動に対するEgress手数料がありません。
3. 100%の型安全性：TypeScript Classインターフェースをそのまま使用し、ランタイムの型エラーを完全に防止します。
4. 強力なエッジセキュリティ：内部サービスはパブリックインターネットに露出しない完全な非公開（Private）状態を維持します。

今すぐバックエンドマイクロサービスの遅いHTTP REST通信をService Bindings RPCへ移行し、0msの驚異的な応答速度を体験してみましょう。

関連記事：Cloudflare Workers OpenTelemetry：OTLPでオブザーバビリティコスト90%削減でモニタリングパイプライン構築ガイドもあわせて確認できます。