분산 트랜잭션 정합성의 근간: 2-Phase Commit (2PC) 아키텍처 완벽 해부
MSA(마이크로서비스 아키텍처) 및 분산 데이터베이스 환경에서 데이터의 원자성(Atomicity)을 보장하기 위한 절대적인 코어 알고리즘인 2PC의 Prepare-Commit 페이즈 분리 메커니즘과, SPOF 한계를 극복하기 위한 Saga 패턴과의 비교를 심층 분석한다.
가. 분산 시스템 환경에서의 데이터 정합성 위기
단일 RDBMS 환경에서는 로컬 트랜잭션 매니저가 ACID 속성을 보장하지만, 현대의 MSA 환경이나 샤딩(Sharding)된 데이터베이스 환경에서는 하나의 비즈니스 로직(예: 송금)이 여러 대의 독립된 데이터베이스 노드를 넘나들며 실행되는 글로벌 분산 트랜잭션이 발생한다. 만약 DB_A(출금)는 커밋(Commit)되었는데 DB_B(입금)가 다운되어 롤백(Rollback)된다면, 기업의 장부 정합성이 영구적으로 붕괴되는 치명적인 금융 사고가 발생한다.
나. 2-Phase Commit (2PC) 프로토콜의 본질
- 이러한 물리적 분산 환경에서, 마치 하나의 데이터베이스에서 트랜잭션을 처리하는 것처럼 모든 노드가 '함께 커밋되거나', '함께 롤백되도록' 강제하여 원자성(Atomicity)을 100% 달성하는 합의 프로토콜이다.
- 전체 트랜잭션을 조율하는 코디네이터(Coordinator)와 실제 데이터를 가지고 있는 참여자(Participant/Cohort) 노드 간의 엄격한 2단계 통신 과정으로 이루어진다.
가. 코디네이터 주도의 Prepare & Commit 2단계 프로세스
2PC는 한 번에 커밋을 지시하지 않고, 먼저 '준비(Prepare)'가 되었는지 확인한 후 만장일치(All-or-Nothing)일 때만 실제 '커밋(Commit)'을 지시하는 신중한 락(Lock) 기반 프로토콜이다.
나. 페이즈(Phase)별 핵심 동작 원리
| 단계 | 명칭 | 코디네이터(TM)와 참여자(RM) 간의 상태 제어 및 로그 처리 |
|---|---|---|
| Phase 1 | 투표 단계 (Voting / Prepare) |
코디네이터가 모든 DB에게 트랜잭션을 실행할 준비가 되었는지 묻는다(Prepare). 각 DB는 실제 데이터를 변경하기 전, 임시로 데이터를 쓰고 Undo/Redo 로그를 안전하게 디스크에 플러시(Flush)한 뒤, 성공하면 'Vote Commit(Ready)', 실패나 타임아웃이면 'Vote Abort'를 코디네이터에게 회신한다. |
| Phase 2 | 실행 단계 (Completion / Commit) |
코디네이터는 취합된 결과를 확인한다. 단 1건이라도 Abort가 섞여 있다면 모든 DB에게 'Global Rollback'을 전송하여 Undo 로그로 원상복구시킨다. 전원이 Ready를 보냈다면 'Global Commit'을 전송하고, 각 DB는 걸어둔 Lock을 해제하며 결과를 최종 반영하고 완료(Ack) 메시지를 보낸다. |
가. 단일 장애점(SPOF) 리스크와 블로킹(Blocking) 문제
2PC는 강력한 데이터 정합성을 제공하지만, 현대의 분산 처리 환경에서는 성능 및 가용성에 치명적인 문제를 안고 있다.
- 코디네이터 SPOF (단일 장애점): 전체를 지휘하는 코디네이터 노드가 Phase 2 지시를 내리기 직전이나 직후에 다운(Down)되어 버리면, 모든 참여자 DB들은 코디네이터가 살아날 때까지 무한정 대기(Blocking)해야 한다.
- 자원 잠금(Locking) 병목: Phase 1의 Prepare 단계부터 Phase 2의 Commit이 끝날 때까지, 각 DB의 트랜잭션 대상 레코드(Row)들은 배타적 락(Lock)이 걸려 타 트랜잭션이 접근할 수 없다. 이는 시스템 전체의 동시성(Concurrency)과 처리량(Throughput)을 심각하게 저하시킨다.
나. 3PC (3-Phase Commit)의 등장과 한계
2PC의 코디네이터 다운에 따른 영구 블로킹(Blocking) 문제를 해결하기 위해, 중간에 'Pre-Commit(사전 커밋)' 단계를 하나 더 끼워 넣은 3PC(3-Phase Commit)가 등장했습니다. 코디네이터가 죽더라도 참여자들끼리 현재 상태를 상호 공유하여 자체적으로 타임아웃을 걸어 트랜잭션을 진행하거나 취소하는 방식입니다. 하지만 이 역시 네트워크 파티션(단절) 상태에서는 완벽하지 않으며, 메시지 오버헤드가 너무 커서 실무에서는 거의 사용되지 않습니다.
도메인이 잘게 쪼개진 마이크로서비스 아키텍처(MSA)에서는, 서비스마다 이기종 DB(MySQL, MongoDB 등)를 사용하므로 XA 기반의 2PC를 묶는 것이 물리적으로 불가능에 가깝다. 이에 대한 해법으로 이벤트 주도 기반의 결과적 일관성(Eventual Consistency)을 추구하는 Saga 패턴이 대세로 자리 잡았다.
| 비교 관점 | 2-Phase Commit (2PC) | Saga 패턴 (Choreography / Orchestration) |
|---|---|---|
| 정합성 철학 | 강한 일관성 (Strong Consistency) 모든 DB가 동시에 상태가 동기화됨. |
결과적 일관성 (Eventual Consistency) 일시적으로 불일치할 수 있으나, 최종적으로 일치됨. |
| 락(Lock) 소유 방식 | 트랜잭션 시작부터 끝(Phase 2 완료)까지 관련된 모든 자원의 락을 거머쥐고 있는다. | 각 서비스가 자신의 로컬 트랜잭션을 즉시 커밋하고 락을 푼 뒤, 이벤트를 다음 서비스로 전달한다 (비동기 병렬 처리). |
| 에러(Rollback) 처리 | DB 엔진 레벨의 트랜잭션 롤백 명령어 사용 | 비즈니스 레벨에서 원래 작업을 취소하는 역방향 보상 트랜잭션(Compensating Transaction) API를 구현하여 순차적으로 호출함. |
| 적용 환경 | 전통적인 RDBMS 기반의 모놀리식(Monolithic) 분산 환경 (XA 트랜잭션) | Kafka 등 메시지 브로커를 활용하는 최신 클라우드 네이티브 및 마이크로서비스(MSA) 환경 |
'데이터베이스' 카테고리의 다른 글
| DB 설계의 뼈대: 함수적 종속성(FD)의 개념과 완전/부분/이행적 종속 심층 분석 (0) | 2026.05.13 |
|---|---|
| DB 동시성 제어의 절대 규칙: 2PL의 확장/수축 단계와 연쇄 복귀 방지(Strict 2PL) (0) | 2026.04.16 |
| 데이터 파이프라인의 진화: Data Lake에서 Data Mesh, 그리고 카파(Kappa) 아키텍처까지 (0) | 2026.04.09 |
| 쿼리 성능의 비밀: 하드 파싱 vs 소프트 파싱, 그리고 조인(Join) 알고리즘 해부 (0) | 2026.04.06 |
| NoSQL 데이터베이스 종류와 특징 비교 정리 (0) | 2026.03.19 |
