Sagaパターンとは? サービスをまたぐトランザクション
Sagaパターンは、複数のサービスにまたがるトランザクションを、それぞれ失敗時に取り消す補償アクションを持つローカルステップの列として管理します。
複数のマイクロサービスをデータベーストランザクションで包むことはできません。Sagaパターンはこれを解決します。ビジネスプロセスはローカルトランザクションの連鎖になり、後のステップが失敗すると、補償アクションを実行して前のステップが取り消されます。これが、グローバルロックなしに分散システムがオールオアナッシングに近い振る舞いを得る方法です。
ローカルステップと補償
各サービスは自身のローカルトランザクションを行い、次のステップをトリガーします。途中でステップが失敗すると、Sagaはすでに完了したステップに対する補償トランザクション (支払いを返金する、確保した在庫を解放する) を実行し、プロセスを論理的にロールバックします。
二つの調整様式
コレオグラフィは各サービスがイベントに反応して次のイベントを発行し、中央のコーディネーターを持ちません。オーケストレーションは、各サービスに次に何をすべきかを指示するコーディネーターを使います。コレオグラフィは分散的で、オーケストレーションは追跡や推論がより容易です。
必要となる理由
- サービス間の分散ロックが不要です。
- 各サービスが自身のデータの所有権を保ちます。
- 部分的な失敗が補償を通じて明示的に処理されます。
- イベントやmessage broker上で自然に機能します。
失敗経路のテスト
ハッピーパスは簡単なケースであり、Sagaの価値は失敗処理にあります。CIは、各ステップに失敗を注入すると補償が正しくトリガーされ、システムが整合した状態に保たれることをテストすべきです。それには成功経路のテストだけでなく、フォールトインジェクションのテストが必要です。
慎重にデプロイしバージョン管理する
Sagaはイベントやコマンドを通じて複数のサービスを結びつけます。あるステップの契約を変えると進行中のSagaが取り残されうるため、後方互換のあるステップ定義と慎重なロールアウト順序が、長時間実行のSagaが途中で壊れるのを防ぎます。
複数サービスのテスト実行
Sagaをエンドツーエンドで実行するには、CIで複数のサービスとブローカーを立ち上げる必要があります。ウォームなマネージドrunner (Latchkeyなど) は、その重めの統合セットアップがパイプラインを止めないようにします。
重要なポイント
- Sagaは、補償アクションを持つローカルステップから成る複数サービスのトランザクションです。
- コレオグラフィ (イベント駆動) とオーケストレーション (コーディネーター) の様式があります。
- その真価は失敗処理にあるので、補償の経路をフォールトインジェクションでテストしましょう。