분산 트랜잭션

분산 트랜잭션은 두 개 이상의 네트워크로 연결된 시스템(데이터베이스, 메시지 큐 등)에 걸쳐 있는 트랜잭션을 의미한다.
핵심은 원자성을 보장하는 것이다. 즉, 모든 서비스의 작업이 성공하거나, 하나라도 실패하면 모두 이전 상태로 되돌려야 한다.

MSA에서 분산 트랜잭션을 달성하는 방법론

2PC (Two-Phase Commit)

• 가장 전통적인 방법으로, 트랜잭션 조정자(Coordinator)가 모든 참여 서비스에 '준비'를 시키고, 모두 OK 사인을 보내면 '커밋'을 수행한다.
  • 장점 : 강력한 일관성을 보장한다.
  • 단점 : 모든 노드가 응답할 떄까지 리소스를 점유하므로 성능 저하가 심하고, 장애 시 단일 실패 지점이 될 수 있어 현대적인 MSA에서는 잘 사용하지 않는다.

Saga 패턴 (가장 권장되는 방식)

• 각 서비스의 로컬 트랜잭션을 순차적으로 실행하며, 실패 시 이전에 성공한 작업들을 취소하는 **보상 트랜잭션(Compensating Transaction)**을 실행하는 방식이다.
  • Choreography 기반 : 중앙 제어자 없이 각 서비스가 이벤트를 주고받으며 다음 단계를 진행한다.
    • 간단한 구조에 유리
  • Orchestration 기반 : 별도의 오케스트레이터가 전체 흐름을 제어한한다.
    • 복잡한 비즈니스 로직 관리에 유리ㅌ

TCC (Try-Confirm-Cancel)

• Saga와 비슷하지만, 비즈니스 로직을 '시도-확정-취소'의 3단계로 명확히 나눈다.
  • Try : 자원을 가선점 (예: 포인트 차감 전 예약 상태로 변경)
  • Confim : 모든 서비스의 Try가 성공하면 확정
  • Cancel : 하나라도 실패하면 가선점된 자원을 해제

예시 : 유저 서버 <-> 슬롯 서버 트랜잭션 관리 전략

추천 전략 : Saga 패턴 (Orchestration 방식)

• 유저의 돈이 걸린 문제이므로 **최종 일관성(Eventual Consistency)**를 유지하는 Saga 패턴이 가장 적합하다.

1. 유저 서버 (시작) ; 유저의 보유 금액을 차감(또는 점유)하고 BettingStarted 이벤트를 발행한다.
2. 슬롯 서버 : 이벤트를 수신해 게임 로직을 처리한 뒤, GameResultCalculated 이벤트를 발행한다.
3. 유저 서버 (마무리) : 게임 결과에 따라 당첨금을 지급하거나 차감 상태를 확정한다.
4. 에러 처리 (보상) : 슬롯 서버에서 오류가 발생하면 유저 서버로 BettingFaild 이벤트를 보내 차감했던 금액을 다시 복구(보상 트랜잭션)한다.

Tip: Kafka나 RabbitMQ와 같은 메시지 브로커를 활용하고, Transactional Outbox 패턴을 적용해 "DB 업데이트와 메시지 발행"이 원자적으로 일어나도록 설계하는 것이 정석이다.

우리가 했던 방식 - 동기식 요청 기반의 의사 분산 트랜잭션

• 슬롯 서버에서 스핀 요청을 받아, 유저 정보를 유저 서버를 통해 조회
• 그리고 유저의 보유 금액이 충분하다면 스핀 로직을 수행하고, 결과를 바탕으로 다시 유저 서버에 베팅 완료 요청을 보냄
• 유저 서버에서 에러를 전달한다면 슬롯 서버에서도 롤백처리

분산 시스템의 핵심인 결합도 분리와 장애 전파 차단관점에서 위험 요소를 안고 있다.

1. 데이터 저합성의 불일치 (가장 큰 문제)

• 가장 위험한 시나리오는 네트워크 타임아웃
  • 상황 : 슬롯 서버가 유저 서버에 betting 요청을 보냈는데, 유저 서버는 처리를 완료했지만 네트워크 이슈로 응답만 슬롯 서버에 전달되지 못한 경우
  • 결과 : 유저 서버는 베팅을 완료로 처리함
    • 슬롯 서버 : 응답을 못 받았으므로 에러로 판단하여 자신의 트랜잭션을 롤백
    • 현상 : 유저는 돈만 날리고 게임 결과는 기록되지 않는 대형 사고 발생

2. 가용성 저하 (장애 전파)

• 두 서버가 동기(Synchronous) HTTP 호출로 묶여 있기 때문에 런타임 의존성이 매우 강하다
  • 유저 서버가 점검 중이거나 장애가 나면 슬롯 서버의 핵심 기능잉ㄴ '스핀' 자체가 불가능해진다.
  • 유저 서버의 응답이 지연 되면 슬롯 서버의 워커 스레드들이 응답을 기다리며 점유되어, 슬롯 서버까지 함께 느려지는 계단식 장애가 발생한다.

3. 성능 병목

• 유저가 스핀을 한 번 할 때마다 유저 조회(GET) + 베팅 처리(POST)라는 최소 두 번의 네트워크 왕복이 발생한다
  • 단일 DB 트랜잭션에 비해 응답 속도가 현저히 느려지며, 동시 접속자가 몰릴 경우 네트워크 I/O 비용이 서비스의 전체 처리량을 깎아 먹게된다.

1차적으로 우리가 방어한 것 : Resilience4j를 통해 장애 전파 차단, 멱등성 처리