XA Datasource와 2 Phase Commit(2PC) 에 대해서

최근 프로젝트에서 분리되어 있는 여러 DB에 대해 2 Phase Commit을 적용해야 하는 일이 생겨 정리하게 되었다.

설명을 시작하기에 앞서, 간단하게 분산 트랜잭션에 대해 얘기하고 넘어가겠다.
분산 트랜잭션은 글로벌 트랜잭션이라고도 하며, 통합되어 관리되는 여러 개의 트랜잭션 묶음을 의미한다.
이때, 1️⃣ 분산 트랜잭션에 포함되는 트랜잭션은 서로 동일한 DB에 존재할 수도 있고, 2️⃣ 서로 다른 DB에 존재할 수도 있다.

XA Datasource와 2 Phase Commit 이란?

XA는 2 Phase Commit을 통한 분산 트랜잭션 처리를 위해 X/Open에서 정의한 표준이다.

분산 트랜잭션에서 사용되는 각각의 DB에는 하나의 XA Datasource가 존재하고, 이 XA Datasource가 XA Connection을 생성한다.

또한, 분산 트랜잭션은 개별 트랜잭션을 관리하기 위해 외부의 Transaction Manager가 필요하다. Java 진영에서는 여러 벤더사에서 Java Transaction API 표준을 구현한 Object를  XA 호환 JTA 모듈로 제공한다.

나의 경우에는 백오피스 서비스에서 분산된 여러 Oracle DB 환경에 2 Phase Commit을 진행해야 하는 경우이기에 XA Datasource를 사용하게 되었다.

 

 

다음으로, 2 Phase Commit이란 무엇일까? 말 그대로 2 단계에 걸친 커밋이라는 의미이다.

https://ebrary.net/64872/computer_science/introduction_phase_commit

2PC는 싱글 노드인 경우에는 사용하지 않는, Coordinator(트랜잭션 매니저)를 사용하여 분산된 여러 개의 트랜잭션을 관리한다.

 

먼저, 그림을 통해 간단하게 2PC 순서를 설명하겠다.

1. 각 트랜잭션은 DB 노드에 데이터를 Write 하고 성공 결과를 응답받는다.
2. (Phase1) 1번 과정에서 모든 트랜잭션이 OK 응답을 받게 되면, 각 트랜잭션은  DB 노드에 Prepare 요청을 보내어 Commit이 가능한지 확인한다. 만약 NO 응답을 받게 되면, 모두 롤백 처리하게 된다.
3. (Phase2) 2번 과정에서 모든 트랜잭션이 Commit이 가능하다는 YES 응답을 받게 되면, 트랜잭션 매니저는 각 DB 노드에 Commit 요청을 보내고 수행된다.

이를 가능하게 하는 기술중 하나는 글로벌하게 Unique한 트랜잭션 ID이다.
Coordinator가 Prepare 요청 단계에서 모든 트랜잭션 참여자에게 글로벌 트랜잭션 ID를 함께 보내고, 이러한 요청 중 하나라도 실패하게 되면 Coordinator는 모든 트랜잭션 참여자들에게 해당 트랜잭션 ID의 트랜잭션에 대해 Abort 요청을 보내게 된다. 

이러한 기술이 자세하게는 적용되고 있다는 점을 언급하고 싶었다. 

 

중요 부분을 정리하자면, 싱글 노드인 경우에는 DB가 Atomicity 한 트랜잭션을 통해 작업의 성공과 실패를 보장할 수 있다. 하지만, 분산된 멀티 노드인 경우는 다르다. 

멀티노드일 때, 2PC에서 중요한 개념은 "모든 트랜잭션 작업이 성공했을 때 전체 TR이 Commit되어야 하며, 하나라도 Rollback이 된다면 모든 TR이 함께 Rollback 되어야 한다"는 것이다.

 

2PC의 취약점

위에서 설명한 Coordinator 즉, 트랜잭션 매니저가 다운되는 경우 2PC의 취약점이 드러나게 된다.

만약, Prepare 요청을 보내기 전이라면 트랜잭션 참여자들은 안전하게 Abort가 가능하다.

하지만, Prepare 요청을 보내고 YES를 받고난 후라면 상황이 다르다. 이 경우에는 트랜잭션 참여자가 트랜잭션 매니저의 도움 없이 스스로 커밋되었는지 Abort 되었는지 알 수가 없다. 

 

결국에는, Coordinator가 Recovery되기를 기다려야 하고, Coordinator가 회복될 때 Coordinator가 기록해둔 트랜잭션 로그를  읽어서 상태를 회복하게 된다.