おとぎ話サーガの特徴
まずは、おとぎ話サーガ単体の特徴から。
オーケストレーション型
同期通信
結果整合性
のサーガパターンである。
エピックサーガに比べて、一気に実装難易度は上がります。
なぜなら、結果整合に伴って、トランザクション管理のコードを自前で用意する必要があります。
エピックサーガとの比較
さて、ではエピックサーガから進化するにあたって、
アトミック整合から結果整合になったわけですが、具体的に何がどうなったのか？
アーキテクチャ図で比較してみましょう。
エピックサーガのアーキテクチャ図
おとぎ話サーガのアーキテクチャ図
両者の違い
まず通信の方向性から。
結果整合になったことで、補償トランザクション通信が端方向になります。
補償トランザクションの方向性が端方向になります。
（この理由は後程）
それ以外のエピックサーガから変化させたことによる、
良くなった点と悪くなった点をそれぞれ見ていきましょう。
信頼性・耐障害性
よくなった点
部分障害への耐性向上
アトミック整合（2PCなど）で参加リソースをロックし続ける状態がなくなります。
これにより、あるサービスが一時的に停止しても、システム全体がロックされ停止するような「連鎖的な障害」のリスクが大幅に低下します。
これはカオスエンジニアリングの【障害の影響範囲を局所的にする】ってのを満たします
リソースの解放
トランザクションが長時間リソースを掴んだままになることがなくなるため、システム全体の安定性が向上します。
悪くなった点
補償トランザクションの失敗リスク
補償トランザクション自体が失敗する可能性があり、その場合データが不整合な状態で残ってしまうリスクが新たに発生します。このリカバリー戦略は複雑です。
ただし、イベントソーシング実装によって、失敗を検知可能かつ、監査可能で、回復可能な状態に保ちます。
イベントソーシングは、「補償トランザクションの失敗」という、結果整合性における最も厄介な問題を解決するための、極めて強力な手法だからです。
性能・スケーラビリティ
よくなった点
スループットの向上
サービス間のリソースロックが不要になるため、エピックの時に起きやすかったボトルネックが解消され、システム全体で同時により多くのリクエストを処理できるようになります。
これによってスケーラビリティが大幅に向上します。
悪くなった点
レイテンシーの微増
正常系の処理（ハッピーパス）におけるレイテンシーは、同期呼び出しの連鎖であるため大きくは改善しません。
むしろ、オーケストレーターでの状態管理や判断ロジックにより、ごく僅かに増加する可能性があります。
結合度とトランザクションフロー
よくなった点
時間的な結合度の低下
各サービスは、他のサービスの処理が完了するまでロックされ待機する必要がなくなります。これにより、サービス間の時間的な結合が解消され、独立性が高まります。
補償が「前進」する処理になることで、端方向補償トランザクションとなる
アトミックなロールバック（後退）とは異なり、補償トランザクションは
「反対の操作（例：入金に対する出金）」という新たなトランザクションを実行します。
これにより、メール送信のような取り消せない操作に対しても、「訂正メールを送る」というビジネス的な補償が可能になります。
なので、エピックの時では、双方向の補償トランザクションであった状態から、サーガからの一方通行の補償トランザクションとなります。
悪くなった点
監査証跡の複雑化
ロールバックされて「何もなかった」ことになるのではなく、「実行と、その取り消し」の両方が記録として残ります。
これにより、監査や会計上の追跡が複雑になる場合があります。
しかしこれも、イベントソーシングを取り入れることで、
「実行と取り消し」という2つの出来事の因果関係を明確に記録し、誰にとっても理解しやすい形で提示することで、監査や追跡の複雑さを劇的に軽減します。
実装の複雑性
よくなった点
インフラ依存の低下
2PC（Two-Phase Commit）のような、特定のミドルウェアやプロトコルに依存する複雑な分散トランザクションマネージャーが不要になります。
悪くなった点
ビジネスロジックの複雑化
開発者は、全てのトランザクションに対して、取り消すための「補償トランザクション」を自ら設計・実装する必要が生じます。
この責務は開発者の認知負荷を大幅に増大させます。
ユーザー体験
よくなった点
システム可用性の向上
システムがロックされにくくなるため、ユーザーから見て「システムが応答しない」という状況が減り、可用性が高く感じられます。
悪くなった点
「取り消し」体験の発生
ユーザーが一度「成功」と認識した処理が、後続のステップの失敗により
「在庫がないためキャンセルされました」と覆る可能性があります。
これはユーザーに混乱を与え、体験品質を損なう一因となります。
よくファッションサイトのオンラインショップで見かける現象です。
コミュニケーションコスト
サービス間の「時間的な結合度」が劇的に低下するため、チーム間の調整や会議といったコミュニケーションコストは大幅に削減されます。
エピックサーガでの調整コスト
エピックサーガの時には、あるサービスで問題が発生したり、
デプロイで遅延したりすると、トランザクション全体がロックされ、他の全てのチームに直接影響していました。
そのため、「今からデプロイするので、ロックに注意してください！！」
「障害が発生したので、全チームで調査を…」といった、密な調整や障害対応の連携が常に求められていました。
おとぎ話サーガでの調整コスト
対して、各サービスが持つのは、自身のデータベースに対するローカルトランザクションのみです。技術的なロックで他サービスを拘束しません。
技術的なトランザクション境界が狭く、そして緩やかになるため、調整コストは大幅に低下させることができます。
結果整合に伴う補償トランザクションの自前実装
ここが今回のメイントピックです。
エピックサーガでアトミック性を保証していたトランザクションマネージャーの役割は、不要になります。
代わりに、もし途中でプロセス全体を中断したくなった場合、
それまでに完了した処理をビジネスロジックで打ち消すための補償トランザクションを開発者自身がアプリケーションコードとして予め実装しておく必要があります。
その責任の所在が、アトミック整合から結果整合へ移行する際の最も大きな変化点です。
そして、そのインフラのコードをそのままにしておくのは、混乱や意図しない副作用を招くため、避けるべきです。
トランザクションマネージャーの役割の変化
エピックサーガ（アトミック整合）におけるトランザクションマネージャーの唯一の責務は、2PC（Two-Phase Commit）などを用いて、複数のサービスにまたがる処理が「すべて成功」するか「すべて失敗」するかのアトミック性を保証することでしたね。
おとぎ話サーガ（結果整合）に移行するということは、この
「インフラによるアトミック性の保証」を放棄し、代わりに「アプリケーションレベルでの補償」によってビジネス的な一貫性を保つ と決断したことを意味します。
したがって、そのビジネスプロセスにおいて、トランザクションマネージャーが担っていた役割は、自前で実装した補償トランザクション付きのサーガ・オーケストレーターに置き換えられ、不要になります。
なぜインフラをそのままにしてはいけないのか？
トランザクションマネージャーの設定を残したまま補償トランザクションを実装すると、
以下のような問題が発生します。
不要なオーバーヘッド
トランザクションマネージャーは、たとえアトミックな保証を使わなくても、それ自体がリソースを消費し、処理に僅かな遅延を加えます。
これじゃあ、結果整合のレイテンシーを増大させるだけです。
アーキテクチャの不一致と混乱
コードを読む開発者にとっては、
インフラレベルのトランザクション管理（トランザクションマネージャー）と、
アプリケーションレベルの補償ロジックという2つの回復メカニズムが混在しているのを見て混乱します。
「本当の回復処理はどちらなのか？」が不明確になり、保守性を著しく低下させます。
意図しない競合
トランザクションマネージャーが、タイムアウトや接続断を検知して自動的にロールバックを試みようとするかもしれません。
この意図しない動きが、アプリケーションの補償トランザクションのロジックと競合し、
予測不能な結果を招く危険性があります。
移行のステップ
移行の際には、そのビジネスプロセスに関わるコードから、分散トランザクション（TM）の利用設定を意図的に解除・削除する必要があります。
これにより、アーキテクチャの意図（＝結果整合）と実装が一致し、クリーンで理解しやすい状態を保つことができます。
①責務の移行：アプリケーションへの実装
まず、これまでトランザクションマネージャー（インフラ）が担っていた
「失敗時に元に戻す」という責務を、アプリケーションコードで肩代わりします。
具体的には、サーガ・オーケストレーターと各サービスの補償トランザクションをオーケストレーターのアプリケーションコードとして実装します。
②クリーンアップ：インフラ設定の削除
新しい回復メカニズム（サーガ）が機能し始めたら、古いメカニズム（トランザクションマネージャー）はそのプロセスにとって技術的負債となります。
そのため、対象の処理から分散トランザクションの設定を削除し、アーキテクチャと実装を一致させます。
この2ステップにより、トランザクション制御の責任がインフラからアプリケーションへ、
と明確に移行されます。
オーケストレーターのアプリ責務が増加する
エピックの時にはあったトランザクションマネージャーという「後ろ盾」がなくなります。
その結果、オーケストレーターは新たに以下のアプリケーションレベルの責務を全て担う必要があります。
オーケストレーターは、単純なサービス呼び出しの連続から、状態管理と複雑なエラー回復ロジックを含む、より高度なものへと変化します。
その結果オーケストレーターのアプリケーションコード自体の複雑性は増し、バグの可能性は高まります。
具体的には以下の責務がオーケストレーターのアプリケーションコードに追加されます。
状態管理
サーガ全体の進捗（どのステップまで成功したか）を永続的に管理する。
補償ロジックの実行
いずれかのステップで失敗した場合、それまでに完了した処理に対応する補償トランザクションを、正しい順序で呼び出す。
エラーハンドリング
補償トランザクション自体の失敗や、サービスのタイムアウトなど、より複雑なエラーケースに対処する。
移行によるセキュリティの変化
エピックサーガからおとぎ話サーガへの移行によるセキュリティ上の変化は、
インフラ層のリスクを低減し、アプリケーション層に新たなリスクと責務を移管する
というトレードオフを引き起こします。
メリット (良くなった点)
サービス妨害（DoS）攻撃に対する耐性の向上
エピックサーガが依存する分散トランザクション（2PCなど）では、
連携するサービスの一つが応答不能になると、他の全てのサービスのリソースがロックされ、プロセス全体が停止する可能性があります。
これは、特定のサービスを狙ってシステム全体を停止させるDoS攻撃の標的になり得ます。
しかし、おとぎ話サーガではこのロック機構がなくなるため、一つのサービスの障害がシステム全体の停止に直結するリスクが大幅に低下します。
デメリット (悪くなった点)
補償トランザクションの脆弱性が新たな攻撃対象になりうる
補償トランザクションにバグがあれば、それが新たなセキュリティホールになり得ます。
例えば「商品の発送には成功したが、支払いに失敗した。
しかし、発送を取り消す補償トランザクションのバグにより、商品だけが送られてしまい、支払いはされない」といった事態が考えられます。
セキュリティ監査の複雑化
アトミックなトランザクションでは「成功」か「無かったこと（ロールバック）」の2択で、監査が容易です。
結果整合性では、「実行」と「その取り消し（補償）」の両方が記録として残ります。
攻撃者がこの複雑な履歴の中に不正な操作を紛れ込ませた場合、発見が困難になる可能性があります。
これに対抗する術はないのでしょうか？
イベントソーシングの思想を導入
イベントソーシングの考え方を導入することで、セキュリティ監査の複雑化というデメリットは、逆に「強力なメリット」へと転換させることができます。
また、補償トランザクションの脆弱性によって**「何が起きたか」を正確に記録**することに長けています。
なぜイベントソーシングがセキュリティ監査を強化するのか
イベントソーシングは、セキュリティ監査において極めて価値の高い、以下の2つの特性を提供してくれるからです。
変更不可能な（イミュータブルな）監査ログ
イベントソーシングでは、全ての出来事が、削除・変更不可能なイベントとして時系列に記録されます。
これは、一度記録されたら改ざんできない、非常に信頼性の高い監査証跡そのものです。
攻撃者がシステムに侵入し、不正な操作を行っても、その痕跡を消すことは困難です。
そんなリスクを攻撃者が負うなんて考えにくいでしょう。
コンテキストの明確な記録
従来のデータベースでは、データの「状態」しか記録されませんが、イベントソーシングでは「何が起きたか」というビジネス上のコンテキストがイベントとして記録されます。
従来の監査
「paymentsテーブルに、CHARGEとREFUNDのレコードがある。
これは通常のキャンセルか？それとも不正利用か？」というように推測が必要。
イベントソーシングでの監査
「OrderPlaced→PaymentFailed(理由:不正利用の疑い)→OrderCancelledというイベントが記録されている」→ 文脈と意図が一目瞭然
このように、イベントソーシングは「実行と取り消し」の履歴を、
単なるデータの羅列ではなく、因果関係が明確な「物語」として記録します。
これにより、監査人はシステムの振る舞いを正確に、かつ容易に追跡できるようになり、
セキュリティ監査の質と効率が劇的に向上します。
まとめ
エピックサーガからおとぎ話サーガに移行する際には、
結果整合になることで、サーガのアプリケーションコードに補償トランザクションを実装し、インフラからトランザクションマネージャーのコードを消す必要 があります。
また、結果整合のトランザクション管理では、補償トランザクションが失敗することを前提に、イベントソーシングを取り入れることを必須 とする方が良いでしょう。