Ant テクノロジー エキスパート: 1 つの記事で分散トランザクションを学ぶ

小さなアリは言いました。

分散トランザクションは、エンタープライズ統合における技術的な難しさであり、あらゆる分散システム アーキテクチャに関係するものでもあります。特に近年普及が進むマイクロサービスアーキテクチャにおいては、それは避けられないことと言ってもいいでしょう。この記事では、分散トランザクションのさまざまな側面を紹介します。

1. 事務

1.1 トランザクションとは何か

データベース トランザクション (略称: トランザクション) とは、データベース実行プロセスにおける論理単位を指し、データベース操作の有限シーケンスで構成されます。

[[233927]]

トランザクションには、通常 ACID 特性と呼ばれる次の 4 つの特性があります。

アトミック性: トランザクションは全体として実行され、そこに含まれるデータベースに対するすべての操作は、すべて実行されるか、まったく実行されないかのいずれかになります。

一貫性: トランザクションは、データベースの状態が 1 つの一貫した状態から別の一貫した状態に変換されることを保証する必要があります。一貫性のある状態とは、データベース内のデータが整合性制約を満たす必要があることを意味します。さらに、一貫性には別のセマンティクス レイヤーがあり、トランザクションの中間状態を観察することはできません (このセマンティクス レイヤーはアトミック性に属するとも言われます)。

分離: 複数のトランザクションが同時に実行される場合、データベースによってこの 1 つの操作のみが実行されるかのように、1 つのトランザクションの実行が他のトランザクションの実行に影響を与えてはなりません。

耐久性: コミットされたトランザクションによってデータベースに加えられた変更は、データベースに永続的に保存される必要があります。トランザクションの終了時に、このアクションは元に戻せません。

1.2 地域情勢

当初、トランザクションは単一のデータベース リソースへのアクセスの制御に限定されていました。

アーキテクチャがサービス指向になった後、トランザクションの概念がサービスに拡張されました。単一のサービス操作をトランザクションと見なす場合、サービス操作全体は単一のデータベース リソースのみを関与させることができます。

単一のサービスと単一のデータベース リソースへのアクセスに基づくこのタイプのトランザクションは、ローカル トランザクションと呼ばれます。

2. 分散トランザクションアプリケーションアーキテクチャ

ローカル トランザクションは主に単一のセッションに制限され、複数のデータベース リソースは関与しません。しかし、SOA（サービス指向アーキテクチャ）に基づく分散アプリケーション環境では、複数のデータベース リソースや複数のサービスへのアクセスを同じトランザクションに含める必要があるアプリケーションが増え、分散トランザクションが生まれます。

最も初期の分散トランザクション アプリケーション アーキテクチャは非常にシンプルで、サービス間のアクセス呼び出しは必要ありませんでした。サービス内の操作のみが複数のデータベース リソースへのアクセスを伴いました。

サービス操作がさまざまなデータベース リソースにアクセスし、そのアクセスにトランザクション特性を持たせたい場合は、分散トランザクションを使用してすべてのトランザクション参加者を調整する必要があります。

上記で紹介した分散トランザクション アプリケーション アーキテクチャでは、サービス操作が複数のデータベース リソースにアクセスしますが、トランザクション全体は単一のサービス内で制御されます。サービス操作で別のサービスを呼び出す必要がある場合、トランザクションは複数のサービスにまたがる必要があります。この場合、あるサービスから開始されたトランザクションが別のサービスを呼び出すと、呼び出されたサービスがアクセスするリソースがトランザクションに自動的に追加されるように、何らかのメカニズムを介してトランザクションが他のサービスに流れる必要があります。次の図は、複数のサービスにわたるこのような分散トランザクションを反映しています。

上記の 2 つのシナリオ (サービスが複数のデータベース リソースまたは他のサービスを呼び出すことができる) を組み合わせて拡張すると、分散トランザクション全体の参加者は、次の図に示すようにツリー トポロジを形成します。サービス間分散トランザクションでは、トランザクションの開始者とコミッターは同じであり、呼び出し元のクライアント全体、またはクライアントが最初に呼び出すサービスである可能性があります。

単一のデータベース リソースへのアクセスに基づくローカル トランザクションと比較すると、分散トランザクションのアプリケーション アーキテクチャはより複雑です。異なる分散アプリケーション アーキテクチャでは、複数のリソースの調整、サービス間のトランザクションの伝播など、分散トランザクションの実装で考慮すべき問題がまったく同じではなく、実装メカニズムも複雑で多様です。考慮すべきエンジニアリングの詳細は非常に多くありますが、分散トランザクションの中核は依然として ACID 特性です。したがって、分散トランザクションを理解したい場合は、まずトランザクションの ACID 特性がどのように実装されるかを理解することから始める必要があります。

次の記事では、最も一般的な 2 つの分散トランザクション モデルから始めて、分散トランザクションの基本的な共通点、つまり分散トランザクションの ACID 特性を確保する方法の分析に焦点を当てます。

3. 一般的な分散トランザクションモデルのACID実装の分析

3.1 X/Open XA プロトコル

最も初期の分散トランザクション モデルは、X/Open International Alliance によって提案された X/Open 分散トランザクション処理 (DTP) モデルであり、X/Open XA プロトコル、または略して XA プロトコルと呼ばれることもあります。

DTP モデルには、グローバル トランザクション マネージャー (TM) と複数のリソース マネージャー (RM) が含まれます。グローバル トランザクション マネージャーは、グローバル トランザクションのステータスと参加リソースを管理し、コミットまたはロールバックするリソースを調整する役割を担います。リソース マネージャーは特定のリソース操作を担当します。

XA プロトコルは、TM と RM 間のインターフェースを記述し、同じ分散トランザクションで複数のリソースにアクセスできるようにします。

DTP モデルに基づく分散トランザクション プロセスは次のとおりです。

1. アプリケーション (AP) が TM にグローバル トランザクションの開始を申請します。

2. RM を操作するには、まず AP が TM に登録します (TM は AP がどの RM を操作したか、つまり支店取引を記録する責任があります)。 TM は、XA インターフェース機能を通じて対応する RM に分散トランザクションのサブトランザクションを開始するように通知し、その後、AP は RM によって管理されるリソースを操作できるようになります。

3. AP がすべての RM に対する操作を完了すると、AP は実行ステータスに基づいて TM にグローバル トランザクションをコミットまたはロールバックするように通知し、TM は XA インターフェース機能を通じて各 RM に操作を完了するように通知します。 TM はまず各 RM に事前コミットを行うように要求します。すべての RM が成功を返すと、各 RM に正式なコミットを実行するように要求します。 XA プロトコルでは、RM 事前コミットが成功すると、後続の正式なコミットも成功する必要があります。いずれかの RM 事前コミットが失敗した場合、TM は各 RM にロールバックするように通知します。

4. すべての RM がコミットまたはロールバックされると、グローバル トランザクションが終了します。

3.1.1 原子性

XA プロトコルは、2PC (2 フェーズ コミット) アトミック コミット プロトコルを使用して、分散トランザクションのアトミック性を保証します。

2 フェーズ コミットとは、コミット プロセスを準備フェーズ (投票フェーズ) とコミット フェーズ (実行フェーズ) の 2 つのフェーズに分割することを意味します。

準備段階:

TM は各 RM に準備メッセージを送信します。 RM のローカル トランザクション操作が正常に実行された場合、成功が返されます。 RM のローカル トランザクション操作が失敗した場合は、失敗が返されます。

提出フェーズ

TM がすべての RM から成功メッセージを受信した場合、各 RM にコミット メッセージを送信します。それ以外の場合は、ロールバック メッセージを送信します。 RM は TM の指示に従ってローカル トランザクションをコミットまたはロールバックし、トランザクション プロセスで使用されるすべてのロック リソースを解放します。

3.1.2 分離

XA プロトコルでは、分散トランザクションの分離を実現する方法については説明されていませんが、XA プロトコルでは、DTP モデル内の各 RM がローカル トランザクションを実装する必要があることが規定されています。つまり、XA プロトコルに基づいて実装された分散トランザクションの分離は、各 RM のローカル トランザクションの分離によって保証されます。分散トランザクションのすべてのサブトランザクションが分離されると、分散トランザクションは自然に分離を実現します。

MySQL を例にとると、MySQL は 2PL (2 フェーズ ロック) メカニズムを使用して、ローカル トランザクションの同時実行を制御し、分離を保証します。 2PL は、ロック操作をロックとロック解除の 2 つのフェーズに分割し、2 つのフェーズが完全に分離されていることを保証するという点で 2PC に似ています。ロックフェーズでは、ロックが追加されるだけで、解除されることはありません。ロック解除フェーズでは、ロックは解除されるだけで、ロックはされません。

上図に示すように、ローカル トランザクションでは、各更新操作を実行する前に、まず対応するロック リソースが取得されます。ロック リソースが正常に取得された場合にのみ操作が実行され、ロック リソースが取得されると、このトランザクションの実行が完了するまでロック リソースは保持されます。

この 2PL メカニズムにより、MySQL は、ローカル トランザクションの実行中に他の同時トランザクションが同じリソースを操作できないようにし、トランザクションの分離を実現します。

3.1.3 一貫性

前述したように、一貫性には 2 つのレベルのセマンティクスがあります。 1 つのレベルは、トランザクションが完了した後、データベースが 1 つの一貫した状態から別の一貫した状態に変化することを保証することです。セマンティクスのもう 1 つのレイヤーは、トランザクション実行中の中間状態を観察できないことです。

セマンティクスの最初の層の実装は非常に単純であり、原子性、分離性、および RM 自身の一貫性の実装によって保証できます。後者のセマンティクス層については、まず、単一の RM 上のローカル トランザクションがどのように実装されるかを見てみましょう。 MySQL を例にとると、MySQL は MVCC (Multi Version Concurrency Control) メカニズムを通じて各一貫性状態のスナップショットを生成します。各トランザクションは各スナップショットに対応する一貫性状態を確認するため、ローカル トランザクションの中間状態が観察されないことが保証されます。

スナップショットは単一の RM に実装されていますが、分散アプリケーション アーキテクチャではどのような問題が発生しますか?

上図に示すように、RM1 のローカル サブトランザクション送信の完了から RM2 のローカル サブトランザクション送信の完了までの間は、RM1 上のサブトランザクション実行の内容のみを読み取ることができ、RM2 上のサブトランザクションは読み取ることができません。つまり、単一の RM 上のローカル トランザクションは一貫していますが、グローバルな観点から見ると、グローバル トランザクション実行プロセスの中間状態が観察され、グローバルな一貫性が破壊されます。

XA プロトコルでは、グローバル スナップショットを実装する方法は定義されていません。たとえば、MySQL の公式ドキュメントでは、分散トランザクションの一貫性を確保するために、シリアル化可能な分離レベルを使用することを推奨しています。「非分散トランザクションと同様に、アプリケーションが読み取り現象に敏感な場合は、SERIALIZABLE が推奨されます。REPEATABLE READ は分散トランザクションには不十分な場合があります。」 (分散トランザクションの場合、繰り返し読み取り分離レベルではトランザクションの一貫性を保証するのに十分ではありません。プログラムにグローバル一貫性読み取り要件がある場合は、シリアル化可能分離レベルを検討できます。)

もちろん、シリアル化分離レベルのパフォーマンスが低いため、多くの分散データベースでは、グローバルな一貫性のある読み取りを提供するために独自の分散 MVCC メカニズムを実装しています。基本的な考え方は、集中化されたオブジェクトまたは論理的に単調に増加するオブジェクトを使用して、グローバル スナップショットの生成を制御し、トランザクションまたは SQL ステートメントごとに 1 回取得して、さまざまな分離レベルで一貫性を実現することです。たとえば、Google の Spanner は TrueTime を使用してグローバル スナップショットへのアクセスを制御します。

3.1.4 まとめ

XA プロトコルは通常、データベース リソース層で実装され、リソース マネージャーに対して直接動作します。したがって、XA プロトコルに基づいて実装された分散トランザクション製品は、分散データベースであれ、分散トランザクション フレームワークであれ、通常のデータベースを使用する場合と同様に、ビジネスにほとんど影響を与えません。

XA プロトコルは、トランザクションの ACID 特性を厳密に保証し、あらゆるビジネス領域の機能要件を満たすことができます。しかし、それは諸刃の剣でもあります。

分離の相互排他要件により、トランザクション実行中はすべてのリソースがロックされます。これは、実行時間が一定の短いトランザクションにのみ適用されます。同時に、データはトランザクション全体を通じて排他的であり、ホット データの同時パフォーマンスは非常に低くなる可能性があります。分散 MVCC または楽観的ロックを実装すると、パフォーマンスが向上する可能性があります。

同時に、一貫性を保証するために、すべての RM は同等に信頼性と信頼性が高く、障害回復メカニズムは信頼性が高く高速である必要があります。ネットワーク障害分離の場合、サービスは基本的に利用できません。

3.2 TCCモデル

TCC (Try-Confirm-Cancel) 分散トランザクション モデルは、XA などの従来のモデルと比較して、分散トランザクションをリソース マネージャー (RM) のサポートに依存せず、ビジネス ロジックを分解して分散トランザクションを実装する点が特徴です。

TCC モデルでは、ビジネス システム内の特定のビジネス ロジックが外部にサービスを提供するときに、ある程度の不確実性を受け入れる必要があると考えています。つまり、ビジネス ロジックの初期操作の呼び出しは一時的な操作にすぎず、それを呼び出すメインのビジネス サービスは後でそれをキャンセルする権利を留保します。メイン ビジネス サービスがグローバル トランザクションをロールバックする必要があると判断した場合、スレーブ ビジネス サービスのキャンセル操作に対応する以前の一時操作のキャンセルを要求します。メイン ビジネス サービスは、グローバル トランザクションをコミットする必要があると判断した場合、スレーブ ビジネス サービスの確認操作に対応する以前の一時操作をキャンセルする権利を放棄します。すべての初期操作は最終的に確認されるかキャンセルされます。

したがって、特定のビジネス サービスの場合、TCC 分散トランザクション モデルでは、ビジネス システムが次の 3 つのビジネス ロジックを提供する必要があります。

初期操作の試行: すべてのビジネス チェックを完了し、必要なビジネス リソースを予約します。

確認操作: 実際のビジネス ロジックはビジネス チェックなしで実行され、Try ステージで予約されたビジネス リソースのみが使用されます。したがって、Try 操作が成功する限り、Confirm も成功する必要があります。さらに、分散トランザクションが 1 回だけ成功することを保証するために、確認操作は冪等性を満たす必要があります。

キャンセル操作: 試行フェーズで予約されたビジネス リソースを解放します。同様に、キャンセル操作も冪等性を満たす必要があります。

TCC 分散トランザクション モデルは、次の 3 つの部分で構成されます。

メインビジネス サービス: メインビジネス サービスは、ビジネス アクティビティ全体の開始者であり、サービスのオーケストレーターです。ビジネス活動全体の開始と完了を担当します。

スレーブ ビジネス サービス: スレーブ ビジネス サービスは、ビジネス アクティビティ全体の参加者であり、TCC ビジネス操作を提供し、メイン ビジネス サービスが呼び出すための予備操作 (Try)、確認操作 (Confirm)、キャンセル操作 (Cancel) の 3 つのインターフェイスを実装する役割を担います。

ビジネス アクティビティ マネージャ: ビジネス アクティビティ マネージャは、TCC グローバル トランザクションのトランザクション ステータスと各スレーブ ビジネス サービスのサブトランザクション ステータスの記録と維持、ビジネス アクティビティの送信時にすべてのスレーブ ビジネス サービスの確認操作を呼び出すこと、ビジネス アクティビティがキャンセルされたときにすべてのスレーブ ビジネス サービスのキャンセル操作を呼び出すことなど、ビジネス アクティビティ全体を管理および制御します。

完全な TCC 分散トランザクション プロセスは次のとおりです。

メインビジネス サービスはまずローカル トランザクションを開始します。

メインビジネスサービスは、分散トランザクションのメインビジネスアクティビティを開始するためにビジネスアクティビティマネージャーに適用されます。

次に、スレーブ ビジネス サービスが呼び出されるために、マスター ビジネス アクティビティはまずスレーブ ビジネス アクティビティをビジネス アクティビティ マネージャーに登録し、次にスレーブ ビジネス サービスの Try インターフェイスを呼び出します。

ビジネス サービスからのすべての Try インターフェイス呼び出しが成功すると、メイン ビジネス サービスはローカル トランザクションをコミットします。呼び出しが失敗した場合、メイン ビジネス サービスはローカル トランザクションをロールバックします。

メインビジネスサービスがローカルトランザクションをコミットすると、TCC モデルはすべてのスレーブビジネスサービスの確認インターフェースをそれぞれ呼び出します。メインビジネスサービスがローカルトランザクションをロールバックする場合は、それぞれCancelインターフェースが呼び出されます。

ビジネス サービスからのすべての確認またはキャンセル操作が完了すると、グローバル トランザクションは終了します。

3.2.1 原子性

TCC モデルでは、トランザクションのアトミック性を保証するために 2PC アトミック コミット プロトコルも使用されます。 Try 操作は、2PC の第 1 段階の準備 (Prepare) に対応します。 Confirm は 2PC の 2 段階目の送信 (Commit) に対応し、Cancel は 2PC の 2 段階目のロールバック (Rollback) に対応します。 TCC はアプリケーション層の 2PC と言えます。

3.2.2 分離

TCC 分散トランザクション モデルは、分散トランザクションのアトミック性を保証するために、2 フェーズのアトミック コミット プロトコルのみを提供します。トランザクションの分離はビジネス ロジックによって実装されます。

分離の本質は、同時実行性を制御し、同時トランザクションが同じリソース上で動作して結果に混乱が生じるのを防ぐことです。

たとえば、金融業界では、ユーザーが取引を開始すると、通常、最初にユーザーの資金がチェックされます。資金が十分であれば、対応する取引金額が差し引かれ、売り手の資金が増加し、取引が完了します。トランザクション分離がない場合、ユーザーは同時に 2 つのトランザクションを開始します。両方の取引のチェックでは十分な資金があることを示していますが、実際には 1 つの取引の支払いに十分な資金しかありません。その結果、両方の取引が正常に支払われ、資本損失が発生します。

同時実行制御はビジネス ロジックの正しい実行を保証するものであることがわかりますが、2 フェーズ ロックなどの同時アクセス制御テクノロジでは、トランザクション全体が実行されるまでデータベース リソースのロックを保持する必要があります。特に分散トランザクション アーキテクチャでは、分散トランザクションの 2 番目のフェーズが実行されるまでロックを保持する必要があります。つまり、分散トランザクションではリソース ロックの保持時間が長くなり、同時実行パフォーマンスがさらに低下することになります。

したがって、TCC モデルの分離の考え方は、ビジネスを変革し、*** 段階以降に基礎となるデータベース リソース レベルでのロックから上位ビジネス レベルでのロックに移行することで、基礎となるデータベース ロック リソースを解放し、分散トランザクション ロック プロトコルを緩和し、ビジネスの同時実行パフォーマンスを向上させることです。

上記の例をもう一度見てみましょう。

*** ステージ: ユーザーの資金を確認します。資金が十分であれば、ユーザーの取引資金を凍結します。この資金はビジネスによって分離されており、この取引以外の同時取引で使用することはできません。

第 2 段階: 第 1 段階で事前に凍結されたユーザーの資金を差し引き、販売者の資金を増額して取引を完了します。ビジネスロック方式を採用することで、ユーザーの資金は隔離・凍結され、基礎となるリソースロックは***段階後に直接解除されます。ユーザーと販売者の他のトランザクションは、分散トランザクション全体の終了を待たずにすぐに同時に実行できるため、より高い同時トランザクション機能を実現できます。

3.2.3 一貫性

TCC 分散トランザクション モデルにおける一貫性の実装を見てみましょう。一貫性レイヤーのセマンティクスを実装する XA プロトコルと同様に、アトミック性を通じてトランザクションのアトミック送信を保証し、ビジネス分離を通じてトランザクションへの同時アクセスを制御して、分散トランザクションの一貫した状態遷移を実現します。

第 2 レベルのセマンティクスに関しては、トランザクションの中間状態を観察することはできません。 SOA 分散アプリケーション環境で必要かどうかを見てみましょう。

会計サービスを例に挙げてみましょう。振替業務（ユーザーA ? ユーザーB）は、取引サービスと会計サービスからなる分散トランザクションで構成されます。トランザクションサービスはメインビジネスサービスであり、会計サービスはスレーブビジネスサービスです。会計サービスの Try 操作により、ユーザー A の資金が事前に凍結されます。コミット操作により、ユーザー A の事前凍結資金が差し引かれ、ユーザー B の利用可能な資金が増加します。キャンセル操作により、ユーザー A の凍結済み資金が解除されます。

アカウンティング サービスが Try フェーズを完了すると、メイン トランザクションをコミットできるようになり、その後、TCC フレームワークはアカウンティングの Commit フェーズを呼び出します。アカウントコミットフェーズが完了する前に、ユーザー A は自分の残高が差し引かれたことを確認できますが、この時点ではユーザー B の利用可能な資金は増加していません。

システム的な観点から見ると、確かに問題や不確実性は存在します。最初のステージの終了と 2 番目のステージの終了の間には遅延があります。この期間中、資産を享受するユーザーはいないようです。

ただし、ユーザーの観点から見ると、この時間間隔は重要ではないか、まったく存在しない可能性があります。特に、この時間間隔が数秒しかない場合、資産の転送について具体的に通信しているユーザーにとっては、プロセスは隠されているか、実際に許容可能であり、結果の最終的な一貫性が保証されます。

もちろん、このようなシステムでは、システムの特定の一貫性状態を本当にチェックする必要がある場合は、追加の方法を使用してそれを実現できます。

一般的に、サービス間の一貫性は、サービス内の一貫性よりも弱まりやすいです。このため、リソース レベルで一般的な分散トランザクションを直接実装する XA などのモデルでは、一貫性の確保に重点が置かれます。しかし、サービスレベルになると、サービス間の機能分割や論理分離が実現され、一貫性が弱まりやすくなります。これは、SOA アーキテクチャにおける BASE 理論の究極の一貫性の考え方です。

BASE 理論は、BA (基本的な可用性)、S (ソフト状態)、E (最終的な一貫性) を指します。この理論では、可用性、パフォーマンス、および劣化したサービスのニーズを満たすために、一貫性の要件を適切に下げることができる、つまり「基本的に利用可能で、最終的に一貫性がある」と主張しています。

業界では通常、ACID に厳密に従うトランザクションをリジッド トランザクションと呼び、BASE コンセプトに基づいて実装されたトランザクションをフレキシブル トランザクションと呼びます。柔軟なトランザクションは ACID を完全に放棄するのではなく、一貫性の要件を緩和するだけです。トランザクションが完了した後の一貫性は厳密に遵守され、トランザクション中の一貫性は適切に緩和できます。

3.2.4 まとめ

TCC 分散トランザクション モデルのビジネス実装特性により、DB とサービス全体にわたるリソース管理を実装し、TCC モデルを通じてさまざまな DB アクセスとさまざまなビジネス操作をアトミック操作に調整して、分散アプリケーション アーキテクチャ シナリオにおけるトランザクションの問題を解決できます。

TCC モデルは、2PC アトミック コミット プロトコルを通じて分散トランザクションのアトミック性を保証し、リソース レイヤーからビジネス レイヤーへの分離を高めて、実装をビジネス ロジックに任せます。各 TCC 操作は、リソース レイヤーの単一のローカル トランザクションです。操作が完了すると、ローカル トランザクションが終了するため、2PC および 2PL 下のリソース レイヤーでのリソース占有によってパフォーマンスが低下する問題を回避できます。

同時に、TCC モデルは、ピークシェービングと谷埋めを実現するための非同期トランザクションなど、ビジネスニーズに応じてカスタマイズされた機能も提供できます。

ただし、TCC モデルへのビジネス アクセスでは、ビジネス ロジックを 2 段階に分割し、Try、Confirm、Cancel の 3 つのインターフェイスを実装する必要があり、高度なカスタマイズと高い開発コストがかかります。

IV.結論

この記事ではまず、分散トランザクションの一般的なアーキテクチャ シナリオを紹介します。分散トランザクションはもともと、複数のデータベース リソースを持つ単一のサービスのシナリオを解決するために設計されました。テクノロジーの発展、特に SOA 分散アプリケーション アーキテクチャの登場とマイクロサービス時代の到来により、サービスは基本的なビジネス ユニットになりました。したがって、サービス全体にわたる分散トランザクションが必要になります。次に、一般的に使用されている 2 つの分散トランザクション モデルである XA と TCC から始めて、それぞれのモデルが分散トランザクションの ACID 特性をどのように実装するかを分析することに焦点を当てながら、それらの実装メカニズムを紹介します。