투 페이즈 커밋(Two-Phase Commit, 2PC) 프로토콜 상세 설명
1. 개요
투 페이즈 커밋(2PC)은 분산 환경에서 원자성(Atomicity)을 보장하기 위해 사용되는 분산 트랜잭션 프로토콜입니다. 여러 데이터베이스 노드(또는 자원 관리자)가 하나의 트랜잭션에 참여할 경우, 모든 노드가 정합성 있는 상태로 Commit 혹은 Rollback할 수 있도록 중앙 Coordinator의 조율 하에 2단계에 걸쳐 트랜잭션을 수행합니다.
2. 주요 구성 요소
| 구성 요소 | 설명 |
|---|---|
| Coordinator (조정자) | 전체 트랜잭션을 관리하고 커밋 여부를 결정 |
| Participant (참여자) | 각 분산 노드(DB 등)로 실제 데이터를 저장하는 자원 관리자 |
| Transaction Log | 트랜잭션의 상태(prepare, commit 등)를 저장하여 장애 복구 지원 |
3. 동작 절차
Phase 1: Prepare (Voting Phase)
- Coordinator는 참여자들에게 "트랜잭션 커밋 준비 가능 여부"를 묻는 Prepare 요청을 전송.
- 각 Participant는 해당 트랜잭션이 문제가 없는지 확인 후:
- 트랜잭션을 로컬 로그에 기록 (undo/redo log)
- 문제가 없으면 YES(Prepared) 응답
- 실패하거나 제약 조건 위반 시 NO(Abort) 응답
Phase 2: Commit / Abort (Decision Phase)
- Coordinator는 모든 Participant로부터 YES를 받았을 경우:
- Commit 명령 전송 → 각 참여자는 실제 커밋 수행 후 완료 메시지 전달
- 한 명이라도 NO를 응답한 경우:
- Abort 명령 전송 → 각 참여자는 트랜잭션 롤백 수행
핵심 원칙: All or Nothing
4. 특징
| 항목 | 설명 |
|---|---|
| Atomicity 보장 | 모든 참여자에게 동일한 결과 보장 (Commit or Abort) |
| 일관성 유지 | 분산 DB 간 정합성 보장 |
| Blocking Protocol | Coordinator 장애 시 Participant가 응답 대기 상태로 남을 수 있음 |
| 로그 기반 복구 | 장애 시 트랜잭션 로그 기반으로 상태 복구 가능 |
5. 문제점 및 한계
-
Coordinator 장애 시 블로킹 발생
- Prepare 후 Coordinator가 장애 나면, 참여자는 커밋/중단 결정을 못 하고 자원 락이 유지됨
-
참여자 장애 시 불확정 상태
- 일부 참여자는 Commit, 일부는 Abort일 수 있는 불일치 위험 존재
-
성능 저하
- 트랜잭션 커밋이 느리고, 디스크 로그 기록으로 인한 오버헤드 존재
6. 보완 기법
| 보완 기법 | 설명 |
|---|---|
| Three-Phase Commit (3PC) | 중간 상태(Pre-Commit)를 추가하여 블로킹 문제를 완화 |
| Paxos Commit | Consensus 알고리즘 적용하여 Coordinator 장애 대응 |
| XA 프로토콜 | 분산 트랜잭션을 표준화한 API (JTA, JDBC 등에서 사용) |
| SAGA 패턴 | 롱런 트랜잭션 분해 및 보상 트랜잭션으로 비동기 처리 (마이크로서비스 기반에서 주로 사용) |
7. 실제 적용 예시
- 은행 간 송금 시스템
- 출금 DB와 입금 DB가 서로 다른 노드에 존재할 경우, 2PC를 사용해 출금과 입금이 모두 성공해야 커밋
- B2B 주문 시스템
- 주문 시스템과 재고 시스템이 분산되어 있을 경우, 주문 생성과 재고 차감의 원자성 보장
8. 결론
Two-Phase Commit은 분산 트랜잭션의 원자성과 정합성을 보장하는 핵심 프로토콜이지만, Coordinator 장애 시의 블로킹 문제, 지연 발생, 성능 저하 등의 한계도 존재합니다. 이러한 단점을 극복하기 위해 3PC, SAGA, Paxos Commit 등의 기술이 도입되고 있으며, 최근에는 마이크로서비스 기반 환경에서 비동기 보상 트랜잭션 패턴이 더 자주 활용되고 있습니다.
