Sagaパターン入門（続編）

Transcript

1. Sagaパターン入門（続編） 2026.01.13 実装方式の詳細と比較 1
2. 本日のアジェンダ 1. 前回の振り返り 2. 従来パターンとの違い 3. Choreography方式の詳細 4. Orchestration方式の詳細 5. 実装方式の比較まとめ 2
3. 前回の振り返り Sagaパターンの基本 分散システムで有用な手法 ACIDのうちIsolation（分離性）の欠如が問題 2つの実装方式が存在 主な問題点 Lost Update: 更新が他で上書き Dirty Read: 未確定の状態が参照可能 3
4. 今回のテーマ 解決策の探求 2つの実装方式の詳細を理解する それぞれの特性と使い分けを学ぶ 具体的な内容 Choreography方式の仕組み Orchestration方式の仕組み 両方式の比較と選択基準 4
5. 従来パターンとの違い Sagaパターンの特徴 途中経過の状態が参照できてしまう 失敗時は補償トランザクションを設計 非同期実行でパフォーマンス向上 分離による複雑性の増加 5
6. Choreography方式とは 基本概念 各サービスが自立して動作 イベント駆動で次のアクションを決定 中央の司令塔は存在しない メッセージングの仕組み イベントをpublish（発行） 必要なイベントをsubscribe（購読） メッセージブローカが仲介 6
7. Choreography方式の構造 7
8. Choreography方式のSaga実装 8
9. Choreographyの動作フロー 9
10. Choreography方式の特徴 メリット サービス間が疎結合 新しいサービスの追加が容易 イベント基盤で拡張性が高い デメリット 全体フローの把握が困難 暗黙的な連鎖で追跡しにくい 競合・整合性リスクが高め 10
11. Orchestration方式とは 基本概念 中央のコーディネータが全体を制御 明示的に処理の順序を決定 中央集権的なアプローチ オーケストレータの役割 各サービスへの指示を出す 処理の順序を管理 全体の状態を把握 11
12. Orchestration方式の構造 12
13. Orchestration方式のSaga実装 13
14. Orchestrationの動作フロー 14
15. Orchestration方式の特徴 メリット 全体フローが把握しやすい 明示的な手順で追跡が容易 競合・整合性リスクが低い デメリット 中央が単一障害点になりうる オーケストレータが肥大化しやすい サービス追加時に中央変更が必要 15
16. 従来 vs Saga パターン Isolation（分離性） 従来: DBが担保 / Saga: 担保しにくい 失敗時の扱い 従来: 自動rollback / Saga: 補償トランザクション 状態の可視性 従来: 確定した結果 / Saga: 途中経過が見える 16
17. 従来 vs Saga パターン（続き） 整合性 従来: 強整合（ACID） / Saga: 最終的整合（ACD） 実行方式 従来: 同期・逐次 / Saga: 非同期でスループット向上 複雑性 従来: シンプル / Saga: 分離で複雑化 17
18. Choreography vs Orchestration 制御の中心 Choreography: 中央なし / Orchestration: 中央あり 連携手段 Choreography: イベント駆動 Orchestration: 直接呼び出し 見通し Choreography: 把握しにくい Orchestration: 把握しやすい 18
19. Choreography vs Orchestration（続き） 柔軟性 Choreography: 高い / Orchestration: 中央変更必要 整合性リスク Choreography: 高め / Orchestration: 低め 向いている状況 Choreography: 疎結合重視 Orchestration: 一貫性・統制重視 19
20. まとめ 実装方式の選択基準 Choreography: 大規模・疎結合・イベント基盤 Orchestration: 一貫性重視・フロー明確・統制 重要なポイント どちらもトレードオフがある システムの特性に応じて選択 補償トランザクションの設計が鍵 20