[트러블슈팅] 1. Outbox 스케줄러의 비동기 콜백 지연으로 인한 상태 덮어쓰기(Race Condition) 방어

• 분야: 동시성 제어, Event-Driven Architecture
• 관련 파일: InventoryOutboxHelper.java

1. 발단 및 1차 시도 (불완전한 해결…)

Outbox 패턴을 도입하여 DB에 이벤트를 적재한 후, 5초마다 도는 스케줄러가 카프카로 이벤트를 발행하도록 구성함. 초기에는 동기(get()) 방식으로 발송했으나, 스케줄러의 처리량을 높이기 위해 비동기(whenComplete()) 방식으로 변경하고 실패 시 retryCount를 증가시키도록 로직을 작성했음

2. 무엇이 문제였나?

비동기 처리 도입 후, 간헐적으로 "이미 카프카 발송에 성공한 이벤트가 FAILED 상태로 덮어씌워지는 현상"이 발견됨. 원인은 카프카 브로커의 일시적 지연으로 인한 Race Condition이었음

• 스레드 A(첫 번째 폴링)가 메시지를 쏘고 타임아웃을 기다림
• 타임아웃이 발생하기 직전, 스레드 B(다음 폴링)가 동일한 메시지를 다시 읽어 카프카로 쏘고 성공(PUBLISHED) 처리함
• 직후, 스레드 A의 실패 콜백이 뒤늦게 도착하여 상태를 다시 FAILED로 덮어씌움

3. 해결방법: 상태 가드

분산 환경의 비동기 콜백은 도착 순서를 보장하지 않음. 따라서 DB의 상태를 변경하기 전, 현재 데이터가 내가 기대하는 상태(예: INIT)가 맞는지 확인하는 로직이 필수적이라고 생각함

4. 최종 해결 및 실제 코드

DB에서 데이터를 조회한 직후, 상태가 INIT이 아닐 경우 즉시 로직을 중단하는 멱등성 보장 로직을 추가함

// 비동기 카프카 전송 실패 시 재시도 횟수를 올리고 3회 초과 시 FAILED 처리하는 로직
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void handleFailure(UUID outboxId) {
    outboxRepository.findById(outboxId).ifPresentOrElse(
        outbox -> {
        // 비동기 콜백 지연으로 인한 Race Condition 방어 (상태 가드)
        // 다른 스레드가 이미 성공(PUBLISHED)시켰거나 영구 실패(FAILED) 처리했다면 무시
            if (outbox.getStatus() != OutboxStatus.INIT) {
		            log.warn("Outbox 상태 변경 무시(이미 처리됨). outboxId={}", outboxId);
                return;
            }
            outbox.incrementRetryCount();
            if (outbox.getRetryCount() >= maxRetries) {
                outbox.markAsFailed();
                log.error("[CRITICAL] Order Outbox 최대 재시도 횟수 초과. FAILED 상태로 마킹. 수동 조치 요망. outboxId={}", outboxId);
            }
            outboxRepository.save(outbox);
        },
        () -> log.warn("[Order Outbox] 실패처리대상 없음 outboxId={}", outboxId)
    );
}