Slash 24 - 보상 트랜잭션으로 분산 환경에서 안전하게 환전하기 세션을 보고 간단히 정리해 봤다.

https://www.youtube.com/watch?v=xpwRTu47fqY&t=1101s

• 기존에 모놀리식으로 되어있었긴 한데 이거를 MSA로 바꿈
  • 원화 계좌 -> 기존에 있던 로직들이 조금씩 옮겨감
  • 외화 계좌 -> 기존에 없던 신규 상품은 아예 DB도 다르게 해서 개발중

환전은 DB계좌가 분리된 원화서버 / 외화서버에서 개발되어야 한다.

이렇게 되면 Transaction을 할 수 없다.

분산 트랜잭션

• 2PC
  • Two Phase Commit
• Saga Pattern

Two Phase Commit

두 단계로 나눠 커밋 진행

1. Voting
   2. Coordinator 가 각 트랜잭션 참가자에게 커밋 가능 여부를 질의한다.
   3. 그래서 각 트랜잭션은 열고 가능 여부 응답한다.
2. Commit
   5. 모든 참여자가 커밋 가능한 경우 트랜잭션을 진행한다.
   6. 하나라도 실패하면 둘 다 롤백한다.

Saga Pattern

• 각 서비스의 작은 트랜잭션들을 실행하면서 진행
• 특정 단계에서 실패하면 보상 트랜잭션 실행

비교

Sage Pattern

• Choreography Saga
  • 중앙 제어자 없이 메세지를 통해 이벤트를 교환하며 진행
  • SPoF 없고 느슨한 결합이 가능
  • 하지만 진행중 트랜잭션을 추적하거나 디버깅이 힘들다.
• Orchestration Saga
  • 오케스트레이터가 각 서비스에게 트랜잭션과 보상 트랜잭션을 명령하며 진행
  • 오케스트레이터가 SPoF가 될 수 있다.
  • 현재 진행중 상태의 추적이 용의하다.

토스에서는 Orchestration Saga 사용

환전서버가 필요했고, 얘가 진행중인 상태를 관리해야 해서
그래서 환전 서버가 Orchestrator가 되는게 적합하다 생각함

• 하나가 성공하고 그 다음이 실패한 경우
  • 성공한 것을 다시 롤백한다.
    • 참고로 토스에서는 출금을 먼저 처리함 -> 중간 상태가 노출되고 입금한 돈이 빠져나갈 경우가 있기 때문

에러 핸들링 (이게 핵심)

• timeout 에러인 경우
  • 성공했는데 타임아웃이 났을수도 있으니 재확인한다.
  • 그 다음 보상 트랜잭션을 하면 됨.
• 근데 보통 한번 타임아웃 나면 계속 실패한다.
  • 이를 해결하기 위해 Kafka 사용
    • 얘는 이제 그 다음 로직을 실행할지에 대한 것인 느낌이다.
      • 즉 앞에서 어떻게 되었는지(진짜 실패인지 아니면 타임아웃인지) 확인하기 전까지 토픽을 보관하고 있는 것이다(30초 1분 이렇게 상태를 딜레이시켜 보관!)
• 그리고 환전 서버가 죽어버리는 경우 (앞의 환전 지연도 못하는거) 현 상태를 보관하고 있다가 Batch로 재실행
• 트랜잭셔널 메세징 보장을 위해 Producer Dead Letter 사용
  • 서비스 메세지 브로커에 문제가 있으면 PDL 보내서 나중에 부활하면 다시 가져갈 수 있도록 해준다.