[TIL] MSA 환경의 분산 트랜잭션 처리 패턴 - 2PC, SAGA

 

MSA(Microservice Architecture), 마이크로서비스 아키텍처란 하나의 서비스가 아닌 작고 독립적인 여러 개의 서비스로 나누어 개발하는 구조이며, 각 서비스는 독립된 데이터베이스를 가진다. 

 

이와 반대되는 전통적인 개발 방식은 Monolithic Architecture로, 하나의 프로젝트에 모든 기능을 포함시킨 구조이다. 

개발 초기에는 이 방식이 더 간단하고 빠르게 개발할 수 있지만, 코드가 길어지고 구조가 복잡해질수록 수정이나 확장이 어렵다는 단점이 있다. 그리고 수정할 때마다 전체 부분을 다시 배포해야 한다는 단점도 있다. 

반면 MSA는 독립성을 보장하기에 유지보수와 관리에 용이하여 훨씬 많이 사용되고 있다. 

 

그런데 이렇게 여러 개의 서비스로 나눠서 관리하면 데이터 일관성의 문제를 마주하게 된다. 

여러 개의 서비스를 거친 후에도 데이터 값은 항상 동일해야 하기 때문이다. 

이렇게 분산된 환경에서 트랜잭션을 어떻게 처리하느냐? 에 대해서 공부해봤다. 

 

 

1. 2PC(2-Phase-Commit) 패턴

문자 그대로 2개의 페이즈로 걸쳐 DB의 변경을 확정한다. 

이 패턴에서는 트랜잭션을 관리하는 코디네이터(Coordinator)가 존재하며

Prepare, Commit 이렇게 두 단계로 진행된다. 

 

 

Prepare 

• Prepare, 즉 준비 단계에서는 각 서비스가 준비되었는지 확인한다. 
• 코디네이터가 트랜잭션의 참여자에게 준비되었니? 여부를 물으며, 전부 준비됨을 확인한 경우 커밋 단계로 넘어간다. 

 

만약 내가 쇼핑몰에서 옷을 구매하고 싶고, 

재고 서비스, 결제 서비스, 주문 서비스(대충)가 있다고 했을 때 

모든 서비스에서 준비됐다!라고 응답을 날려야 된다는 것이고, 이 준비 상태에서는 DB에 lock을 걸고 대기한다. 안 되는 게 하나라도 있을 경우 전부 롤백된다. 

전부 괜찮으면 Commit 단계로 넘어오게 되고 코디네이터의 명령에 따라 트랜잭션을 수행하게 된다. 

 

 

 

이 패턴에는 치명적인 단점이 있다. 

• 해당 요청을 수행하기까지 DB는 전부 lock을 걸고 대기하기 때문에, 그동안 DB에 접근할 수 없으며 시간이 많이 지연될 수 있다. 거쳐야 할 노드의 수가 많을수록 지연되기 쉽다. 
• 이는 마이크로서비스가 가진 의미와 정반대로 동작하는 것이다. 하나가 멈추면 전체가 멈춰버린다는 것은... 독립성을 낮추고 결합도를 높이는 것이다. 
• 또한 모든 DB가 분산 트랜잭션을 지원해야 하므로 NoSQL같은 DB는 사용하지 못한다. 

 

 

그래서 요즘은 이 패턴을 사용하지 않으며 대신 SAGA 패턴을 사용한다. 

 

 

2. SAGA 패턴

분산된 환경에서 데이터의 일관성을 유지하기 위해 전체 트랜잭션을 작은 트랜잭션 여러 개로 쪼개어서 순차적으로 진행하고, 트랜잭션이 실패할 경우 보상 트랜잭션을 통해 이전 작업들을 취소하는 패턴

(개인적으로 saga라는 게 무슨 뜻일까 궁금해서 찾아보니 전설, 서사시를 뜻하는 말이라는데 여러 개의 장으로 나뉘어서 긴 이야기를 설명하는... 그런 뜻을 담았다고 함 캔디크러쉬사가의 사가랑 똑같음) 

 

예를 들어 내가 항공권 + 호텔 + 차 여행 패키지 상품을 구매한다고 생각했을 때, 

각각의 서비스에서 순차적으로 구매(항공권 -> 호텔 -> 차)하고 만약 셋 중 하나가 실패할 시 이전 작업들을 취소하는 것이다 (보상 트랜잭션)

2pc는 준비됨 상태에서 db에 lock을 걸고 대기하다 하나라도 오류가 생기면 다른 db까지 접속을 할 수 없게 되지만, (장애 전파성)

사가 패턴에서는 장애가 전파되지 않는다. 

 

 

 

또한 이 사가패턴은 '최종적 일관성(Eventual Consistency)'를 보장한다. 

 

최종적 일관성(Eventual Consistency)

트랜잭션으로 인해 데이터가 변경되면서 당장은 DB간 데이터가 불일치하더라도,

결국은 일관성이 유지되는 특성이다. 

 

예를 들어 내가 친구에게 만 원을 송금할 때, 

만 원 송금 버튼 -> 내 통장에서 만 원 차감 -> 친구 통장 만 원 증가

라는 과정을 거칠 텐데 

내 통장에서 만 원이 빠져나간 그 즉시 친구 통장에 만 원이 추가되진 않는다.

진짜 영점몇몇몇...초 그 사이에는 내 통장에서 돈이 나갔지만 친구 통장은 그대로인 데이터 불일치가 발생한다는 것이다. 

그러나 결국에는 이체가 완료되면서 데이터가 최종적으로 일치하게 된다. 

 

마찬가지로 사가 패턴을 이용할 때에도 그 잠깐의 시간에 데이터 불일치가 존재하지만, 

실패한다면 보상 트랜잭션으로 취소가 될 것이고 성공한다면 데이터 간 일관성은 유지될 것이다. 

결국 성공하든 실패(보상)하든, '약간의 시간차'를 두고 최종적으로는 데이터의 격차가 사라지고 일치하게 되므로 이를 최종 일관성이라고 부르는 것이다.

 

 

생각해보니 실생활에서도 이 최종적 일관성을 많이 마주해왔던 것 같다. 

인터넷으로 쇼핑을 하고, 결제 방법을 무통장 입금으로 결정했을 때

입금을 했지만 주문 완료 처리가 바로 되지 않았던 적이 있다. 그래도 결국에는 입금 처리가 될 걸 알고 다. 

또한 좋아하는 상품에 찜(하트)을 눌렀을 때도, 순간 데이터가 안 터지거나 연결 오류가 생기면 하트가 잠깐 반영되었다가 바로 사라지게 된다. 우선 사용자의 요청을 처리하고, 이게 최종적으로 완료되지 않으면 다시 롤백.. 하는 거랑 비슷한 것 같기두

 

 

 그리고 사가 패턴에는 두 가지 방식이 존재하는데... 

 

1. 코레오그래피 사가 (Choreography Saga) - 이벤트 기반

Central Controller 없이, 서비스들끼리 이벤트를 주고받으며 자율적으로 동작한다. 

• [주문 서비스]가 주문 생성 이벤트 발행 ➔ [결제 서비스]가 이를 듣고 결제 후 결제 완료 이벤트 발행 ➔ [재고 서비스]가 이를 듣고 재고 차감
• 장점: 서비스 간 결합도가 낮고 구조가 간단하다. 
• 단점: 프로세스가 더 길어지면 흐름 추적이 어려울 수 있고, 서로 의존하게 될 가능성이 있다. 

 

2. 오케스트레이션 사가 (Orchestration Saga) - 중앙 제어 기반

• 중앙 관리자(Orchestrator)가 각 서비스에게 지시하고 성공/실패 여부를 총괄하여 진행한다.
• 장점: 전체 비즈니스 로직과 흐름 파악이 더 명확하다.
• 단점: 오케스트레이터 서비스 자체가 복잡하며, 오케스트레이터에 문제가 생길 경우 영향을 받는 환경 전체에 장애가 발생할 수 있다. 

 

 

MSA라는 용어 자체를 알아보려다가 분산 트랜잭션 처리 패턴까지 알아봤는데... 이걸 실제로 써볼 기회가 있으면 좋겠다. . . 적용할 부분을 찾아봐야겠다 

 

 

---

참고했습니다 :>

마이크로서비스 - 분산 트랜잭션 처리 패턴

 

MSA 환경에서의 분산 트랜잭션 관리: 2PC & SAGA 패턴

 

Saga Pattern(사가 패턴)