要点: 複数Serviceを跨ぐ業務ActionはDistributed LockではなくDurable Workflowで信頼性を得ます。
課題
決済、在庫、配送、通知は一つのDB Transactionを共有できません。Timeout、Side Effect重複、取消不能な処理が発生します。
単純な対策だけでは不十分な理由
外部SaaSを含む2PCは現実的でなく、Durable Orchestratorは部分完了を通常Stateとして扱います。
Compensationは完全な逆操作でないことがあり、明示Policyが必要です。
処理フロー
Command
Workflow開始→State Machine
Transition永続化→Activity
Idempotent Call→Compensation
業務Recovery
Workflow開始→State Machine
Transition永続化→Activity
Idempotent Call→Compensation
業務Recovery
アーキテクチャ上の判断
重要FlowをOrchestrate
Sequence、Deadline、Support Actionを一元可視化します。
Act前にPersist
Activity前にTransition Intentを保存します。
Semantic Idempotency
Retry Request IDではなくOrderやOperation IDを使います。
さらに深く考える
State MachineはProduct Model
各Stateの顧客向け意味をSupport、Financeと共有します。
Human Workも設計対象
Manual TaskにOwner、Deadline、Evidence、Idempotent Resumeを持たせます。
実装手順
- Business State、Deadline、終端Outcomeを先に定義します。
- 各ActivityにStable Operation IDを付けます。
- CompensationにもFailureとAuditを持たせます。
技術例: Durable Order Workflow
workflow.save(state = 'RESERVING', version = 4)
reservation = inventory.reserve(orderId, operationId)
workflow.save(state = 'CHARGING', reservationId)
charge = payments.charge(orderId, operationId)
workflow.save(state = 'CONFIRMED', chargeId)Replay時はOperation IDで結果を取得し、時刻など非決定値を未記録で再計算しません。
想定すべき障害パターン
- 決済成功Responseが失われます。
- Compensationが失敗し人手判断が必要です。
- 二つのWorkflowが同じAggregateを競合します。
監視すべきシグナル
| シグナル | 確認する理由 |
|---|---|
| State別Workflow Age | 停止Journeyを検出します。 |
| Activity Attempt・Latency | Dependency不安定を示します。 |
| Compensation・Manual率 | 例外Costを示します。 |
設計の検証方法
- 成功後Responseを落とし収束を確認します。
- 全Persist Stateで再起動します。
- Compensation失敗時のAlertと手動解決を確認します。
安全なRollout計画
既存Flowを副作用なしでMirrorしHistoryを比較します。その後Activity単位で移行し、障害訓練完了までFallbackと照合を維持します。
本番前チェックリスト
- HistoryはDurableでReplayはDeterministicです。
- TimeoutはBusiness Deadlineを表します。
- Operatorが安全にRetry・Compensateできます。
まとめ
Sagaは部分進捗を可視化・回復可能にし、分散をAtomicと偽りません。