DDD 비동기 보상 트랜잭션

1. DDD 관점에 따라, BC와 AR 구성

• 1차적으로 “상품”의 의미에 따라 경계를 나눴습니다.
  • Catalog에서의 상품은 현 시점의 상품 정보
  • Order에서의 상품은 주문 시점의 상품 정보
• 그리고 “트래픽 특성”에 따라 경계를 한번 더 나눴습니다.
  • Catalog - Inventory
    • 상품 자체의 정보는 읽기 위주의 연산
    • 재고 정보는 쓰기 위주의 연산 + 동시성 제어 필요
  • Order - Payment

    • 결제는 주문번호와 금액만 알면 됨

    • 결제는 외부 API (PG사)와 연동

      → API 연동 장애를 고려해, 주문 서비스와 격리 필요

    • PG사 API를 호출하기 때문에, 결국 분산 트랜잭션 처리가 필요

2. 분산/보상 트랜잭션 설계

• BC별로 별개의 DB를 사용하기 때문에, SAGA 패턴을 선택했습니다

  • 2PC는 코디네이터 장애 시 블로킹과 락 점유 시간이 길어, MSA에서 비현실적
  • 추후 워크플로 툴로 자동화 가능

• Event-driven ochestration 방식을 채택했습니다.

  1. 가능하면 비동기로 처리하기 위함

  2. Choreography 방식은 연쇄 트리거 느낌

     → 사가 흐름 추적이 어렵기 때문에, 금전적인 도메인 특성상 배제

• 주문 SAGA 프로세스

  

  

• 주문 SAGA의 보상은 “결제”를 기준으로 되도록 구현했습니다.

  • SAGA 순서 (보상 필요한 단계들만)

    SAGA 시작
    재고 예약
    주문 생성
    결제 승인
    재고 차감
    주문 확정
    SAGA 종료

    • 각 단계 종료 후, SAGA 상태를 변경
    • 재시도 로직으로 인해, 각 단계는 멱등 보장

  • 실제 보상 로직

    SAGA 상태 → 보상 중
    결제 취소 시도
    재고 복구 or 예약 해제
    주문 실패 처리
    SAGA 상태 → 보상 성공

    • 사가 데이터에 결제키가 저장돼있는 경우, 결제 취소 시도

3. 보상 실행 매커니즘

• 보상 프로세스는 3가지가 지켜져야 합니다.

  1. 가까운 시점에 반드시 실행되어야 함

     → 스케쥴러나 이벤트로 감지 필요

  2. 실패 시 재시도, 일정 횟수 이상 실패하면 수동 처리가 되어야 함

     → 보상도 분산 트랜잭션이므로, 중간에 장애 시 대처 필요

  3. 각 단계는 멱등해야 함

     → 재시도 시에 중복 요청이 발생할 수 있기 때문

• 처음엔 데이터를 한 번에 긁어 처리하는 Chunk 방식의 Batch를 떠올렸지만, 구체화할수록 의문이 생겼습니다.

  • 보상 방식
    1. N개의 보상이 필요한 데이터 읽기
    2. 데이터별로 보상 로직 수행 후에 커밋
  • Saga 데이터는 상태를 가지며 여러 스레드가 동시에 건드릴 수 있어, 건별 커밋이 정답이라고 판단
    • Chunk 단위로 트랜잭션을 보장하는 Spring Batch의 경우, 한 건만 실패해도 전체 롤백됨
    • ex) 이미 “결제 취소”로 보상을 했다면?
      • “결제 취소를 취소”하는 것은 거의 불가능..
      • 재결제 필요 → 사용자 경험 낮아짐
  • Chunk Size = 1로 두면, Batch의 이점은 사라짐

• 보상 프로세스는 Saga 실패 직후가 아닌, 별도 스케쥴러가 주기적으로 감지해 실행하는 것으로 설계했습니다.

  • 재시도 가능성이 있기 때문에, 실패 시점 불분명

    → TTL을 넘으면 실패로 간주

  • TTL이 있기 때문에, 주기적 감지 필요

• 결론적으로 스레드 풀을 가진 스케쥴러 워커를 구현했습니다.

  • 문제: 멀티 스레드가 아직 보상 전인 Saga 데이터에 동시 접근 가능
    • 상태 관리를 하기에는 단계가 많지 않음
    • 보상 로직 내부에 외부 호출이 있기 때문에, 프로세스 전체에 트랜잭션 적용 피해야 함
  • 해결: Saga 데이터에 상태를 추가하고, 락 전용 필드를 두는 것으로 구현

4. 비동기 이벤트 송수신 과정에서의 정합성