[Spring Boot] MSA 분산 트랜잭션 처리 방식 비교

 

 

지난 번 프로젝트에서는 MSA아키텍처에서 인증/인가 ,회원서비스를 진행 하여 분산 트랜잭션 처리하는 것에 대한 것을 깊게 알지 못하였었다. 

그런데 이번 최종 프로젝트에서는 이커머스 도메인에서 주문 파트를 맡게 되어 분산 처리를 어떻게 할까 고민을 많이 해보고, 무엇들이 있는지 찾아보았다. 

상품 주문시 상품의 재고확인, 재고 차감 그리고 결제까지 하나라도 실패할 시 모든 작업 내용들을 롤백 해주어야 한다.

 

모놀리식에서는 하나의 DB로 사용하기에 트랜잭션을 처리하는데 있어서 하나라도 실패하면 DB에 적용되지 않게 하기 위한 과정이 어렵지 않았었다. 

하지만, MSA아키텍처에서는 각각의 독립적인 서비스로 DB또한 하나의 DB가 아니기에 분산 처리를 필수로 해줘야 한다. 

 

 

주문 생성 프로세스 

---

 

재고 차감 -> 할인 쿠폰 검증 -> 결제 승인 -> 주문 생성 프로세스이다. 이 처럼 여러 DB와 서비스가 연쇄적으로 연동되어야 한다. 

 

위에서 말한 것처럼 한 단계라도 실패하면 전체를 되돌려야 하는데, 이를 처리하는 방법이 크게 3가지가 있는 거 같았다. 

 

 

2PC (Two-Phase Commit)

---

 

여러 데이터베이스를 하나의 글로벌 트랜잭션으로 묶어 Commit / Rollback을 동시에 처리하는 방식이다. 

 

이론적으로는 진짜 트랜잭션 처럼 ACID 보장 가능이라고 하지만, MSA방식에서는 거의 사용하지 않는다고 한다. 

 

Coordinator 장애 시 전체 트랜잭션이 중단이 되고, 지연이 증가되어 성능이 저하된다. 

그리고 락이 길게 유지 되어 고트래픽 서비스에 매우 취약하다. 

서비스가 늘어날수록 확장성이 완전 상실되어버린다. 

 

 

동기 호출 기반 보상 로직 직접 구현 

---

 

Feign -> Feign -> Feign 형태로 직접 순서를 만드는 방식이고, 주문 서비스가 다른 서비스들을 차례대로 호출하고 

중간에 실패하면 필요한 보상 작업을 직접 수행하는 방식이다. 

 

단순해 보이고 빠르게 구현 가능해 보이지만, 서비스 간 강한결합이 발생하게 된다.

장애 전파가 연쇄적으로 이어지고, 트래픽 증가 시 전체 서비스가 타임아웃으로 멈출 위험이 생긴다. 

보상 로직을 각 서비스가 관리해야 하므로 유지보수 난이도가 증가한다. 

재시도나 중복 실행 순서 제어 등 비즈니스 규칙 구현이 매우 복잡하여 

구현 난이도가 높고 장애 복구가 취약하여 권장하지 않는다고 한다. 

 

 

Saga Orchestration

---

 

Saga는 크게 두 종류인데, Saga 패턴은 각 서비스가 자신의 로컬 트랜잭션만 수행하고, 실패하면 보상 트랜잭션으로 원상 복구하는 방식이다. 

위 패턴은 두 가지 종류가 있는데 Orchestration과 Choreography 종류가 있고 먼저 오케스트레이션부터 정리하자면, 

 

중앙 지휘자 느낌이다. 중앙 관리식인데, 전체 비즈니스 흐름을 단계별로 지휘하는 Saga 구현 방식이다. 

 

예를 들어서 

1. 주문 생성 요청 -> 오케스트레이터로 전달 

2. 오케스트레이터가 유저 서비스에 검증 이벤트 발행 

3. 성공 시 -> 상품 서비스로 재고 차감 요청 

4. 성공 시 -> 할인 쿠폰 검증 이벤트 발행 

5. 성공 시 -> 결제 서비스로 승인 요청 

6. 마지막 성공 시 -> 주문 서비스로 최종 주문 확정 이벤트 발행 

7. 중간 단계 실패 시 -> 이전 단계들을 역순으로 보상 실행 

오케스트레이터에서 전체 과정을 관리하는 방식이다. 

 

우리 프로젝트에서 내가 직접 구현해볼 방식이다.

 

 

왜 오케스트레이션을 선택했는가?

---

 

우선 오케스트레이션 패턴을 직접 구현해보면 흐름 제어가 명확하다. 

그러니까 서비스 중 하나가 실패하면 오케스트레이터가 전체 흐름을 알고 있으므로 어디까지 성공하거나 실패한 부분을 확인하여 어떤 보상을 해야 하는지 정확히 판단할 수 있다. 

 

서비스간 강한 결합을 낮출 수 있게한다. 

각 서비스들이 서로 직접 호출하지 않고 오케스트레이터만 바라보므로 아키텍처가 느슨하게 유지된다. 

 

각 서비스는 비동기 메시지를 처리하므로 한 서비스가 장애가 전체를 멈추게 하지 않는다. 

즉, 장애가 발생해도 장애 전파가 최소화된다. 

 

그리고 마지막으로 최종 프로젝트에서 요구 사항에 프로메테우스, 그라파나를 사용하여 모니터링 하는 과제가 있는데, 

밑에서 설명할 코레오 그래피에서는 상태 추적이 어렵지만 오케스트레이션 패턴은 상태 추적이 가능하다. 

 

 

Saga Choreography

---

 

위에서 말한 것처럼 완전 다른 방식은 아니다. Saga의 다른 형태이다. 

 

오케스트레이터 없이 서비스들이 Kafka 이벤트로 서로 다음 단계를 트리거하는 방식이다.

 

코레오 그래피는 서비스 간 경로를 복잡해지고, 순서 제어 어렵고 상태 추적이 불가능하다. 

 

하지만 소규모 흐름이면 많이 사용 한다고 하지만, 그러나 주문 처럼 복잡한 흐름에는 부적합하다는 의견들이 많은 거 같다. 

 

 

시퀀스 다이어그램

---