Transactional Outbox Pattern

분산 환경에서의 문제는 ‘이중 쓰기’ 문제입니다.

• DB에는 저장이 됐는데, 카프카 메시지 발행이 실패한다면?

• 반대로 메시지는 보냈는데 DB 저장에 실패해 롤백된다면?

이러한 데이터 불일치 상황에서 자주 활용되는 강력한 패턴인 트랜잭셔널 아웃박스 패턴이 있습니다.

Dual Write Problem

주문 서비스에서 주문 생성과 재고 감소 이벤트 발행을 동시에 진행하는 경우를 보겠습니다.

[상황]

1. DB 트랜잭션:

   • 주문 데이터를 DB에 저장 (INSERT)

2. 외부 호출:

   • Kafka로 재고 감소 이벤트 발행 (SEND)

[문제]

1. DB 저장은 성공하고, Kafka 이벤트 발행 직전에 서버가 다운 → 주문은 생성됐지만 재고는 줄어들지 않음

2. Kafka에 이벤트는 발행했지만, DB 저장 중 롤백 → 주문은 없는데 재고가 줄어듬 (데이터 불일치)

두 작업은 서로 다른 시스템이기 때문에 하나의 원자적인 트랜잭션으로 묶을 수 없습니다.

이처럼 두 개의 이종 시스템에 동시에 쓰기 작업을 진행하다가 실패한 경우 예외 핸들링을 잘못 해주면 데이터 일관성이 깨질 수 있습니다.

Transactional Outbox Pattern

트랜잭셔널 아웃박스 패턴은 단일 DB에 대해서는 트랜잭셔널한 처리가 가능하다는 것을 활용합니다.

즉, “메시지 발행도 DB 트랜잭션 안에서 처리하자”는 의미입니다.

Kafka에 직접 메시지를 보내는 대신, ‘보낼 메세지’를 DB 테이블(Outbox)에 저장하는 것입니다. 이렇게하면 비즈니스 로직과 메시지 저장이 같은 DB 트랜잭션으로 묶이므로 원자성이 보장됩니다.

[동작 원리]

1. 트랜잭션 시작

2. 비즈니스 로직: Order 테이블에 주문 정보 저장 (INSERT)

3. Outbox 저장: Outbox 테이블에 발행할 이벤트 정보(Payload) 저장 (INSERT)

   • outbox_events table 예:

     • { "eventType": "ORDER_CREATED", "payload": { ... }, "status": "PENDING" }

     column_name	type	description
     id	BIGINT	PK
     event_type	VARCHAR	이벤트 종류 구분
     payload	JSON, TEXT	이벤트 관련 핵심 데이터
     status	VARCHAR	이벤트 처리 상태
     created_date	TIMESTAMP	이벤트 생성 시간

4. 트랜잭션 커밋: 두 데이터가 동시에 저장됨 (실패 시 둘 다 롤백)

5. 메시지 릴레이(Relay): 별도의 프로세스가 Outbox 테이블을 감시하다가, 새로운 데이터가 보이면 Kafka로 실제 메시지를 발행하고 상태를 PUBLISHED로 변경함.

Outbox Pattern 예시

1. 문제 상황 (Dual Write)

@Transactional
public void placeOrderProblematic(...) {
    orderRepository.save(order); // 1. DB 저장
    kafkaProducer.send("stock-decrease", ...); // 2. Kafka 발행
    
    if (true) throw new RuntimeException("강제 에러"); // 3. 예외 발생!
}

• 결과:

  • 예외가 발생해서 DB의 주문 정보는 롤백되어 사라졌습니다.

  • 하지만 이미 발행된 Kafka 메시지는 취소할 수 없어, 재고 서비스는 재고를 줄여버리는 사고가 발생합니다.

2. Outbox Pattern 적용

@Transactional
public void placeOrder(...) {
    orderRepository.save(order); // 1. DB 저장
    
    // 2. Kafka 대신 DB에 이벤트 저장
    OutboxEvent event = new OutboxEvent("stock-decrease", ...);
    outboxRepository.save(event); 
    
    if (true) throw new RuntimeException("강제 에러"); // 3. 예외 발생!
}

• 결과:

  • 예외 발생 시 DB 트랜잭션이 롤백되므로, 주문 정보와 Outbox 이벤트가 모두 깔끔하게 사라집니다.

  • Kafka 메시지는 아예 발행 시도조차 하지 않았으므로 데이터 일관성이 완벽하게 지켜집니다.

아웃박스 이벤트 실행하기: Message Relay

DB에 저장된 이벤트를 꺼내서 실제로 Kafka에 보내주는 역할이 필요합니다. 이를 Message Relay라고 합니다.

구현 방식 1: Polling Publisher

가장 쉽고 직관적인 방법입니다. 스케줄러가 주기적으로 DB를 조회해서 새로운 이벤트가 있으면 메시지 브로커로 발행합니다.

@Scheduled(fixedDelay = 10000) // 10초마다 실행
public void publishOutboxEvents() {
    // 1. 아직 발행 안 된(PENDING) 이벤트 조회
    List<OutboxEvent> events = outboxRepository.findByStatus("PENDING");
    
    for (OutboxEvent event : events) {
        // 2. Kafka 발행
        kafkaProducer.send(event.getTopic(), event.getPayload());
        // 3. 상태 변경 (PUBLISHED)
        event.setStatus("PUBLISHED");
        outboxRepository.save(event);
    }
}

• 장점: 구현이 쉽고 DB만 있으면 됩니다.

• 단점:

  • Polling 주기:

    • 너무 길면 실시간성이 떨어질 수 있습니다.

    • 그렇다고 주기가 너무 짧으면 DB에 심한 부하를 주게 될 것입니다.

  • 중복 발행: 여러 서버가 동시에 Polling 하면 같은 메시지를 중복 발행할 수 있습니다. (스케줄러 락 등으로 방어 필요)

스케줄링에 의한 폴링 방식이 아니더라도 메시지 릴레이를 할 때 주의해야 할 사항은 무엇일까요?

그중 하나는 메시지 릴리에이 실패했을 때 어떻게 처리할 것인지 입니다. (ex: 카프카 메시지 발생 실패)

재시도를 하는 등 다양한 수단을 도입해야 하고, Posion Pill이라고 부르는 메시지 자체가 유효하지 않아서 무조건 실패하는 메시지는 무한정 재시도하도록 구현하면 안 됩니다.

이런 부분을 고려한다면 아웃박스 이벤트 테이블에 재시도 횟수를 함께 저장하는 것도 좋은 방법이 될 수 있습니다.

구현 방식 2: Transaction Log Tailing (CDC)

실무에서 대규모 트래픽 처리에 권장되는 방식입니다. Debezium 같은 CDC(Change Data Capture) 도구를 사용합니다.

• 동작: 애플리케이션은 Outbox 테이블에 INSERT만 합니다. CDC 도구가 DB의 트랜잭션 로그(Binlog)를 실시간으로 감시하다가, 변경 사항을 감지하여 자동으로 Kafka에 메시지를 쏴줍니다.

• 장점: 실시간성이 높고 애플리케이션 부하가 없습니다.

• 단점: 인프라 구성(Kafka Connect, Debezium 등)이 복잡합니다.

Summary

Transactional Outbox Pattern은 메시지 유실을 막는 강력한 도구지만, 만능은 아닙니다.

• 메시지 순서:

  • Polling 방식이나 멀티 스레드 환경에서는 메시지 발행 순서가 뒤바뀔 수 있습니다.

  • 엄격한 순서가 필요하다면 Kafka 파티셔닝 전략과 함께 고려해야 합니다.

• 멱등성(Idempotency) 필수:

  • Relay가 메시지를 보내고 DB 상태를 PUBLISHED로 바꾸기 직전에 죽는다면? 재실행 시 메시지가 중복 발행될 수 있습니다.

  • Consumer 쪽에서는 반드시 중복 메시지를 걸러내는(멱등성) 처리를 해야 합니다.