これは TECHSCORE Advent Calendar 2018 の5日目の記事です。
はじめに
世の中がマイクロサービスの話題で溢れている中で、トランザクションはどうやって実現されているのか不思議だったので調べてみました。
マイクロサービスでは複数のAPIでのやり取りとなるため、これまで使っていたデータベースのようなトランザクション（BEGIN-COMMIT）が使えません。
解決策の一つにSagaパターンがあります。
Sagaパターン
Sagaパターンとは、複数のサービスにまたがるビジネストランザクションをSagaとして実装します。Sagaは一連のローカルトランザクションです。
たとえば下記の図のような構成を考えます。
このとき、Service A におけるSaga Aの成功と失敗を次のように定義します。
- 成功 : Transaction X、Transaction Y、Transaction Z のすべてが成功した場合
- 失敗 : Transaction X、Transaction Y、Transaction Z のいずれかが一つでも失敗した場合
以下のSagaはすべてのローカルトランザクションが成功してるので、Saga Aも成功となります。
次に、Transaction Zが失敗した場合です。
この場合、Transaction Zが失敗したため、補償トランザクション（Compensation Transaction）をすでにコミット済みのTransaction Y、Transaction Xに対して実行します。Saga Aとしては失敗となります。
とてもシンプルな考え方ですね。
Saga の実現方法
Sagaの実現方法として2つの方法があります。
- Choreography（振り付け）
- Orchestration（オーケストレーション）
Choreography
Choreography では、各ローカルトランザクションは、他のローカルトランザクションのトリガーとなるイベントを発行します。この方法では、各ローカルトランザクション（Service X、Y、Z）は自身の発行するイベントおよび自身のトリガーとなるイベントに対してが責務の範囲となります。
Orchestration
Orchestration では、Service Aで生成したオーケストレーターが、実行するローカルトランザクションコマンドを各サービス（Service X、Y、Z）に通知します。オーケストレーターは実行するローカルトランザクションのインターフェースについて知識を持つ必要があります。
Choreography vs Orchestration
初見ではChoreographyのほうがOrchestrationよりも責務がわかりやすく、他のサービスとのインターフェースの調整も不要なため良さそうにみえましたが、それぞれ良し悪しがあるようです。
Choreographyは、自身のトリガーとなるイベントに対しての責務が大きく、複数のサービスが循環参照するようなケースだとイベントの扱いが非常に難しくなります。シンプルなSagaの場合は十分に有効な方法なのだと思います。
Orchestrationは、関係するサービスのインターフェースについては管理する必要がありますが、各サービス間で互いのイベントを気にする必要がなく、処理としてはとてもシンプルになります。また、Sagaがオーケストレーターに閉じるため、Saga外部のことを気にする必要がありません。ただし、Saga間の独立性については考慮が必要です。
まとめ
マイクロサービスにおけるトランザクションでSagaが使えそうな気がしてきましたが、実際に導入するにはまだまだ壁がありそうです。
- Sagaのための補償トランザクション
- Saga間での独立性
- Sagaでの異常ケース（ロールバックなどが正常に行われない）のリカバリ
Sagaを入り口に他のアーキテクチャパターンも学習しようと思います。
参考
プレゼンテーション
GOTO 2015 • Applying the Saga Pattern • Caitie McCaffrey *動画
GOTO 2015 • Applying the Saga Pattern • Caitie McCaffrey *スライド
とてもわかりやすくSagaパターンについて話されています。
書籍
Microservices Pattern - Chris Richardson
本記事で感じた導入に際しての壁の対応について詳しく書かれています。
Sagaパターンの他にも有用なマイクロサービスのためのパターンが多くあります。
記事
オーケストレーション対コレオグラフィー：定義に関する論争
OrchestrationとChoreographyについて書かれています。
sagaを使用したマイクロサービスのデータ一貫性
ACID Is So Yesterday: Maintaining Data Consistency with Sagas
いずれもSagaでのACIDにおける独立性（Isolation）の欠落について書かれています。
Saga: How to implement complex business transactions without two phase commit.
BPMN (Business Process Model and Notation) というモデル図でSagaパターンについて説明があります。
