2PC(Two-Phase Commit, 2단계 커밋)는 분산 시스템에서 여러 데이터베이스나 서비스가 하나의 작업을 동시에 수행할 때 사용하는 트랜잭션 처리 방식이다.
쉽게 말해서 "여러 개의 시스템에서 동시에 작업을 진행할 때, 이 작업이 전체적으로 성공하거나 전체적으로 실패하도록 보장하는 방법"이다.
🛠️ 2PC 동작 원리
2PC는 이름 그대로 2단계로 나누어 작업을 처리한다.
1단계 : Prepare 단계 (준비단계)
이 단계에서는 Coordinator(조정자)가 참여하고 있는 모든 시스템들에게 "이 작업을 할 준비 됐어?" 라고 물어본다. 각 시스템은 자신이 맡은 작업을 실제로 처리하진 않고 그냥 처리할 수 있는 상태인지 체크만 한다. 만약 참여한 모든 시스템들이 "준비 완료!" 라고 응답하면 다음 단계로 넘어간다. 하지만 참여한 시스템 중 하나라도 준비 안 됐다고 하면 전체 작업은 취소된다.
조정자 : 다들 작업 준비됐어?
모든 시스템 : 응 준비됐어! (다음 단계로)
하나라도 준비 안됨 : 미안, 준비 안됐어! (바로 취소)
2단계 : Commit/Rollback 단계 (실행/취소 단계)
1단계에서 모두 준비 완료라고 하면 이제 실제 작업을 진행(Commit)하라고 지시한다.
만약 하나라도 준비 안 된 곳이 있어서 취소가 결정되었다면 모든 시스템들에게 작업을 취소(Rollback) 하라고 지시한다.
조정자 : 이제 진짜 작업해! (Commit!)
또는
조정자 : 작업 취소해! (Rollback!)
❌단점
-
Blocking (블로킹) 문제
Coordinator(조정자)가 "준비됐어?" 라고 물어보고 사라지면 시스템들이 영원히 기다리는 상황 발생할 수 있다. -
성능 저하
모든 시스템이 응답을 다 할 때까지 기다려야 하므로 속도가 느려진다. -
장애 복구 어려움
네트워크 장애나 Coordinator의 다운으로 인해 트랜잭션 처리 상태가 꼬일 수 있다.
이러한 이유로 실제 마이크로서비스 환경에서는 2PC를 잘 사용하지 않는다. 대신 비동기 메시지 기반의 이벤트 처리 방식이나 보상 트랜잭션을 사용하는 패턴이 더 유연하게 활용된다.
📝 배운점
2PC는 분산 시스템에서 데이터 정합성을 강력하게 보장할 수 있는 방식이지만 Coordinator에 의존하기 때문에 장애 발생 시 시스템이 멈추거나 복구가 어려워질 수 있다는 단점이 있다. 마이크로서비스처럼 독립성과 유연성이 중요한 구조에서는 잘 쓰이지 않고 실제로는 Saga 패턴이나 이벤트 기반 처리 방식이 더 선호된다는 점을 알게 되었다. 그래도 2PC는 분산 트랜잭션 개념의 기초이자 전통적인 해결책이기 때문에 구조를 정확히 이해해두는 게 중요하다고 느꼈다.
