Have to get fun
재밌오

SAGA(Supervisor 보상 패턴)

현실적인 MSA 서비스간 보상 패턴

비즈니스

sample-order.png

  1. “주문 → 결제 → 배달” 까지는 반드시 하나의 Transaction 으로 이뤄져야 한다. (어느 부분에서던 Exception 발생하면, 모두 없던 것(Rollback) 되어야 한다.
  2. 결제시, 쿠폰은 사용할 수도 안할 수도 있다. 단, 사용한다면 중복 사용이 안되게 데이터 정합성을 반드시 지키도록 처리해야 한다.
  3. 문자발송, 라이더 등록은 retry 되기만 해도된다.

이상적인 패턴?

위와 같이 심플한 비즈니스(?) 가 존재할 때, 보상트랜잭션을 중점적으로 이상적인 패턴을 구현해보자!

일단, 보상트랜잭션이 발생가능한 구간은 아래와 같다.

  • 보상트랜잭션 발생 가능 구간
    1. 주문 Service 처리 실패 시
    2. 결제 Service 처리 실패 시
    3. 쿠폰 Service 처리 실패 시
    4. 배달 Service 처리 실패 시

너무나 케이스가 많다.

예를들어, 결제 Service 에서 처리 후 Exception 이 발생가능한 구간이 너무나 많다.

  • 주문의 요청을 처리하다가
  • 쿠폰 사용하다가 (쿠폰 사용 전? 쿠폰 사용 후?)
  • 배달 요청하다가

심지어, 배달요청은 완료되었으나, 결제 Service 의 추가 로직을 처리하다가 Exception 이 발생할 수 있다.

2. 결제 Service 처리 실패 시

  • 배달 Service 에 요청 전 실패
    • 사용한 쿠폰이 있다면, 쿠폰 사용 취소를 요청해야 한다.
  • 배달 Service 에 요청 후 실패
    • 사용한 쿠폰이 있다면, 쿠폰 사용 취소를 요청해야 한다.
    • 배달….어떻게하지?

SAGA Pattern?

  • Orchestration SAGA 패턴이라면
    • Orchestrator 가 되는 주문 Service 가 책임을 지고 모든 하위 서비스들에게 보상 트랜잭션을 요청해야한다.
    • 쿠폰은 정상처리가 되었는지, 배달이 정상처리가 안되었는지 모든 요청에 대한 정상처리 여부를 관리해 보상트랜잭션을 발행 or 요청해야 한다.
  • Choreography SAGA 패턴이라면
    • 본인의 하위 서비스 (aka. 요청했었던 서비스) 에만 보상트랜잭션을 발행 or 요청해야 한다.
    • 하지만, 하단의 보상트랜잭션의 요청이 실패한다면? 등의 다양한 케이스의 추적이 불가능에 가깝다…
    • 실제 운영시에는 Service 담당자간의 무수한 핑퐁이 왔다갔다할터…

물론 정답은 아니지만..

정답이 어디있겠느냐만, 절대적인 규칙으로 모든 케이스를 심플하게 처리할 수 있다.

  1. 모든 Service 들은 각자 받은 요청을 정성껏 History 관리한다.
  2. (Choreography SAGA 패턴)에 착안해, 각자 서비스들은 Exception 발생했을 경우 충실하게 “실패 이벤트”를 발행한다. Http Response 도 실패로 응답한다.
  3. (Orchestartion SAGA 패턴)에 착안해, “실패 이벤트”는 절대자(Supervisor) 가 구독해 관리한다.
  4. 절대자는 사전에 정의된 실패이벤트에 따라 사전에 정의된 보상을, 각 서비스에 요청한다.
  5. 각 서비스들은 보상을 충실하게 이행한다.

sample-order-best.png

절대자(Supervisor) 는 각 Report 에 대해, 어떤 보상을 발행해야 하는지 사전에 아래와 같이 정의해둔다.

1. 결제Service에서 Report-1 발생시
    쿠폰 취소, 배달 취소, 라이더 매칭 취소, 취소 문자 재발송
2. 결제Service에서 Report-2 발생시
    배달 취소, 라이더 매칭 취소, 취소 문자 재발송
3. 주문Service에서 Report-1 발생시
    주문 자체 로직만 재실행 (하위 서비스는 모두 정상 처리 그대로 Stay! 주문 자체만 retry!)
4. 주문Service에서 Report-2 발생시
    결제 취소, 배달 취소, 라이더 매칭 취소, 취소 문자 재발송
5. 주문Service에서 Report-3 발생시
    결제 취소, 쿠폰 취소, 배달 취소, 라이더 매칭 취소, 취소 문자 재발송

문제점?

절대자(Supervisor) 에 다양한 Report 에 따라 보상을 사전에 정의해 둬야하는 단점이 있다.

또한 그 룰이 비즈니스의 성장에 따라 기하급수로 증가할 수 있다.

하지만, 잘 관리된 룰이라면 케이스에 따른 보상 처리를 한 눈에 파악할 수 있다는 장점. 어느 서비스가 어디까지 보상을 처리했는지 확인이 용이하다는 장점이 있다.

  • 룰 관리가 어려움
  • 하지만, report 에 따른 보상(Compensation)을 한 눈에 확인할 수 있음
  • 운영시, 모니터링이 용이함

Table of Contents