[MSA] 2페이즈 커밋(2PC) 쓰지 말자

이 글은 '샘 뉴먼 - 마이크로소프트 아키텍처 구축' 내용을 기반으로 합니다.

 

2페이즈 커밋은 여러 시스템에 걸쳐 있는 작업을 원자적으로 처리하려는 분산 트랜잭션을 관리하기 위한 알고리즘 중 하나이다.

 

• 작동 방식:
  1. 투표 단계(Voting Phase): 트랜잭션 관리자(=중앙 코디네이터)가 모든 참여자(Cohort)에게 로컬 트랜잭션을 커밋할 준비가 되었는지 묻는다.
  2. 커밋 단계(Commit Phase): 모든 참여자가 '예'라고 답하면, 관리자는 모든 참여자에게 커밋하라고 지시한다. 만약 한 명이라도 '아니오'라고 한다면, 관리자는 모든 참여자에게 롤백을 지시한다.
• 문제점: 이 방식은 모든 참여자가 중앙 코디네이터의 지시를 기다려야 하므로 시스템을 취약하게 만든다. 코디네이터나 참여자 중 하나라도 응답하지 않으면 전체 시스템이 멈출 수 있다. 또한, 투표 후 커밋 단계에서 실패할 가능성도 완벽히 배제할 수 없다. 참여자들은 리소스에 대한 잠금(Lock)을 유지해야 하므로 경합이 발생하여 시스템 확장을 어렵게 만든다.
• 대안: 2페이즈 커밋은 분산 트랜잭션의 복잡성과 확장성 문제를 증대시키고, 이는 MSA의 장기적인 유지보수와 개발에 문제를 일으킨다. 그러므로 가능하다면 최종 일관성(Eventual Consistency) 모델을 사용하거나, 사가 패턴을 사용하는 것이 낫다.

 

2페이즈 커밋의 가장 큰 문제 중 하나는 블로킹 프로토콜이라는 점이다. 투표 단계에서 관리자는 모든 참여자의 응답을 기다려야 하고, 커밋/롤백 단계에서도 모든 참여자가 지시를 받을 때까지 대기할 수 있다. 만약 관리자나 특정 참여자가 응답하지 않거나 실패하면, 다른 참여자들은 해당 트랜잭션에 대한 결정을 내리지 못하고 무한정 기다리며 리소스를 점유하게 될 수 있다. 이는 시스템 전체의 응답성을 저하시키고 가용성을 떨어뜨린다.

 

트랜잭션의 일관성을 유지하기 위해 2페이즈 커밋은 참여자들이 트랜잭션 처리 중 관련 데이터에 락을 설정하도록 요구하는 경우가 많다. 여러 시스템에 걸쳐 잠금을 유지하고 관리하는 것은 그 자체로 복잡하며, 잠금 시간이 길어질수록 다른 트랜잭션들이 해당 데이터에 접근하지 못해 경합이 발생한다. 이는 시스템 전체의 처리량을 감소시키고 확장성을 크게 저해하는 주요 원인이 된다. 즉, 마이크로서비스 아키텍처의 장점 중 하나인 개별 서비스의 독립적인 확장성을 저해하는 것이다.