Saga

Saga

各マイクロサービスは、分散トランザクションは使わずに、ローカルトランザクションの形式を取る

そのため、各サービスにまたがるデータベース間の同期を取る方法の１つがSaga

ローカルトランザクション、イベント、補償トランザクション

互いに独立して、通信によって、更新されていくため、結果整合性となる

つまり、ある時点ではおかしな状態を許容しなくてはいけないということ

通常の感覚だとNGになるが、ビジネスとして結果整合性を許容できないケースは少ない

しっかりとビジネス側と話して許容してもらう

正常系

最初のサービスがローカルトランザクションで、自分の管理するDBを更新したら、イベント通知にてメッセージを送信して、次のサービスがそれを受け取り、処理を開始してDBを更新する。

ローカルトランザクションをバケツリレーのように運んでいく形

異常系

障害が発生した場合は、補償トランザクションとして、各サービスを戻すバケツリレーを開始する

コレオグラフィ

メッセージングを利用して、データの同期を行うパターン

あるサービスが送信したメッセージを購読したりして、そのイベントを契機に自身の処理が実行される

補償トランザクションも同じく、エラーなどが発生したら、メッセージを送信して、そのイベントを契機に自身の補償トランザクションが動く

メリット

構造はシンプル

メッセージングで運ばれていくだけ

各サービスで完結する

連携が柔軟

全体のフローの制御を変更する必要はない

各サービスで必要なメッセージを受信して、処理を行えば良い

デメリット

Saga全体の見通しは悪い

各サービスの中に、サービス間の連携フローが実装されているため、全体感が分からない

中身を見て、どうなっているかを組み立ててみないと分からない

トランザクションの実行状態が確認しにくい

トレースがしにくい

各サービスにSagaの制御ロジックが入ってしまう

オーケストレーション

Sagaオーケストレーターと呼ばれる特別なサービスが、トランザクション処理をおこなう

リクエスト・レスポンス形式の非同期メッセージを介して、行なっていく

メリット

データベース連携の流れがわかりやすい

Sagaオーケストレーターが全体の流れを制御する