トランザクション処理と分散コンピューティングにおいて、補償トランザクションとは、以前にコミットされたトランザクションの効果を元に戻すトランザクションです。これはSaga設計パターンの中核概念であり、従来のACIDトランザクションが実現不可能または実用的ではないシナリオにおいて、複数のサービスまたはデータベース間でデータの一貫性を維持するために使用されます。
補正トランザクションは、複数の個別のトランザクションで構成されるビジネスプロセスにおいて、1つ以上のステップが既に正常に完了(コミット)した後に失敗した場合に必要となります。コミットされていない変更を破棄するデータベースのロールバックとは異なり、補正トランザクションは、完了したトランザクションの作業をビジネスロジックに基づいてセマンティックに元に戻す新しいトランザクションであり、システムを整合性のある状態に復元します。
メカニズムと原理
ビジネスプロセスの実行には、多くの場合、単一のアトミック単位として扱う必要がある一連の操作が含まれます。従来のデータベーストランザクションは、コミットとロールバックのメカニズムによってこのアトミック性を実現していますが、複雑で長時間実行されるプロセスにはこのアプローチでは不十分な場合が多くあります。[ 1 ]
補正トランザクションは、元の操作の論理的に逆の操作を実行することで機能します。例えば、元のトランザクションが「口座から100ドル引き落とす」だった場合、補正トランザクションは「口座から100ドル貸し出す」となります。長時間実行されるプロセスの各ステップには、対応する補正トランザクションが設計されている必要があります。プロセスがいずれかの時点で失敗した場合、システムはそれ以前に完了したすべてのステップの補正トランザクションを逆順に実行し、プロセスを元に戻します。
アプリケーション
補償トランザクションは、分散型および複雑なシステムで一貫性を維持するための重要なパターンです。
長時間実行されるトランザクション(Sagas)
補正トランザクションは、サガパターンの基本です。サガとは、各トランザクションが単一のサービス内のデータを更新し、イベントを発行する一連のローカルトランザクションです。ローカルトランザクションが何らかの理由で失敗した場合、サガは一連の補正トランザクションを実行し、先行するローカルトランザクションによって行われた変更を元に戻します。
このパターンは、フライト、ホテル、レンタカーの調整を伴う旅行予約プロセスなど、長期間実行されるプロセスに不可欠です。これらの操作は長期間に及ぶ可能性があり、複数の独立したWebサービスが関与するため、データベースロックを保持することは現実的ではありません。代わりに、各サービスはトランザクションをコミットし、後続のステップが失敗した場合に備えて補償トランザクションを用意します。これは、2フェーズコミットプロトコルを使用した分散トランザクションとは異なり、リソースの長時間ロックを回避します。[ 2 ]
ネイティブのロールバックメカニズムを持たないシステム
グローバルなコミット/ロールバック機構が利用できないシステム(レガシーシステム、サードパーティAPI、非トランザクションデータストアを統合するシステムなど)では、失敗した操作は手動で元に戻す必要があります。補正トランザクションは、この「元に戻す」ロジックのための正式な構造を提供します。この文脈において、このロジックはシステムアーキテクトによって明示的に設計・実装される回避策であり、システムアーキテクトは補正トランザクション自体が失敗する可能性も考慮する必要があります。[ 3 ]
サービス指向アーキテクチャ(SOA)
補正トランザクションは、サービス指向アーキテクチャ(SOA)の一部としてビジネスプロセスに参加するWebサービスに設計されることがよくあります。ビジネスプロセス実行言語(BPEL)などの標準には、ビジネスプロセス定義内に補正ロジックを定義するための規定が含まれており、複雑なマルチサービス相互作用における障害の自動処理を可能にします。
制限と課題
補償パターンは強力ですが、制限もあります。
- 真の分離が実現されていない:元のトランザクションの結果は、補正される前に他のプロセスから参照可能です。別のプロセスがこのデータを読み取った場合、その情報に基づいて処理が行われますが、その処理は遡及的に元に戻されるため、データの不整合が発生する可能性があります。これは「ダーティリード」と呼ばれます。
- 複雑さ:堅牢な補正ロジックの設計と実装は複雑です。開発者は、補正トランザクションが完了まで実行され、データのあらゆる状態に対応できることを保証する必要があります。
- 補償の失敗:補償トランザクション自体が失敗する可能性があります。これは重大な問題であり、補償の再試行、管理者による手動介入、または障害のエスカレーションなど、堅牢なエラー処理戦略が必要となります。
- 不完全な取り消し:操作を完全に取り消すことが必ずしも可能であるとは限りません。例えば、トランザクションによってメールが送信された場合、そのメールを「送信取り消し」することはできません。補償トランザクションは、フォローアップの謝罪メールの送信などのアクションしか実行できません。
これらの課題のため、補償トランザクションは正確な元の状態への復帰を保証するものではなく、ビジネスの観点から意味的に一貫した状態への復帰を保証するものである。[ 4 ]
参照
- 酸
- ビジネスプロセス実行言語(BPEL)
- 2相コミットプロトコル
参考文献
- ^グレイ、ジム(1981年6月)「トランザクションの概念:長所と限界」Very Large Database Conference Proceedings。
- ^ソフトウェアアーキテクチャの基礎:エンジニアリングアプローチ. O'Reilly Media. 2020. p. 363. ISBN 978-1492043454。
- ^ソフトウェアアーキテクチャの基礎:エンジニアリングアプローチ. O'Reilly Media. 2020. p. 364. ISBN 978-1492043454。
- ^ソフトウェアアーキテクチャの基礎:エンジニアリングアプローチ. O'Reilly Media. 2020. p. 364. ISBN 978-1492043454。