1. イントロダクション
マイクロサービス環境では、分散トランザクション制御は避けて通れません。特に Sagaパターン は、分散システムで 可用性 と 一貫性 のバランスをとりつつビジネス処理を完遂する代表的手法です。本稿では 3 方式をアーキテクト視点で比較し、選定と改善の実務指針を提示します。
- Choreography Pattern
- Orchestration Pattern
- Single Pessimistic Pattern（Fail Fast 型）
2. 各パターンの要約
2.1 Choreography
イベント駆動。各サービスがイベントを購読し、状態遷移と補償トランザクションを自律的に実行。中央制御が不要なため疎結合・拡張性が高い。一方で全体フローの俯瞰が難しく、過度なイベント連鎖（“イベント・スパゲッティ”）のリスクがある。
2.2 Orchestration
専用オーケストレータが Saga の進行・分岐・補償を統制。監査性・可観測性・手続き的明確さが強み。一方で制御プレーンのボトルネック化／集中障害点（SPOF）化やスケール対応コスト増が課題。
2.3 Single Pessimistic (Fail Fast)
悲観的方式（例: 競合チェックやロック）で早期に失敗を返すモデル。高スループット下でもレイテンシを最小化しやすいが、“成功率” だけでは価値を測りにくく、ワークロード特性（競合度・ホットキー偏在）との適合が成否を左右する。
3. 実験設計の概要
- 対象パターン: Choreography / Orchestration / Single Pessimistic
-
収集メトリクス:
e2e_latency/convergence_events/saga_steps/load_phase_results - 負荷プロファイル: Light / Medium / Heavy（RPS増加・競合率上昇）
- 評価軸（一次）: 平均/中央値/ p95 / p99 レイテンシ, 失敗率, 収束時間, 補償イベント発生頻度
- 評価軸（二次）: 実装複雑度, 運用コスト, デバッグ容易性, スケール戦略
4. 分析結果サマリ（プレースホルダ）
4.1 レイテンシ分布
Single Pessimistic は中央値まで最速、Choreography は中庸かつ安定、Orchestration は高分位 (p95/p99) で尾が伸び集中制御がボトルネック化。SLO 設計では “中央値” より “尾部” 改善の優先度差が明確。
4.2 失敗率と補償イベント
Single Pessimistic は失敗率高めでも補償コスト低、Orchestration は失敗抑制と引き換えに補償集中リスク、Choreography は分散するが監視遅れると補償増を見逃しやすい。補償/成功比が “整合性税” 指標。
4.3 Response Timeヒートマップ
負荷増で Orchestration が顕著に劣化、Single Pessimistic は増加率が緩やか、Choreography は漸進的。重負荷下の色濃度差がボトルネックの性質（中央集約 vs 分散イベント vs ロック衝突潜在）を示唆。
4.4 Throughputとthroughput_effect棒グラフ
Raw が伸びても throughput_effect が追随しないパターンは失敗/補償オーバーヘッド増。Single Pessimistic はギャップ拡大しやすく、Orchestration は安定効率、Choreography は中間。効率比(throughput_effect / raw) が早期劣化警報に有効。
5. 詳細考察（アーキテクト視点）
5.1 レイテンシ特性
- Single Pessimistic: 最短（ネットワーク往復 + 最小ローカル処理）。失敗（即時リジェクト）を遅延した成功より安価とみなす前提。
- Choreography: 中庸。イベント非同期伝搬が局所遅延を平滑化する一方、連鎖長と再試行が p95/p99 を押し上げる。
- Orchestration: Heavy 負荷下で遅延が顕在化。オーケストレータ待ち行列と同期呼び出しカスケードがボトルネック。
5.2 信頼性と補償
- Choreography / Orchestration: 補償手順が明示化され失敗率 <1%（想定）。
- Single Pessimistic: 高失敗率でも “Fail Fast” が前提。健全性は有効処理あたりCPU秒・公平度など別指標で評価。
5.3 性能劣化要因（特に Orchestration）
| 要因 | メカニズム | 改善余地 |
|---|---|---|
| シリアル化 | ステップ間同期 + 中央制御 | 並列ブランチ化 / 非同期化 |
| 状態保持コスト | Sagaインスタンス状態の集中管理 | 状態分散 / Event Sourcing + キャッシュ |
| I/O 待ち | 外部サービス依存呼び出し直列化 | Bulkhead / Timeout最適化 / CircuitBreaker |
| オーバーヘッド | 汎用フレームワーク層 | 軽量実装 / gRPC + バイナリプロトコル化 |
5.4 Choreography のスケール観点
- 良い点: 新サービス追加は購読登録のみ → 組織スケール容易
- 課題: 監査（誰が何をどの順序で）が後追いになりやすく分散トレーシング前提。
- 設計要点: 1イベント=1責務 / 冪等キー / 再送 + DLQ / スキーマバージョン管理。
5.5 Single Pessimistic の適用境界
- ロック粒度が粗いとドロップ率↑ → 事前パーティショニング必須
- ホットスポット偏在時はシャーディング再配置コストが顕著
- “成功率” より “平均待ち行列長” “衝突率勾配” を SLO 指標化
6. 実務的インプリケーション（最終）
6.1 意思決定フレーム
選定マトリクス（要件 vs パターン適合度）
| 要件/特性 | Choreography | Orchestration | Single Pessimistic | 補足判断指標 |
|---|---|---|---|---|
| 開発組織スケール（チーム数増） | ◎ | ○ | △ | 自律性最大化ならChoreography |
| 可観測性/監査 | △ | ◎ | ○ | 規制/監査要件でOrchestration優位 |
| 初期実装スピード | ○ | △ | ◎ | Fail Fastは範囲限定 |
| レイテンシ最小化（p95重視） | ○ | △ | ◎ | 競合が低〜中で効果大 |
| 競合ホットスポット頻度 | ○ | ○ | △ | ロック競合に弱い |
| 補償手順の一元統制 | △ | ◎ | △ | 中央定義可能性 |
| サービス追加頻度 | ◎ | ○ | △ | イベント購読追加のみ |
| ガバナンス/変更承認 | △ | ◎ | ○ | フロー定義集約 |
| 並列/分岐制御複雑度 | ○ | ◎ | △ | DSL/ワークフロー機能 |
| 学習コスト | ○ | △ | ◎ | ドメインイベント設計負荷 |
| Fail Fast 許容度 | ○ | ○ | ◎ | ビジネス拒否=正常扱い |
凡例: ◎=強く適合 / ○=適合 / △=注意 / ×=不適
クイック診断
Yes が多い列が候補:
- 「サービス追加頻度が高い / チーム自治」→ Choreography
- 「監査・分岐複雑 / 失敗補償統制」→ Orchestration
- 「p99 低遅延最優先 / 競合高速拒否許容」→ Single Pessimistic
6.2 主なアンチパターン
| アンチパターン | 説明 | 早期兆候 | 緩和策 |
|---|---|---|---|
| イベント連鎖過度化 | 目的不明イベント増殖 | トレース深さ>10 | イベント命名規約 / 集約再設計 |
| オーケストレータ巨大化 | 1ファイル/クラス集中 | PR差分肥大 | 機能別分割 / 階層化 / DSL分離 |
| ロック粒度過大 | 単一グローバルロック | 成功率急落 / 衝突率急増 | シャード細分化 / Key設計見直し |
| 無制限/安易リトライ | 再送が指数的増加 | DLQ溢れ / p99上昇 | Backoff + Jitter + 上限制御 |
| 補償ロジック欠落 | 逆操作未定義 | 不整合チケット増 | 補償テンプレ / 自動テスト |
| モニタリング不足 | 主要メトリクス欠如 | Post-mortem遅延 | OTel / 必須Span検証CI |
| Fail Fast誤用 | 需要>供給で成功率極小 | SLO未定義 | スロット予約 / フェアキュー |
6.3 リスクと緩和策
| リスク | 検知指標 (例) | 影響大パターン | 緩和策 |
|---|---|---|---|
| 集中ボトルネック | Orchestrator CPU>70%継続 | Orchestration | 水平スケール / ステップ非同期化 |
| イベント滞留 | キュー滞留件数増 / p99上昇 | Choreography | キュー分割 / 優先度 / コンシューマ増強 |
| ホットシャード偏在 | 衝突率閾値超 / 偏差↑ | Single Pessimistic | 一貫ハッシュ再計算 / 動的再配置 |
| 補償失敗連鎖 | 補償失敗率>1% | 全般 | 冪等化 / ステップ縮小 / CircuitBreaker |
| 再送洪水 | 再送率>成功率 | Choreography | Backoff + 冪等キー / DLQ閾値アラート |
| 監査欠落 | トレース欠損率>0.5% | 全般 | OpenTelemetry / 必須Spanスキーマ検証 |
| 公平性劣化 | Starvation検出 / 待ち時間分布歪み | Single Pessimistic | フェアスケジューラ / Token Bucket調整 |
7. 推奨アクション（最終）
- Orchestration Heavy の性能最適化（並列度 / I/O 効率 / キャッシュ戦略再検討）
- 競合ログ拡張（リトライ回数 / ロック衝突率 / シャード偏在度）
- 監視における 400（業務拒否）と 500（障害）の分離ダッシュボード
- 指標層強化（分位数 / 衝突率勾配 / リトライ分布 / 公平度メトリクス）
8. まとめ（最終）
- Choreography: バランス型・拡張性良好
- Orchestration: 制御型・スケール最適化余地大
- Single Pessimistic: 超低レイテンシ・評価軸再設計前提