分散トランザクション - 整合性を保つ設計パターン

分散トランザクションの課題

マイクロサービスでは、1つのビジネス操作が複数のサービスにまたがることがあります。各サービスは独自のデータベースを持つため、従来のACIDトランザクションが使えません。

flowchart LR
    Order["1. 注文サービス<br/>注文を作成"]
    Inventory["2. 在庫サービス<br/>在庫を減らす"]
    Payment["3. 決済サービス<br/>支払いを処理"]
    Shipping["4. 配送サービス<br/>配送を手配"]

    Order --> Inventory --> Payment --> Shipping

    Question["❓ どこかで失敗したら？<br/>全体をロールバック？"]

2相コミット（2PC）

すべての参加者が準備完了してから、一斉にコミットするプロトコルです。

sequenceDiagram
    participant C as コーディネーター
    participant A as 参加者A
    participant B as 参加者B

    C->>A: 1. Prepare
    C->>B: 1. Prepare
    A-->>C: 2. Ready
    B-->>C: 2. Ready
    C->>A: 3. Commit
    C->>B: 3. Commit
    A-->>C: 4. Done
    B-->>C: 4. Done

2PCの問題点

現代のマイクロサービスでは2PCは推奨されません

Sagaパターン

長時間のトランザクションを、一連のローカルトランザクションに分割します。失敗時は補償トランザクションでロールバックします。

flowchart LR
    subgraph Normal["正常フロー"]
        T1["T1<br/>注文作成"] --> T2["T2<br/>在庫確保"] --> T3["T3<br/>決済"] --> T4["T4<br/>配送手配"]
    end

flowchart LR
    subgraph Failure["失敗時（T3で失敗）"]
        T1b["T1"] --> T2b["T2"] --> T3b["T3<br/>❌ 失敗"] --> C2["C2<br/>在庫戻し"] --> C1["C1<br/>注文キャンセル"]
    end

オーケストレーション方式

中央のオーケストレーターがSagaを制御します。

class OrderSaga {
  async execute(orderData) {
    const sagaId = uuid();
    let currentStep = 0;

    try {
      // Step 1: 注文作成
      const order = await orderService.create(orderData);
      currentStep = 1;

      // Step 2: 在庫確保
      await inventoryService.reserve(order.items);
      currentStep = 2;

      // Step 3: 決済
      await paymentService.process(order.total);
      currentStep = 3;

      // Step 4: 配送手配
      await shippingService.schedule(order);
      currentStep = 4;

      return { success: true, orderId: order.id };

    } catch (error) {
      // 補償トランザクションを実行
      await this.compensate(currentStep, order);
      throw error;
    }
  }

  async compensate(step, order) {
    if (step >= 3) await paymentService.refund(order.id);
    if (step >= 2) await inventoryService.release(order.items);
    if (step >= 1) await orderService.cancel(order.id);
  }
}

コレオグラフィ方式

各サービスがイベントを発行・購読して協調します。

flowchart TB
    subgraph Success["正常フロー"]
        OS1["注文サービス"] --> E1["OrderCreated"]
        E1 --> IS1["在庫サービス"] --> E2["InventoryReserved"]
        E2 --> PS1["決済サービス"] --> E3["PaymentProcessed"]
        E3 --> SS1["配送サービス"] --> E4["ShippingScheduled"]
    end

flowchart TB
    subgraph Failure["失敗時"]
        PS2["決済サービス"] --> EF1["PaymentFailed"]
        EF1 --> IS2["在庫サービス"] --> EF2["InventoryReleased<br/>(補償)"]
        EF2 --> OS2["注文サービス"] --> EF3["OrderCancelled<br/>(補償)"]
    end

比較

補償トランザクション

失敗時にロールバックする代わりに、逆の操作を実行します。

// 元の操作
async function reserveInventory(items) {
  for (const item of items) {
    await db.inventory.update({
      where: { productId: item.productId },
      data: { quantity: { decrement: item.quantity } }
    });
  }
}

// 補償トランザクション
async function releaseInventory(items) {
  for (const item of items) {
    await db.inventory.update({
      where: { productId: item.productId },
      data: { quantity: { increment: item.quantity } }
    });
  }
}

補償の考慮点

すべての操作が補償可能とは限らない:

Outboxパターン

データベース更新とイベント発行を確実に行います。

// 1. トランザクション内で両方を実行
async function createOrder(orderData) {
  await db.transaction(async (tx) => {
    // ビジネスデータを保存
    const order = await tx.orders.create(orderData);

    // outboxテーブルにイベントを保存
    await tx.outbox.create({
      eventType: 'OrderCreated',
      payload: JSON.stringify(order),
      status: 'pending'
    });
  });
}

// 2. 別プロセスでoutboxをポーリング
async function publishOutboxEvents() {
  const events = await db.outbox.findMany({
    where: { status: 'pending' }
  });

  for (const event of events) {
    await messageQueue.publish(event.eventType, event.payload);
    await db.outbox.update({
      where: { id: event.id },
      data: { status: 'published' }
    });
  }
}

結果整合性

即座の整合性ではなく、最終的に整合性が取れることを許容します。

結果整合性の対処

// UI側での対応例
async function placeOrder(orderData) {
  const result = await api.createOrder(orderData);

  // 即座に確定ではなく「処理中」として表示
  return {
    orderId: result.orderId,
    status: 'processing',
    message: 'ご注文を受け付けました。確定後にメールでお知らせします。'
  };
}

まとめ

分散トランザクションは、マイクロサービスアーキテクチャにおける難しい課題です。2PCは現代の分散システムには適さず、Sagaパターンと補償トランザクションが推奨されます。結果整合性を受け入れ、ビジネス要件に合った整合性モデルを選択することが重要です。