マイクロサービスアーキテクチャにおける分散トランザクションの処理について知っておくべきこと

マイクロサービス アーキテクチャの創始者である Martin Fowler のアドバイスによると、マイクロサービス アーキテクチャでは分散トランザクションは可能な限り避けるべきです。しかし、一部の領域では、敵対的な敵のように、分散トランザクションは避けられません。

エンジニアリング分野では、分散トランザクションに関する議論は主に、強い一貫性と結果的一貫性のソリューションに焦点が当てられています。

一般的なソリューションは次のとおりです。

• 2 フェーズ コミット (2PC) スキーム。
• eBay イベント キュー ソリューション。
• TCC 補正モード。
• キャッシュされたデータの最終的な一貫性。

一貫性理論

分散トランザクションの目的は、サブデータベース データの一貫性を確保することですが、データベース間のトランザクションでは、個々のノードの壊滅的な障害など、さまざまな制御不能な問題が発生する可能性があります。単一マシンのトランザクションと同じ ACID を期待することは不可能です。

さらに、業界で有名な CAP 理論によれば、分散システムでは、データの一貫性、システムの可用性、およびパーティション耐性を規模に応じて同時に考慮する必要があるとも言われています。

2 フェーズ コミット プロトコル (2PC) は、分散トランザクションを実装するための従来のソリューションですが、2PC はスケーラビリティが低く、分散アーキテクチャで使用するにはコストがかかります。 eBay の設計者 Dan Pritchett は、大規模分散システムにおけるデータ一貫性の問題を解決するために BASE 理論を提案しました。

BASE 理論によれば、システムの強い一貫性を常に放棄することで、システムのスケーラビリティを獲得できるとされています。

01.CAP理論

分散システムでは、一貫性、可用性、パーティション耐性の 3 つの要素のうち、2 つだけを同時に満たすことができますが、両方を満たすことはできません。その中で、パーティション耐性は不可欠です。

• 一貫性:分散環境において複数のノードのデータが強く一貫しているかどうか。
• 可用性:分散サービスは常に可用性を確保できます。ユーザーがリクエストを送信すると、サービスは限られた時間内に結果を返すことができます。
• パーティション耐性:具体的には、ネットワーク パーティションに対する耐性を指します。

たとえば、Cassandra、Dynamo などでは、デフォルトでは C よりも AP が優先されます。 HBase、MongoDB などでは、デフォルトでは A よりも CP が優先されます。

02.BASE理論

中心的なアイデア:

• 基本的に利用可能:これは、分散システムに障害が発生した場合、コアの可用性を確保するために、ある程度の可用性の損失が許容されることを意味します。
• ソフト ステート:分散システムにおいて、システム全体の可用性に影響を与えない中間状態の存在を許可することを指します。
• 最終的な一貫性:分散システム内のすべてのデータのレプリカが、一定期間後に最終的に一貫した状態に到達できることを指します。

一貫性モデル

データ一貫性モデルは、次の 3 つのカテゴリに分類できます。

• 強力な一貫性:データが正常に更新されると、すべてのコピーのデータが常に一貫性を保ちます。これは通常、同期的に実現されます。
• 弱い一貫性:データが正常に更新された後、システムは最後に書き込まれた値がすぐに読み取れることを保証しません。また、読み取れるまでの特定の時間も保証しません。
• 結果的一貫性:弱い一貫性の一種。データが正常に更新された後、システムは最後に書き込まれた値をすぐに返すことを約束するわけではありませんが、最後の更新操作の値が最終的に返されることを保証します。

分散システム データの強い一貫性、弱い一貫性、および最終的な一貫性は、Quorum NRW アルゴリズムを通じて分析できます。

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

01.2PCソリューション——強力な一貫性

2PC の基本原則は、段階的に送信してログを保持することにより、トランザクション送信の段階的なステータスを記録することです。コンポーネントがクラッシュして再起動すると、トランザクション送信のステージ ステータスをログを通じて復元し、この状態ノードで再試行できます。

たとえば、コーディネーターを再起動した後、ログを使用して、送信が「準備」状態か「すべて準備」状態のどちらであるかを判断できます。前者の場合、一部のノードが正常に準備されていないか、すべてのノードが正常に準備されているがまだコミットを発行していないことを意味します。状態が復元された後、すべてのノードに対してRollBackが発行されます。

「すべて準備」状態の場合、コミットをすべてのノードに送信する必要があり、データベース ノードはコミットの冪等性を確保する必要があります。

2PC ソリューションには 3 つの問題があります。

• 同期ブロッキング。
• データに矛盾があります。
• 単一点の問題。

アップグレードされた 3PC ソリューションは、主に次の 2 つの改善によりこれらの問題を解決することを目指しています。

• タイムアウトメカニズムを追加しました。
• 2 つのフェーズの間に準備フェーズが挿入されます。

ただし、3 フェーズ コミットにもいくつかの欠陥があります。プロトコル レベルからデータの不整合を完全に回避するには、Paxos または Raft アルゴリズムを使用できます。

02.eBay イベント キュー ソリューション - 最終的な一貫性

eBay のアーキテクトである Dan Pritchett 氏は、BASE 原理を説明する論文「Base: An Acid Alternative」の中で、eBay の分散システムの一貫性の問題に対する解決策について言及しました。

その中心的なアイデアは、メッセージまたはログを介して分散処理を必要とするタスクを非同期的に実行することです。メッセージまたはログは、ローカル ファイル、データベース、またはメッセージ キューに保存され、ビジネス ルールに基づいて失敗した場合に再試行されます。各サービスのインターフェースがべき等性を持つことが要求されます。

説明されているシナリオでは、ユーザー テーブル user とトランザクション テーブル transaction があります。ユーザー テーブルには、ユーザー情報、合計売上、合計購入金額が格納されます。取引テーブルには、各取引のシリアル番号、購入者情報、販売者情報、取引金額が格納されます。トランザクションが生成された場合は、トランザクション テーブルにレコードを追加し、ユーザー テーブルの金額を変更する必要があります。

この論文で提案されている解決策は、トランザクション テーブル レコードの更新とユーザー テーブル更新メッセージをローカル トランザクションで完了することです。ユーザー テーブル更新メッセージの繰り返し消費の問題を回避するために、完了したトランザクションに関連する情報を記録する操作レコード テーブル updates_applied が追加されます。

このソリューションの中核は、第 2 フェーズの再試行とべき等実行にあります。失敗後の再試行は補償メカニズムであり、システムの最終的な一貫性を確保するための重要なプロセスです。

03. TCC (Try-Confirm-Cancel) 補償モード - 最終的な一貫性

図に示すビジネス モデルは、サービス A、サービス B、サービス C、サービス D で構成されるマイクロサービス アーキテクチャ システムです。サービス A は、操作を完了するために、サービス B、サービス C、サービス D を順番に呼び出す必要があります。

サービス A がサービス D の呼び出しに失敗した場合、システム全体のデータの一貫性を確保するために、サービス B と C の呼び出し操作をロールバックし、逆の復帰操作を実行する必要があります。ロールバックが成功すると、マイクロサービス システム全体のデータが整合されます。

これを実現するための 3 つの重要な要素:

• サービス呼び出しチェーンを記録する必要があります。
• 各サービス プロバイダーは、互いに補うために反対のビジネス ロジックを持つ一連の操作を提供する必要があり、ロールバック操作ではべき等性を確保する必要があります。
• 失敗の原因に応じて、異なるロールバック戦略を実装する必要があります。

実装における 2 つの困難:

• 補償モデルの特徴は、実装が簡単であることです。ただし、ほとんどの場合、ビジネス パラメータやビジネス ロジックが大きく異なるため、特にサービス チェーン レコードの場合、ある程度の普遍的なソリューションを形成することは困難です。
• 多くのビジネス特性により、サービスが安全なロールバック操作を提供するのは不可能です。

04. キャッシュされたデータの結果的一貫性

私たちのビジネス システムでは、通常、I/O 操作がデータベースに直接影響しないように、キャッシュ (Redis または Memcached) がデータ読み取り用のバッファとしてデータベースの前で使用されます。

商品詳細ページを例にとると、販売者が商品情報を変更してデータベースに書き戻すと、ユーザーが商品詳細ページで見る情報はキャッシュから取得した古いデータのままとなり、キャッシュ システムとデータベース システムの間でデータの不整合が発生します。

このシナリオでキャッシュとデータベース データの不一致の問題を解決するには、次の 2 つのソリューションがあります。

• キャッシュされたデータの有効期限を設定します。キャッシュ内のデータの有効期限が切れると、ビジネス システムはデータベースからデータを取得し、新しい値をキャッシュに格納します。この有効期限は、システムが最終的な一貫性に到達できる許容時間です。
• データベースデータを更新した後、同時にキャッシュデータもクリアしてください。データベースのデータが更新されると、キャッシュ内のデータは同期的に削除されるため、次回商品の詳細を取得するときには、データベースから直接取得され、キャッシュに同期されます。

選択の提案

データの一貫性の問題に直面した場合、まずビジネス ニーズの観点から 3 つの一貫性モデルの受け入れを決定し、次に特定のシナリオに基づいてソリューションを決定する必要があります。

アプリケーションの観点から見ると、分散トランザクションの実際のシナリオは避けられないことがよくあります。他のソリューションが利用可能になるまでは、2PC も良い選択肢です。

ショッピングや送金などの電子商取引や金融サービスの場合、ミドルウェア層の 2PC の最大の問題は、不可抗力や予期せぬ状況が発生すると、ビジネスが見えなくなり、一貫性が失われることです。

データノードが突然クラッシュした場合、ビジネスでは 2PC ログに基づいて補償することが困難になります。金融のシナリオでは、データの一貫性が生命線であり、企業はデータを完全に制御する必要があります。

TCC などの分散トランザクション モデル、またはメッセージ キューに基づく柔軟なトランザクション フレームワークを使用することをお勧めします。どちらのソリューションもビジネス層で実装されます。ビジネス開発者は十分な制御権を持ち、SOA フレームワークと組み合わせて、Dubbo、Spring Cloud などのアーキテクチャを構築できます。