2.7 トランザクション・プロトコルについて

提供されている情報を使用して、業務要件に基づいてアプリケーションのトランザクション・プロトコルを選択します。

ビジネス・ユース・ケースが変わると必要な一貫性のレベルも変わります。たとえば、送金を行う金融アプリケーションには、厳密かつグローバルな一貫性が必要です。XAトランザクション・プロトコルはそのようなアプリケーションに適しています。XAは最適なトランザクション一貫性を提供する一方で、開発者の労力が最小限に抑えられるためです。また、通常、旅行予約ではこのレベルの一貫性は必要ないため、LRAが適しています。LRAトランザクションは、開発者にとっては複雑ですが、最大の柔軟性を提供します。

次の表に、アプリケーションのトランザクション・プロトコルの選択に役立ついくつかのパラメータを示します。

パラメータ	XA	LRA	TCC
トランザクションの一貫性レベル	最も厳密	結果	厳密
内容を保証しない読取り	不可	可	不可
アプリケーション開発の複雑さ	低	高	中
タイムアウトまたはエラー時の自動ロールバック	可	可	可
トランザクション・パフォーマンス	良	さらに良い	最良
トランザクション中のロックの保持	可	不可	不可

XA参加側は、トランザクションの間、ロックを保持します。LRAおよびTCCは、参加側のビジネス・ロジックの期間のみに対応するローカル・トランザクションを使用します。

XAトランザクションプロトコル

アプリケーションでこのプロトコルを使用するのは、プログラミング・モデルがアプリケーションに課す要件が最小限であり、アプリケーションのみがトランザクションの境界と結果を決定するときです。また、サービスがACID要件を満たす必要がある場合にもXAを使用できます。この要件では、すべての参加側が1つの一貫した状態から別の一貫した状態に移行し、完全な分離とシリアライズ可能性を備えることが必要です。

シリアライズ可能性を確保するために、リソース・マネージャは、トランザクションの処理中に、読取り、書込み、削除が行われたリソースをロックします。つまり、これらの同じリソースを使用する他のトランザクションは、それらのロックが解放されるまで待機する必要があります。このシリアライズでは、このようなロックをリクエストが待機するため、アプリケーションのパフォーマンスが大幅に制限される可能性があります。

XAで発生する可能性があるもう1つのパフォーマンスの問題は、トランザクションに追加される待機時間です。影響は、実際のビジネス・リクエストのレイテンシとXA操作のレイテンシによって異なります。たとえば、複数のマイクロサービスにまたがるビジネス・リクエストに800ミリ秒かかる場合は、XA操作によってさらに200ミリ秒が追加されても、重要性に大きな影響があるとはいえません。ただし、ビジネス・リクエストにかかるのが50ミリ秒で、XA操作のレイテンシによってさらに200ミリ秒追加される場合は、アプリケーションのパフォーマンスに大きな影響があるといえます。

LRAトランザクション・プロトコル

このプロトコルは、XAトランザクション・プロトコルの使用に適さない可能性があるアプリケーションに使用します。XAトランザクションにはリソースのロックが伴うため、XAトランザクションではマシン間の相互作用のみを行って比較的短時間で終わるようにすることをお薦めします。LRAプロトコルの方が適しているのは、ユーザーがトランザクションの意思決定プロセスに関与する場合、または数分もしくは数時間以上実行する可能性がある長いワークフローの場合です。

LRAプロトコルはリソースをロックしないため、シリアライズによるパフォーマンスの問題が発生せず、大きな利点があります。シリアライズの問題を回避できるためパフォーマンスに有利ですが、LRAによってアプリケーションに多少の負担がかかります。LRAトランザクションの中止すなわち取消しが行われるとき、アプリケーション開発者は、適切な補正アクションを実行するためにコードを用意する必要があります。預入れを引出しで補正するのは当然であるため、これは簡単に思えるかもしれません。ただし、さらに別の引出しが発生すると、補正のための引出しを行う十分な資金が存在しないことが考えられます。このケースでは、補正アクションが失敗し、トランザクションがヒューリスティックな結果になる可能性があります。その他の多くのケースで、補正アクションの実装が非常に困難または実用的でない場合があります。補正アクションを作成するのはアプリケーション開発者の責任ですが、すべての障害シナリオで補正アクションをテストするのは難しい可能性があります。

LRAとXAの両方のトランザクション・プロトコルで提供される利点を使用するために、XAトランザクションをLRAトランザクション内にネストできます。映画チケットを予約するアプリケーションについて考えてみましょう。席を予約するマイクロサービスは、LRAトランザクション・プロトコルを使用します。予約席の支払いを行うマイクロサービスは、XAトランザクションを使用します。このように、LRAとXAの両方のトランザクション・プロトコルで提供される利点を活用し、パフォーマンスを向上させることができます。

Try-Confirm/Cancel (TCC)トランザクション・プロトコル

このプロトコルは、アプリケーション・ビジネス・モデルが予約をサポートする場合に使用します。たとえば、航空券、レンタカー、ホテルを予約する旅行代理店アプリケーションなどです。

TCCトランザクション・プロトコルは、XAトランザクション・プロトコルによって提供されるのと同じグローバルな一貫性を保証しますが、TCCトランザクションプロトコルを利用できるアプリケーションのタイプに制限があります。TCCは、予約可能なアプリケーション・リソースでのみ機能します。たとえば、航空券やホテルの予約です。予約ごとに、システムが一貫した状態から別の一貫した状態に移行します。シリアライズの制約が課されないため、このプロトコルは完全にスケーラブルです。XAと同様に、開発者はTCCを簡単に利用できます。開発者は、トランザクション境界の位置を決め、トランザクションの結果を判断するだけで済むためです。トランザクション・コーディネータがワークフローを処理して、すべての参加側サービスがトランザクションを確定するか取り消すことを保証します。これにより、アプリケーション・コードの責任がさらに最小化されます。