분산 트랜잭션 일관성을 지키는 Two Phase Commit

여러 시스템의 변경을 하나의 결과로 묶는 방식

분산 환경에서는 하나의 업무가 여러 데이터베이스와 시스템의 변경을 함께 요구한다. 이때 일부 작업만 성공하면 데이터 불일치가 생길 수 있다. Two Phase Commit(2PC)은 모든 참여 노드가 커밋하거나 모두 롤백하도록 조정해, 분산 트랜잭션의 ACID 속성과 데이터 무결성을 지키는 프로토콜이다.

1970년대 후반 분산 데이터베이스 시스템이 발전하면서 개발됐으며, 코디네이터와 참여자가 하나의 최종 결정을 공유하는 구조를 갖는다.

준비 응답을 수집한 뒤 최종 결정을 전파한다

2PC는 준비 단계와 커밋 단계로 나뉜다. 먼저 코디네이터가 참여자에게 커밋 준비를 요청하고, 참여자는 트랜잭션을 수행한 뒤 로그를 남긴다. 각 참여자는 커밋 가능 여부에 따라 준비됨(Ready) 또는 중단(Abort)을 응답한다.

⤢✕

모든 참여자가 준비됨을 보냈다면 코디네이터는 커밋 명령을 전송한다. 참여자 중 하나라도 중단을 응답하거나 타임아웃이 발생하면, 코디네이터는 전체 참여자에게 롤백을 지시한다. 참여자는 명령에 따라 결과를 처리하고 완료 사실을 보고하며, 코디네이터는 모든 응답을 받은 뒤 트랜잭션을 종료한다.

⤢✕

참여자는 초기 상태에서 준비 요청을 받고 작업 가능 여부에 따라 준비 또는 중단 상태로 이동한다. 준비 상태에서는 코디네이터의 커밋 또는 롤백 명령을 기다린다.

⤢✕

원자성은 얻지만 대기와 장애 전파를 감수한다

2PC의 강점은 모든 참여자가 커밋 또는 롤백이라는 동일한 결정을 수행한다는 데 있다. 분산 시스템 전체의 데이터 일관성을 유지할 수 있고, 알고리즘의 구조가 비교적 이해하기 쉬우며 대부분의 상용 DBMS와 미들웨어에서 지원한다.

반면 준비 단계와 커밋 단계 모두 네트워크 통신을 필요로 한다. 참여자가 늘면 응답을 기다리는 시간도 길어지고, 동기식 블로킹 프로토콜이라는 특성은 성능 저하로 이어진다.

코디네이터는 단일 장애점이 될 수 있다. 모든 참여자가 준비됨을 보낸 뒤 코디네이터가 장애를 일으키면, 참여자는 커밋과 롤백 중 어느 결정도 받지 못한 채 대기 상태에 들어갈 수 있다.

⤢✕

커밋 메시지가 일부 참여자에게만 도달한 시점에 코디네이터가 장애를 일으키는 경우도 문제가 된다. 일부는 커밋을 마쳤지만 다른 참여자는 준비 상태에 남아 불확실한 상태가 발생할 수 있다.

금융·주문·다중 지역 동기화에 요구되는 일관성

은행 간 자금 이체에서는 출금 계좌와 입금 계좌가 서로 다른 데이터베이스에 있을 수 있다. A은행에서 B은행으로 송금할 때 A은행 출금과 B은행 입금은 함께 성공하거나 함께 실패해야 한다.

전자상거래 주문도 같은 성격을 가진다. 재고 관리 DB의 재고 차감, 주문 DB의 주문 생성, 결제 시스템의 결제 처리가 모두 성공하거나 모두 실패해야 한다.

클라우드 서비스에서는 여러 리전에 걸친 데이터 일관성 유지가 필요한 다중 지역 데이터 동기화에 적용할 수 있다.

블로킹 문제를 다루는 프로토콜과 패턴

3PC는 2PC의 블로킹 문제를 줄이기 위해 사전 커밋 단계를 추가한다. 참여자가 타임아웃 상황에서 결정을 내릴 수 있지만, 메시지 교환이 늘어나 성능 오버헤드도 커진다.

Paxos는 비동기 환경에서 분산 합의를 위한 알고리즘이다. 과반수 합의 방식을 사용하므로 일부 노드 장애에도 진행할 수 있으며, Google의 Chubby와 Apache ZooKeeper 등에서 활용된다.

Raft는 Paxos의 복잡성을 해결하기 위해 개발됐고, 리더 선출·로그 복제·안전성 메커니즘으로 구성된다. etcd와 Consul 등에서 사용된다.

마이크로서비스 아키텍처에서는 보상 트랜잭션도 활용된다. Saga 패턴은 각 로컬 트랜잭션과 보상 트랜잭션 쌍으로 구성하며, 장애가 발생하면 이전 단계까지 수행된 작업에 대해 보상 트랜잭션을 실행한다.

운영 시에는 타임아웃과 복구 로그를 함께 설계한다

무한 대기를 줄이려면 네트워크 지연과 시스템 부하를 고려해 적절한 타임아웃 값을 설정해야 한다. 장애 복구에서는 코디네이터의 로그 기반 복구 전략과, 불확실한 상태에 놓인 참여자가 코디네이터에 상태를 확인하는 전략이 필요하다.

로그는 준비 단계의 Prepare Log, 최종 결정을 남기는 Commit Log, 완료된 트랜잭션을 정리하는 Checkpoint로 구분해 관리할 수 있다.

마이크로서비스에서는 적용 범위를 제한할 수 있다

마이크로서비스 아키텍처에서는 2PC의 강한 결합성 때문에 직접 적용하기 어렵다. 중요 트랜잭션에만 2PC를 적용하고, 덜 중요한 일관성에는 최종 일관성(Eventual Consistency) 모델을 적용하는 하이브리드 방식이 가능하다.

CQRS로 명령과 조회 책임을 분리하고 이벤트 스트림에 상태 변경을 기록하면, 실패 시 재처리 메커니즘을 활용할 수 있다. Atomikos, Narayana 같은 분산 트랜잭션 매니저를 사용해 XA 표준 기반으로 트랜잭션을 조정하는 방법도 있다.

2PC는 분산 환경의 원자성과 일관성을 이해하는 출발점이다. 실제 설계에서는 일관성 요구사항, 성능 목표, 장애 허용성을 함께 검토해 2PC와 대안 프로토콜, 하이브리드 접근법 중 적합한 전략을 선택해야 한다.