1つの記事で完了！ Saga 分散トランザクションを 10 分で説明する

[[388307]]

この記事は、Cui Hao 氏が執筆した WeChat 公開アカウント「Shishan's Architecture Notes」から転載したものです。この記事を転載する場合は、Shi Shan の Architecture Notes 公開アカウントにご連絡ください。

導入

マイクロサービス アーキテクチャの台頭により、実際のシナリオで分散トランザクションの問題に遭遇する企業がますます増えるでしょう。特に、複数のプロセス間アプリケーションが連携してタスクを完了する金融アプリケーションのシナリオでは、分散トランザクションの参加がさらに不可欠です。分散トランザクションに関しては、2PC と TCC がよく言及されます。ただし、ビジネス プロセスが長く、TCC 変換が難しいシナリオの場合は、Saga 分散トランザクションが選択されます。今日は、Saga の分散トランザクションの実装の内容を紹介します。

1. Sagaの分散ソリューション
2. Sagaはトランザクションの一貫性を処理する
3. Saga 分散トランザクション調整
4. Sagaの分散ソリューション

インターネットの急速な発展により、元のモノリシック アプリケーションでは、高トラフィックおよび高同時実行の要求をサポートすることが困難になりました。そのため、ソフトウェア システムは、元のモノリシック アプリケーションから分散型アプリケーションへと徐々に移行してきました。図 1 に示すように、左側の Web アプリには UI とサービス モジュールが含まれています。変換後は、右側のマイクロサービス アーキテクチャに対応するようになります。サービス間に関連する呼び出しがあります。

図1 モノリシックシステムアーキテクチャから分散システムアーキテクチャへの移行

分散展開後は、トランザクション操作を共同で完了する複数のサービスが存在し、これらのサービスは異なるサーバーまたはネットワーク環境に存在します。トランザクションを完了するためにサービスがネットワークを介してリモートで連携する必要があることを、分散トランザクションと呼びます。例：銀行振込業務、ファスナー在庫発注など。

分散トランザクションのシナリオでは、データの一貫性が強く求められる場合、ビジネス レイヤーで「2 フェーズ コミット」(2PC) ソリューションが使用されます。

最終的な一貫性を保証する場合は、TCC (Try Confirm Cancel) モードを採用できます。最終的な一貫性を保証する TCC モデルは業界で広く使用されていますが、一部の分散トランザクション シナリオではプロセスが多く長いため、他社のサービスを呼び出す必要がある場合があります。特に、制御不能なサービス（他社のサービス）の場合、TCC 開発モデルに従えず、TCC モデルの開発コストが増大します。コア金融ビジネス（チャネル層、製品層、統合層）に代表される特定のシナリオに反映され、その特徴は、複数のプロセス、長いプロセス、および制御不能なサービスへの呼び出しです。同時に、プロセスが長く、トランザクション境界が長すぎて、ロック時間が長いため、TCC モードを使用すると同時実行パフォーマンスに影響します。

このようなビジネス シナリオの分散トランザクション処理を考慮して、Saga 分散処理モードが提案されています。 Saga は「長いトランザクションのためのソリューション」であり、「長いビジネス プロセスと多くのビジネス プロセス」を含むシナリオに適しています。特に、レガシー システム サービスであるトランザクションに参加するサービスの場合、TCC モードでは 3 つのインターフェイスを提供できないため、Saga モードを採用できます。

適用可能なビジネス シナリオには、金融機関のドッキング システム (外部システムとのドッキングが必要)、チャネル統合 (長いプロセス)、分散アーキテクチャ サービスなどがあります。その利点は、ローカル トランザクションの 1 フェーズ コミット、ロックフリー、および高パフォーマンスです。参加者は高いスループットで非同期的に実行できます。更新操作の逆操作は比較的理解しやすいため、補正サービスは簡単に実装できます。もちろん、分離が保証されないという欠点もあります。

Sagaはトランザクションの一貫性を処理する

1987 年、プリンストン大学の Hector Garcia-Molina 氏と Kenneth Salem 氏は、長期にわたるトランザクションの扱い方に関する Paper Sagas を出版しました。 Saga は、インターリーブして実行できるサブトランザクションのコレクションに分解できる、長期間実行されるトランザクションです。これらの各サブトランザクションは、データベースの一貫性を維持する実際のトランザクションです。

この人の論文では、各 Saga は一連のサブトランザクション Ti で構成されていると述べられています。各 Ti には対応する補正アクション Ci があり、これは Ti によって発生した結果を元に戻すために使用されます。ここで、各分散トランザクションの各実行操作またはステップは Ti であることがわかります。たとえば、在庫の減算は T1、注文の作成は T2、支払いサービスは T3 です。次に、在庫 C1 の復元、注文 C2 のロールバック、支払い C3 のロールバックなど、各 Ti に対応する補償アクション Ci が実行されます。

Saga トランザクションには 2 つの回復戦略があります。

前進的回復とは、「勇気を持って前進する」ことを意味します。

実行に失敗したトランザクションについては、トランザクションの再試行が試行されます。ここでは、各サブトランザクションが最終的に成功するという前提があります。この方法は、図 2 に示すように、必ず成功する必要があるシナリオに適しています。上の図では、サブトランザクションは左から右に実行されます。 T1 が実行された後、T2 が実行され、その後に T3、T4、T5 が実行されます。

図2 Sagaトランザクション実行戦略

トランザクション回復の順序も、T1、T2、T3、T4、T5 の方向になります。 T1 が失敗した場合、T1 は再試行されます。同様に、サブトランザクションの実行中に失敗したトランザクションも実行されます。だから「勇気を持って前進する」というのです。

バックワードリカバリは、トランザクションが失敗した場合に完了したすべてのトランザクションを補償する「バックワードリカバリ」方式です。次の図 2 に示すように、サブトランザクションは依然として左から右に実行されます。トランザクション T3 を実行すると、トランザクションは失敗するため、補正トランザクションは赤い線の方向に、最初に C3、次に C2、C1 の順に実行され、T0、T1、T2 の補正トランザクション C1、C2、C3 がすべて実行されるまで続きます。つまり、Saga 全体の実行結果をロールバックします。

Saga 分散トランザクション調整

上記では、Saga の概念とトランザクション回復方法について紹介しました。各トランザクションには複数のサブトランザクションがあり、各サブトランザクションには、トランザクションがロールバックされるときに使用される補正トランザクションがあります。サブトランザクションに対応する操作は分散システム アーキテクチャ内の異なるサービスに展開されるため、共通のトランザクションを完了するにはこれらのサブトランザクションが連携する必要があります。

実際、Saga トランザクションが開始されると、調整ロジックは最初の Saga 参加者、つまりサブトランザクションにローカル トランザクションを実行するように指示します。トランザクションが完了すると、Saga は実行順に Saga の次の参加サブトランザクションを呼び出します。このプロセスは、Saga トランザクションが完了するまで継続されます。

サブトランザクションの実行中にサブトランザクションに対応するローカル トランザクションが失敗した場合、Saga は逆の順序で補正トランザクションを実行します。一般的に、Saga がトランザクションを実行する順序を Saga の調整ロジックと呼びます。この調整ロジックには、次の 2 つのモード (振り付けとオーケストレーション) があります。

振り付け: 参加者 (サブトランザクション) の呼び出し、割り当て、意思決定、および順序付けは、イベントの交換によって実行されます。これは、参加者がメッセージ メカニズムを通じて通信し、リスナーを通じて他の参加者から送信されたメッセージをリッスンして、後続の論理処理を実行する分散型モデルです。中間調整ポイントがないため、参加者は互いに調整するために自分自身に頼ります。

制御 (オーケストレーション): Saga は、参加者間の調整作業を容易にする制御クラスを提供します。トランザクション実行コマンドは、Saga の参加者に論理的な順序で要求する制御クラスによって開始されます。参加者からのフィードバックを受け取った後、制御クラスは他の参加者への通話を開始します。すべての Saga 参加者は、このコントロール クラスを中心に通信し、作業を調整します。

次の例では、これら 2 つの調整モードについて説明します。注文サービスの注文作成操作によって開始される注文配置ビジネスがあるとします。支払サービスでは支払指示、在庫サービスでは在庫減額、出荷サービスでは出荷操作を順に呼び出します。最後に、すべての参加者（サービス）での操作（サブトランザクション）が完了すると、注文発注トランザクション全体が完了します。

振り付け: 参加者の操作を調整する中央制御クラスがないため、調整はメッセージの送信を通じて行われます。

図3に示すように:

図3 オーケストレーションモード - トランザクション実行成功

1. 「注文サービス」で「注文の作成」操作を実行すると、「注文の作成メッセージ」がキューに送信されます。

2. 「支払いサービス」はキュー内の注文メッセージをリッスンし、「注文の支払い」操作を呼び出し、さらに「サービス専用メッセージ」をキューに送信します。

3. 「支払いメッセージ」を聞いた後、「在庫サービス」は「在庫控除」を処理し、「在庫控除メッセージ」を送信して、次の消費者がそれを受け入れるのを待ちます。

4. 全体のトランザクションの最後のサブトランザクションとして、「出荷サービス」は「在庫減額メッセージ」を受信した後に出荷のサブトランザクションを実行します。取引が完了すると、「注文サービス」に「発送メッセージ」が送信されます。メッセージを受信した後、注文サービスはトランザクション ループ全体を完了して送信します。

上記は、トランザクションが正常に実行されたことについてです。取引が失敗した場合はどうすればいいですか?

図4に示すように:

図4 オーケストレーションモード - トランザクション実行の失敗

1. 「発送」実行時にサブトランザクションが失敗した場合、「発送失敗メッセージ」が送信されます。

2. 「出荷失敗メッセージ」を受信した後に、在庫サービスは「在庫のロールバック」操作を実行し、当初差し引かれた在庫を戻し、同時に「差し引き失敗メッセージ」を送信します。

3. 「支払いサービス」は「控除失敗メッセージ」を受け取った後、「ロールバック支払い」を実行して返金し、同時に「支払い失敗メッセージ」を送信します。このメッセージを受信すると、注文サービスは注文トランザクションを失敗としてマークします。

上記の説明から、オーケストレーションの利点がわかります。

シンプル: 各サブトランザクションは、操作を実行するときにイベント メッセージを発行するだけでよく、他のサブトランザクションはリッスンして処理します。

疎結合: 参加者 (サービス) はイベントをサブスクライブすることで通信し、組み合わせの柔軟性を高めます。

もちろん、いくつかの欠点もあります。

理解が難しい: ビジネス プロセスの完全な説明がないため、トランザクション全体の実行プロセスを理解するにはコードを読む必要があります。開発者がコードを理解して保守する難易度が増します。

サービス間には循環依存関係があります。通信はメッセージとイベントを通じて行われるため、参加者間には循環依存関係があります。つまり、サービス A はサービス B を呼び出し、サービス B はサービス A を呼び出します。これによってもアーキテクチャ設計の複雑さが増すため、設計の初期段階で慎重に検討する必要があります。

密結合のリスク: 各参加者が実行するメソッドは、前のステップで参加者が送信したメッセージによって異なります。ただし、参加者の実際のステータスを把握するには、前のステップの参加者のすべてのメッセージをサブスクライブする必要があり、これにより 2 つのサービスの結合度が目に見えない形で増加します。

オーケストレーションの中核は、参加者 (サービス) にどの操作 (サブトランザクション) を実行する必要があるかを指示する制御クラスを定義することです。 Saga コントローラー クラスは、コマンドと非同期応答を通じて参加者と対話します。

図5に示すように:

図5 制御モード - 成功

1. 注文サービスが注文トランザクションを実行すると、Saga コーディネーターに要求コマンドが送信されます。コマンドを受信すると、Saga コーディネーターはサブトランザクションが実行される順序でサービス内のメソッドを呼び出します。

2. まず、「支払いサービス」内の「支払い注文」操作を呼び出して「支払い注文」操作を実行し、実行結果「支払い完了」が点線部分を通じて返されます。

3. 次に、「在庫サービス」で「在庫控除」メソッドを実行し、点線部分を通じて控除完了メッセージを「フィードバック要求」モジュールに返します。

4. 次のステップは、「shipping」コマンドを実行し、「shipping サービス」の「shipping」メソッドを呼び出して、「shipping 完了」応答を返すことです。

5. 最後に、3 つのサブトランザクションがすべて実行された後、注文サービスに戻り、分散トランザクション全体が完了します。

取引が正常に完了した後、異常な状況を見てみましょう。

図6に示すように:

図6 制御モード - 失敗

1. 「配送」コマンドを実行すると、「配送に失敗した」ことが判明したため、「配送サービス」は Saga コーディネータにフィードバックします。

2. このとき、コーディネーターは「在庫サービス」の「在庫のロールバック」操作を呼び出して、減算された在庫を復元します。

3. 次に、「支払いサービス」の「支払いのロールバック」を呼び出して、支払いの払い戻しを完了します。

4. 最後に、トランザクションが失敗したことが注文サービスに通知されます。

制御モードもイベント駆動型であることに注意してください。オーケストレーション モードと同様に、参加者にコマンドを実行するように通知するメッセージを送信します。上記 2 つの図におけるコマンドの実行と呼び出しもメッセージを通じて実行されます。

コントローラ設計の利点:

循環依存関係を回避する: オーケストレーション パターンの参加者間で循環呼び出しが発生しますが、中央制御クラス アプローチによりこれを回避できます。

複雑さを軽減: すべてのトランザクションは、コマンドの実行と応答の処理を担当するコントローラーによって完了します。参加者は、メッセージの処理方法を考慮することなく自分のタスクを完了するだけでよいため、参加者のアクセスの複雑さが軽減されます。

テストが容易: テスト作業は集中制御クラスに集中し、他のサービスは機能を個別にテストできます。

拡張が容易: トランザクションに新しいステップを追加する必要がある場合、制御クラスのみを変更すればよく、トランザクションの複雑さは線形に保たれ、ロールバックの管理が容易になります。

もちろん、このアプローチには欠点もあります。

依存型コントローラー: コントローラーにロジックを集中しすぎるリスク。

管理の難しさが増す: このモデルでは、さまざまなビジネス サービスの管理に加えて、追加の管理および制御サービスも必要になり、目に見えない形で管理の難しさや複雑さが増します。単一ポイントリスクもあります。コントローラーに問題が発生すると、ビジネス全体が麻痺してしまいます。

要約する

佐賀の概要はこちらです。まず第一に、Saga は分散型の長期トランザクションのためのソリューションです。トランザクションが長く、数が多く、複雑な状況、特にサービスが複数の企業によって開発され、制御できない場合は、Saga モデルを使用して分散トランザクションを処理できます。 Saga は、トランザクションの一貫性に対処するために、フォワード リカバリとバックワード リカバリの戦略を採用しています。前者は継続的な再試行によってトランザクションの完了を確実にしますが、後者はサブトランザクションの補正トランザクションを 1 つずつロールバックすることによってトランザクションを失敗としてマークします。分散調整に関しては、Saga はオーケストレーションと制御という 2 つのモードを採用しています。前者は、参加者 (サービス) がメッセージを介して通信し、イベントに基づいてトランザクションの実行プロセスを開始できるようにします。分散型モデルです。後者は、中央制御クラスを通じてトランザクションの実行およびロールバック手順を処理し、サービスの呼び出しとサービス フィードバックの受け入れを統合します。