マイクロサービスアーキテクチャによる分散トランザクションソリューション

[[426291]]

ビジネスの急速な発展とビジネスの複雑性の増大に伴い、従来のモノリシック アプリケーションでは、開発効率の低さ、保守性の低さ、アーキテクチャのスケーラビリティの低さ、柔軟な展開のなさ、堅牢性の低さなど、いくつかの問題が徐々に明らかになってきています。

マイクロサービス アーキテクチャは、業務に応じて独立したサービス ユニットに分割された分散システムであり、モノリシック システムの欠点を解決しながら、ますます複雑化するビジネス ニーズにも対応します。各マイクロサービスは、1 つのタスクのみを適切に実行することに重点を置いています。

マイクロサービスアーキテクチャの特徴

マイクロサービス アーキテクチャの利点は非常に明白であり、近年急速に発展しています。

1. 複雑なビジネスを複数の小規模ビジネスに分割すると、ビジネスの再利用性が向上し、人員編成や分業が容易になります。
2. サービスは独立して展開および拡張され、各サービスの変更および展開は他のサービスに影響を与えません。
3. 各サービスは、ビジネスシナリオに基づいて適切なプログラミング言語とデータベースを選択できます。

マイクロサービスには上記のような利点がありますが、次のような多くの新たな問題も生じます。

1. サービスの数が多くなると、テスト、展開、監視が難しくなります。
2. モノリシックアプリケーションが分散システムに分割されると、プロセス間の通信メカニズムと障害処理対策がより複雑になります。
3. システムをマイクロサービス化すると、元々サービス内にあったローカル データベース トランザクションが複数のサービスに分割され、分散環境でトランザクションの一貫性を確保する必要があります。

上記の問題のうち、1と2は近年登場したさまざまなマイクロサービス技術によって解決できます。たとえば、Kubernetes はサービス検出とサービスガバナンスを提供します。したがって、分散トランザクションは、マイクロサービスの実装に対する最大の障害となり、最も困難な技術的問題にもなっています。以下では、マイクロサービス アーキテクチャにおける分散トランザクションのソリューションについて詳しく説明します。

ローカルトランザクションから分散トランザクションへの進化

送金を例に挙げてみましょう。 A が B に 100 元を送金する必要がある場合、A の残高は -100 元、B の残高は +100 元である必要があります。単一ボディモードでは、ローカルトランザクションを通じてこれを解決できます。

地方問題

複数のステートメントをまとめて操作する機能をデータベーストランザクションと呼びます。データベース トランザクションにより、トランザクションのスコープ内のすべての操作が成功または失敗することを保証できます。トランザクションが失敗した場合、SQL ステートメントが実行されなかった場合と同じ結果となり、データベース データは変更されません。

データベース トランザクションには、次の 4 つの ACID 特性があります。

• A: アトミック、アトミック性、すべての SQL をアトミック作業単位として実行します。すべてを実行するか、まったく実行しません。
• C: 一貫しています。トランザクションが完了すると、すべてのデータのステータスが一貫したものになります。つまり、アカウント A から 100 を減算する限り、アカウント B に 100 を追加する必要があります。
• I: 孤立。複数のトランザクションが同時に実行される場合、各トランザクションによって行われた変更は他のトランザクションから分離される必要があります。
• D: 期間、永続性。つまり、トランザクションが完了した後、データベース データへの変更は永続的に保存されます。

分散トランザクションの典型的なシナリオ

銀行間送金業務は、典型的な分散型トランザクションのシナリオです。 A が銀行間で B に送金する必要がある場合、2 つの銀行のデータが関係します。転送の正確性は、データベースのローカル トランザクションでは保証できず、分散トランザクションを通じてのみ解決できます。

サービスをマイクロサービスに分割する場合、分散トランザクションを必要とするシナリオが多数あります。マイクロサービスのベスト プラクティスでは、分散トランザクションを可能な限り回避することが推奨されていますが、多くのビジネス シナリオでは、分散トランザクションは避けられない技術的な問題です。

分散トランザクションソリューション

一般的な分散トランザクション モードには、XA、TCC、SAGA、信頼性の高いメッセージングなどがあります。以下は簡単な紹介です

2 フェーズ コミット/XA

XA は、X/Open 組織によって提案された分散トランザクション仕様です。 XA 仕様は主に、(グローバル) トランザクション マネージャー (TM) と (ローカル) リソース マネージャー (RM) 間のインターフェイスを定義します。 MySQL などのローカル データベースは、XA で RM の役割を果たします。

XA は 2 つの段階に分かれています。

最初のフェーズ (準備): 参加しているすべての RM がトランザクションの実行を準備し、必要なリソースをロックします。参加者の準備ができたら、TM に準備ができたことを報告します。

フェーズ 2 (コミット/ロールバック): トランザクション マネージャー (TM) は、すべての参加者 (RM) の準備ができていることを確認すると、すべての参加者にコミット コマンドを送信します。

現在、MySQL、Oracle、SQLServer、PostgreSQL など、ほとんどの主流データベースは XA トランザクションをサポートしています。

正常に完了した XA トランザクションのタイミング図は次のとおりです。

TCC事業計画

TCC ソリューションは、実際には XA 送信の改善です。ビジネス ロジック全体の各ブランチを、Try、Confirm、Cancel の 3 つの操作に明示的に分割します。 try 部分はビジネスの準備を完了し、confirm 部分はビジネスの送信を完了し、cancel 部分はトランザクションのロールバックを完了します。

トランザクションが開始されると、ビジネス アプリケーションはトランザクション コーディネータに登録してトランザクションを開始します。次に、ビジネス アプリケーションはすべてのサービスの try インターフェイスを呼び出して、準備の最初の段階を完了します。トランザクション コーディネータは、try インターフェイスの戻りステータスに基づいて、confirm インターフェイスを呼び出すか、cancel インターフェイスを呼び出すかを決定します。 API 呼び出しが失敗した場合は再試行されます。

正常に完了した TCC トランザクションのタイミング図は次のとおりです。

SAGA事業計画

Saga は、TCC と同様に、最終的に一貫性のあるトランザクションであり、柔軟なトランザクションでもあります。 Saga の本質は、長いトランザクションを小さなトランザクションに分割し、各トランザクションに実行モジュールと補正モジュールを含めることです。

Saga は try を使用せず、トランザクションを直接コミットするため、ダーティ リードが発生する可能性があります。これは、一貫性の要件が高い一部のシナリオでは受け入れられません。

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

サブトランザクションの実行中にサブトランザクションに対応するローカル トランザクションが失敗した場合、Saga は逆の順序で補正トランザクションを実行します。

正常に完了した SAGA トランザクションのタイミング図は次のとおりです。

信頼できるニュース

メッセージ一貫性ソリューションは、メッセージ ミドルウェアを通じて上流および下流のアプリケーション データ操作の一貫性を保証します。基本的な考え方は、ローカル操作とメッセージ送信をローカル トランザクションに配置して、ローカル操作とメッセージ送信の両方が成功するか、両方が失敗するかを確実にすることです。ダウンストリーム アプリケーションはメッセージ システムをサブスクライブし、メッセージを受信した後に対応する操作を実行します。

RocketMQ は、参照できる典型的な信頼性の高いメッセージ インターフェイスを提供します。

分散トランザクションオープンソースプロジェクト

現在、分散トランザクション分野では、Seata に代表される Java 言語のオープンソース プロジェクトが存在します。非Java分野ではGo言語のDTMが代表的なプロジェクトです。 DTM は、XA、TCC、SAGA、および信頼性の高いメッセージングをサポートします。アーキテクチャ図は次のとおりです。

図中の役割は XA モデルのロール モデルと一致しており、次のように説明されます。

• AP アプリケーション (トランザクションの定義と送信、現在は Go 言語をサポートしており、近々 Nodejs、Python、PHP、Rust などもサポートされる予定です)
• RM リソース マネージャー (ローカル業務の管理を担当、言語制限なし、HTTP 関連のインターフェイスが提供されている限り)
• TM トランザクション マネージャー (DTM、グローバル トランザクションの調整、コミット、ロールバック)

上記のアーキテクチャ図では、AP は、既存のマイクロサービスにほとんど影響を与えない DTM によって提供される分散トランザクション インターフェイスを介して RM および TM と対話します。

また、実際の業務では、AP と RM の役割が重複することもあります。たとえば、TCC モードでは、AP は独自のローカル トランザクションを持つことができ、他のトランザクション ブランチを登録して呼び出すこともできます。