Process Manager, Sagaってなに？
ときどきProcess ManagerとかSagaとかって何？って質問をいただくので書き留めておく。(細かい技術的な各論はここでは書いていないので、具体的には紹介する書籍から学んでほしい)
結論からいうと、厳密な定義はあるが、混同して使われることが多い。
Sagaは一貫性よりもロールバックなどの補償を優先することでロックを回避するパターン。比較的単純な仕組みであるため、一般的に状態を必要としない
Proccess Managerは有限状態機械によって実装されたワークフローパターン。Sagaとは異なりトランザクション中は永続的な状態を保持する
このような違いがあるが、実装には両方の観点が含まれることが多々ある。
Process Manager
Enterprise Integration Patterns
のChapter 7. Message RoutingにProcess Managerの紹介がある。こちらのサイトでも同様の内容が見られる。
Process Managerは、メッセージフローを中心的に制御し、一連のプロセスの状態を維持する機能を持つ。特に、複数のプロセスが並行して実行される場合、各メッセージがどのプロセスに関連しているのかを把握し、正しく処理を進めることが重要。
Process Managerは、その柔軟性から多種多様な問題を解決することが可能だが、すべての状況においてプロセスマネージャーを使用することは過剰な場合もある。そのため、実際の使用に当たっては、システムの要件に応じて適切に選択する必要がある。
全体として、Process Managerは、メッセージフローを効率的に制御し、状態管理を行うことで、複雑なシステムの実行をスムーズに進める重要な役割を担う。
Reactive Messaging Patterns with the Actor Model
具体的な実装を知りたい方はこの本がお勧め。こちらはScala/Akkaで実装まで解説されている本。ScalaとAkkaが分かっている前提で読む本なのでハードルが高い…。しかも記載されているコード例がもう古い…。
Sagaについてはこの本が詳しい。
4章は、まるまるSagaの章だけど、Sagaの必要条件である、5章のルール3は絶対読んで欲しい。
アグリゲートの操作には、1つのトランザクションが作成、更新するアグリゲートは1つだけにしなければならないというルールがあります。
中略
このルールにより、複数のアグリゲートを作成、更新しなければならない操作の実装は難しくなります。しかし、サーガ(第4章参照)は、まさにこの問題を解決するために設計されたメカニズムです。
中略
これが可能なのは、トランザクションモデルが豊富なRDBMSなどのデータベースを使っているときだけです。単純なトランザクションしかサポートしないNoSQLデータベースを使っている場合、サーガを使う以外に選択肢はありません。
実装的な観点
こちらは、私が書いた、比較的新しいAkka Typed 2.6で書いたコード(Pekkoを使いたい人はimportをpekkoのやつに変更するとそのままビルドできると思う)。雰囲気は味わえると思われる。実装にはProcessManagerという名前を付けているが、Sagaの補償アクションの考え方も含まれている。
このProcess Managerは注文を受けると在庫確保を行い決済を行う。以下のような特徴を備えている。
メッセージを送受信するアクターである
注文コマンドを受付、外部にある在庫アクターや決済アクターとメッセージをやりとりする。
有限状態機械(FSM)である
この例では在庫確保状態、決済失敗状態、注文完了状態、注文失敗状態がある
つまり、注文メッセージを受け付けると、在庫アクターに在庫確保メッセージを投げる。成功の返信がきたら在庫確保状態に遷移し、決済アクターに決済メッセージを投げる。成功の返信がきたら注文完了状態に遷移する。状態はイベントとして永続化(追記)される
Saga的な観点でいえば、決済に失敗した際は在庫確保を取り消す必要がある。そのような補償アクションも実行する責任がある(失敗しても必ず補償するとは限らない。「顧客への通知」が失敗しても「在庫確保」まで遡って補償アクションを実行することはないかもしれない)
アクターの状態は永続化される
この例ではイベントソーシングになっている。状態遷移した際にイベントが追記されているので、なんらかの理由で再起動した際はイベントから最新の状態を復元し、プロセスの残りのステップがあれば実行が再開される。
参考文献
Process Manager
Saga
この記事が気に入ったらサポートをしてみませんか？