비동기 분산 트랜잭션(Saga)의 멱등성, 메시지 순서 역전(Out-of-Order) 해결기

• 분야: MSA, Event-Driven Architecture, Saga Pattern, Idempotency, Kafka Partition Key Routing
• 관련 파일: OrderCommandService.java , OrderEventConsumer.java

---

1. 발단: 비동기 환경에서 발견된 '시간차 엣지 케이스'

주문 생성 트랜잭션을 비동기 Saga 패턴(Kafka)으로 분리한 후, 시스템의 안정성을 검증하기 위해 여러 예외 시나리오를 시뮬레이션함. 그중 "유저의 기습 취소" 상황에서 엣지 케이스를 발견함

[시나리오 타임라인]

1. 유저가 주문을 요청하여 상태가 PENDING(대기)이 됨.
2. 유저가 변심하여 즉시 주문 취소(cancelOrder)를 요청함. 상태는 CANCELED가 되고, 깎였을지 모를 재고를 원복하기 위해 STOCK_RESTORE(재고 복구) 이벤트를 Kafka로 발행함. (복구 이벤트 #1)
3. [경합 발생] 그런데 찰나의 시간차로, 인벤토리 서비스는 유저가 취소하기 직전에 이미 재고 차감을 성공하고 ORDER_APPROVED(승인) 메시지를 오더 서비스로 날려둔 상태였다면?
4. 오더 서비스가 뒤늦게 승인 메시지를 수신(approveOrder)함. 이미 취소된 주문이므로 상태 변경은 무시하지만, 인벤토리의 재고가 깎였다는 뜻이므로 롤백을 위해 STOCK_RESTORE를 또 발행함. (복구 이벤트 #2)

2. 문제 인식: "이벤트가 2번 날아가면 재고가 2배로 늘어나는 것 아닌가?" (멱등성 결함)

사실 이전에도 CodeRabbit 코드 리뷰를 통해 "중복 이벤트가 발행되니 인벤토리 서비스의 멱등성 처리가 필수적이다"라는 피드백을 받았음. 그땐 인벤토리에 이미 ProcessedEvent 엔티티를 활용한 멱등성 방어 로직이 있어서 잘못된 피드백인 줄 알았으나, 다시 보니 오더 서비스의 이벤트 발행부에 결함이 있었음.

// [기존 코드 - OrderCommandService.java]
orderOutboxHelper.append("ORDER", orderId, "STOCK_RESTORE",
    // 문제점: 이벤트 ID를 무조건 랜덤 UUID로 생성하고 있음!
    new StockRestoreEventPayload(UUID.randomUUID(), item.getOptionId(), item.getQuantity())
);

위 코드처럼 취소할 때에도 랜덤 UUID를 생성하고, 승인받은 후 롤백할 때에도 또 다른 랜덤 UUID를 생성하면, 인벤토리 입장에서는 "서로 다른 2개의 독립적인 복구 요청"으로 인식하여 재고를 2배로 늘려버리는 상황이 발생함.

3. 1차 해결: 결정적(Deterministic) UUID를 통한 멱등성 보장

이 문제를 근본적으로 해결하기 위해, 같은 비즈니스 행위(특정 주문의 특정 옵션 복구)에 대해서는 항상 동일한 이벤트 ID가 생성되도록 결정적(Deterministic) UUID 부여 방식으로 리팩터링했음.

// [개선된 코드 - OrderCommandService.java]
// 특정 주문과 옵션에 대해 항상 동일한 이벤트 ID를 보장하는 식별자 생성
String uniqueKey = "RESTORE_" + order.getId().toString() + "_" + item.getOptionId().toString();
UUID deterministicEventId = UUID.nameUUIDFromBytes(uniqueKey.getBytes());

orderOutboxHelper.append(
    "ORDER", order.getId().toString(), "STOCK_RESTORE",
    new StockRestoreEventPayload(deterministicEventId, item.getOptionId(), item.getQuantity())
);

💡 검증 및 성과 (실제 운영 로그)

테스트 결과, 오더 서비스는 완벽히 동일한 UUID(7500eaee...)를 가진 이벤트를 2번 발행했고, 인벤토리 서비스는 두 번째 이벤트를 성공적으로 방어했음.

// [1] 오더 서비스: 엣지 케이스 감지 및 2번째 롤백 이벤트 발행
WARN [Order Saga Edge-Case] 이미 유저가 취소한 주문에 대해 승인이 도착했습니다. 인벤토리 롤백 이벤트를 발행합니다: 68578038...

// [2] 오더 서비스 DB (p_order_outbox): 결정적 UUID 생성 확인
{"eventId": "7500eaee-df88-3cb9-a9b5-b97dc7d82d84", "optionId": "1a2e7d36...", "quantity": 1}
{"eventId": "7500eaee-df88-3cb9-a9b5-b97dc7d82d84", "optionId": "1a2e7d36...", "quantity": 1}

// [3] 인벤토리 서비스: 멱등성 필터 작동 (두 번째 요청 방어)
INFO [Kafka Consumer] 재고 복구 이벤트 수신: eventId=7500eaee-df88...
WARN [Idempotency] 이미 처리된 카프카 메시지입니다. 중복 복구를 방지하고 반환합니다. eventId=7500eaee...

결과적으로 동일한 eventId를 가진 롤백 메시지가 발행되었고, 인벤토리는 '[Idempotency] 이미 처리된 카프카 메시지입니다.' 라며 두 번째 요청을 완벽하게 방어했음.

이를 통해 At-Least-Once(적어도 한 번) 전송 보장과 멱등성을 결합하여 데이터 정합성을 지켜냄

---

4. 새로운 발견: 분산 시스템의 최종 보스 "순서 미보장(Out-of-Order)"과 재고 누수

멱등성을 보장했음에도 불구하고, DB 데이터를 교차 검증하는 과정에서 문제상황을 추가로 발견함. 취소 처리 후 현재의 일일 재고가 10개(최대치)로 원복되지 않고 9개로 누수(Leak) 되어 있었음...

[원인 분석: 카프카 토픽 간 순서 미보장]

1. 오더 서비스가 거의 동시에 ORDER_CREATED (주문 토픽)와 STOCK_RESTORE (복구 토픽)를 카프카로 발행함.
2. 서로 다른 토픽이다 보니, 인벤토리의 컨슈머들이 이를 동시에(혹은 순서가 역전되어) 소비함.
3. 찰나의 차이로 복구(+1)가 차감(-1)보다 먼저 실행됨.
4. 재고가 10개(MAX)인 상태에서 복구(+1)가 먼저 들어오니 상한선에 막혀 그대로 10개가 됨.
5. 직후 차감(-1) 로직이 실행되어 재고가 9개가 됨.
6. 이후 오더 서비스가 엣지 케이스 방어 로직으로 쏜 두 번째 복구(+1) 이벤트가 도착했지만, 앞서 3번 단계에서 완성해 둔 '멱등성 필터'에 걸려 정상적인 중복 요청으로 간주되어 무시당함.
7. 결과적으로 재고가 9개로 누수됨.

5. 최종 해결 과정: 단일 토픽 통합 & 파티션 키 라우팅

이 현상은 대규모 분산 시스템의 '토픽 간 메시지 순서 역전(Out-of-Order Delivery)' 문제였음

1) 단일 커맨드 토픽 통합 (application.yml)

기존에 나뉘어 있던 차감/복구 명령 토픽을 inventory.command라는 단일 토픽으로 통합함

2) 파티션 키(Partition Key) 지정 (OrderCommandService.java)

카프카는 동일한 Key를 가진 메시지를 동일한 파티션에 순서대로 넣음. 이를 활용하기 위해, 메시지 발행 시 Key 값을 기존 orderId에서 reservationId로 통일함. (이전에 작업해둔 ORDER_CREATED와 똑같은 카프카 파티션에 들어가게 만들기 위해서 저렇게 넣었음.)

// 파티션 키를 reservationId로 통일하여 In-Order 보장
orderOutboxHelper.append(
	"ORDER",
	order.getReservationId().toString(), // Partition Key 통일
  "STOCK_RESTORE",
  payload
);

6. 최종 검증

테스트 결과, 동일 주문에 대한 차감과 복구가 FIFO 순서로 처리되었으며 재고 누수도 해결됨.

// [1] In-Order 보장 (무조건 차감 -> 복구 순서로 실행됨)
19:22:09.028 [Kafka Consumer] 신규 주문 생성 메시지 수신 -> 재고 다중 차감 시도 (In-Order 처리)
19:22:09.102 [Kafka Consumer] 재고 복구 이벤트 수신 (In-Order 처리)

// [2] 멱등성 보장 (시간차로 늦게 도착한 2번째 복구 요청 차단)
19:22:13.986 [Idempotency] 이미 처리된 카프카 메시지입니다. 중복 복구를 방지하고 반환합니다.