분산 트랜잭션 설계하기 (초급)

분산 트랜잭션 관리는 MSA 운영의 핵심 중 하나로 설계도 어렵지만 제반되는 기술도 러닝 커브가 상당히 높습니다.

이와 관련되어 실무에서 경험해본 내용과 F-Lab의 twitch-clone 프로젝트를 진행하면서 고민해본 기록을 남겨봅니다.

 

2PC 패턴과 (2 Phase Commit) SAGA 패턴에 대한 배경 지식이 있다면 글을 이해하는데 더 좋습니다.

마이크로서비스 분산 트랜잭션 관리 (2Phase Commit)

마이크로서비스 분산 트랜잭션 관리 (Saga Pattern)

 

1. 초기 설계와 최종 모델

twitch-clone 프로젝트는 domain이 분리된 모듈로 개발되고 있습니다.

즉 api-module로 들어오는 사용자의 구독 요청에 user-module의 구독 usecase를 호출합니다.

 

구독에 필요한 부가 기능인 결제를 추가했지만 user-module에서 한 번에 처리되는 게 불편합니다.

 

payment-module로 결제를 분리하고 usecase를 별도로 만들었습니다.

그리고 구독에 트랜잭션을 걸어 구독과 결제를 하나의 업무 단위로 움직이게 설계했습니다.

 

결제가 추가되었음에도 불구하고 api-module에서는 이전의 usecase를 동일하게 사용할 수 있습니다.

즉 구독에 필요한 로직이 변경되더라도 외부에 변화가 없는 느슨한 결합의 로직이 완성되었습니다. 

 

하지만 단점에도 불구하고 우리는 api-module에서 2PC 패턴으로 트랜잭션을 관리하는 모델을 최종 선택 했습니다.

 

2. 왜 2PC 패턴인가?

선택의 이유를 좀 더 쉽게 설명하기 위해 외부 서비스 로직이 있다고 가정하고 확장했습니다.

결제를 하기 위해서는 부정 방지 여부를 확인해야 하고, 구독이 성공하면 기록을 남겨야 합니다.

• 이 모델은 Choreographed SAGA 패턴과 유사합니다.
  • 메시지 브로커 활용 대신 트랜잭션을 잡고 있는 점이 달라 장애 처리는 비교적 용이하지만,
    복수 개의 서비스에 연쇄적인 트랜잭션이 생기고 있어 관리와 추적이 힘들다는 단점이 같습니다.
  • 반면 2PC 패턴은 트랜잭션의 관리 주체가 한 곳으로 집중되어 트랜잭션 관리가 용이합니다.
• api-module만이 Spring 의존도를 가지며 그 외 module은 도메인 로직만을 가지도록 설계했습니다.
  따라서 usecase에 따라 각 module에서 생성된 결과를 api-module에서 영속시킵니다.
• 사이드 프로젝트이기에 복잡도가 높지 않기에 로직의 추가가 api-module에 영향을 주어도 괜찮다고 생각했습니다.

위와 같은 이유로 느슨한 결합을 일부 포기하더라도 2PC 패턴을 선택하는 게 좋다고 판단했습니다.

 

마치며

모든 패턴에는 장단점이 존재하기에 최신의 이상적인 모델만을 고수하는 것은 정답이 아닙니다.

중요한 것은 주어진 업무 성격과 인프라 제반 사항, 인력 분배와 러닝 커브, 운영까지를 고려하여 트레이드오프 하고 지금에 맞는 베스트 프렉티스를 선별하는 것이고, 그런 능력을 가져야 합니다.입니다.

그렇기 위해서는 많은 패턴을 학습하고 설계해봄으로써 배경 지식을 쌓아야 합니다.

 

이번 설계가 그러했습니다. 

아마 실무였다면 트랜잭션 타임을 줄이기 위해 MQ를 도입하고 Orchestration Saga 패턴을 고려했을 것 같습니다.

하지만 사이드 프로젝트에 MQ까지 고려하는 것은 힘들었고, 학습 목표인 도메인 분리와 모듈 프로그래밍에 맞게 좀 더 쉬운 아키텍처를 선택했습니다.

 

마지막으로 극도의 성능과 분산 트랜잭션이 필요하다고 알려진 게임 분야에서도 필요에 따라서는 2PC를 구현하여 성공적으로 운영하는 사례를 공유하며 마무리합니다.