分散トランザクション処理(ブンサン トランザクション ショリ)とは | 意味や読み方など丁寧でわかりやすい用語解説

分散トランザクション処理とは、複数のデータベースやサービス、あるいはその他の独立したシステムコンポーネントにまたがる一連の操作を、全体として一つの不可分な論理単位（トランザクション）として扱うための技術である。これは、あたかも単一のシステム内で処理が行われるかのように、すべての操作が成功するか、あるいはすべての操作が失敗して元の状態に戻るかのどちらか一方になることを保証する。この「すべて成功するかすべて失敗するか」という特性は、トランザクションの原子性（Atomicity）と呼ばれ、データの整合性を維持するために極めて重要となる。

現代のITシステムは、スケーラビリティの向上や高可用性の実現、さらにはマイクロサービスアーキテクチャの採用などにより、複数の独立したコンポーネントが連携して動作する分散環境で構築されることが一般的である。例えば、ECサイトでの商品購入処理を考えると、在庫管理、決済処理、配送手配といった複数の異なるサービスが関与することがある。これら全ての処理が首尾一貫して行われる必要があり、もし途中でいずれかの処理が失敗した場合、関連する全ての処理が取り消され、システムの状態が矛盾しないように元の状態に戻されなければならない。分散トランザクション処理は、このような複雑な分散環境において、データの整合性を厳密に保証するための基盤技術となる。

分散トランザクション処理を実現するための最も一般的なプロトコルの一つに、2相コミット（Two-Phase Commit, 2PC）がある。このプロトコルは、トランザクションの進行を調整する「コーディネーター（調整者）」と、トランザクションに参加する個々のシステム（データベースやサービスなど）を管理する「リソースマネージャー（参加者）」によって動作する。

2相コミットは、その名の通り、2つの主要なフェーズで構成される。

第一フェーズは「準備フェーズ（または投票フェーズ）」である。 まず、コーディネーターが、トランザクションに参加する全てのリソースマネージャーに対し、「コミットの準備はできているか？」という問い合わせ（準備完了要求）を送信する。 これを受け取った各リソースマネージャーは、自身が担当する部分のトランザクションを実際に実行し、その結果を永続的なログに一時的に記録する。この時点ではまだ最終的な変更は確定しない。 その後、各リソースマネージャーは、自身の処理が成功し、コミット可能であると判断すれば「はい（投票承諾）」という応答をコーディネーターに返す。もし何らかの理由で処理が不可能であったり、エラーが発生したりした場合は「いいえ（投票拒否）」を返す。この間、リソースマネージャーは自身が管理するリソース（例えばデータベースの特定のデータ行）をロックし続け、他のトランザクションからのアクセスを制限する。

第二フェーズは「コミットフェーズ（または決定フェーズ）」である。 コーディネーターは、第一フェーズで受け取った全てのリソースマネージャーからの応答を待つ。 もし全てのリソースマネージャーから「はい」という応答が届いた場合、コーディネーターは全体としてトランザクションをコミットできると判断し、全てのリソースマネージャーに対し、「コミットせよ」という指示を送信する。これを受け取った各リソースマネージャーは、第一フェーズで一時的に記録した変更を永続化し、リソースのロックを解除する。 一方、もし一人でもリソースマネージャーから「いいえ」という応答があった場合、あるいは何らかの理由で応答がタイムアウトした場合、コーディネーターはトランザクション全体を中止する必要があると判断する。この場合、コーディネーターは全てのリソースマネージャーに対し、「ロールバックせよ（元に戻せ）」という指示を送信する。これを受け取った各リソースマネージャーは、第一フェーズで一時的に記録した変更を破棄し、元の状態に戻し、リソースのロックを解除する。 このようにして、すべての参加者がコミットするか、全員がロールバックするかのいずれかの状態となり、分散環境におけるトランザクションの原子性が保証される。

しかし、2相コミットプロトコルにも課題は存在する。一つは「単一障害点」の問題である。コーディネーターが故障した場合、リソースマネージャーは最終的な決定指示を受け取ることができず、自身のリソースをロックしたまま待機状態に陥る可能性がある。これを「ブロッキング問題」と呼ぶ。この状態が長く続くと、関連するリソースが利用できなくなり、システム全体の可用性が低下する恐れがある。また、複数のシステム間のネットワーク通信を伴うため、単一システム内のトランザクション処理に比べて性能オーバーヘッドが大きく、レイテンシ（遅延）が増加しやすいという側面もある。

これらの課題を解決するため、より複雑な3相コミット（3PC）プロトコルや、障害耐性を高めるPaxos、Raftといった合意プロトコル、あるいは厳密なACID特性の一部を緩め、最終的な整合性を目指すSagaパターンなどの代替的なアプローチも研究・実用化されている。Sagaパターンは、トランザクションを複数のローカルトランザクションに分割し、各ローカルトランザクションが成功したことを前提に次の処理を進めるが、途中で失敗した場合は、それまでに実行されたローカルトランザクションを補償する別のトランザクションを実行して状態を元に戻す方式である。

分散トランザクション処理は、銀行システムにおける口座間送金（送金元口座の残高減と送金先口座の残高増が同時に行われなければならない）や、マイクロサービスアーキテクチャを採用した大規模なエンタープライズシステムなど、データの整合性を厳密に保つことが不可欠な場面で利用される。しかし、その複雑さから設計や実装は難しく、また性能面でのトレードオフも大きいため、システムの要件に応じて、厳密な分散トランザクションが必要なのか、あるいは最終的な整合性で十分なのかを慎重に検討し、適切な技術を選択することが重要となる。