데이터 일관성과 메시징: Outbox 패턴과 대안들

현대 소프트웨어 시스템에서는 데이터베이스와 메시지 브로커(Kafka, RabbitMQ 등)를 연동하여 데이터를 저장하고 이벤트를 전달하는 작업이 흔합니다. 이 과정에서 가장 큰 과제는 데이터 일관성을 보장하는 것입니다. 데이터베이스에 작업이 성공적으로 기록되었지만 메시지가 유실되거나 중복 전송되는 경우, 시스템의 신뢰성이 떨어질 수 있습니다.

이 글에서는 데이터베이스와 메시지 브로커 간의 일관성을 보장하기 위한 대표적인 아키텍처인 Outbox 패턴과 함께, 이를 대체하거나 보완할 수 있는 몇 가지 대안을 살펴봅니다.

---

Outbox 패턴: 데이터 일관성의 기본 솔루션

1. Outbox 패턴이란?

Outbox 패턴은 데이터베이스와 메시지 브로커 간의 작업을 분리하면서도 일관성을 보장하는 아키텍처입니다. 애플리케이션에서 데이터를 저장할 때, 동일한 트랜잭션 내에서 메시지 데이터를 별도의 Outbox 테이블에 기록합니다. 이후, 배치 작업이나 별도의 프로세스를 통해 Outbox 테이블에서 메시지를 읽고 메시지 브로커에 전송합니다.

2. Outbox 패턴의 동작 방식

1. 애플리케이션이 데이터베이스에 데이터를 저장합니다.
2. 동일한 트랜잭션 내에서 메시지 데이터를 Outbox 테이블에 기록합니다.
3. 별도의 배치 프로세스가 Outbox 테이블에서 메시지를 읽어 메시지 브로커에 전송합니다.
4. 성공적으로 전송된 메시지는 Outbox 테이블에서 삭제됩니다.

3. Outbox 패턴의 장점

• 트랜잭션 일관성: 데이터 저장과 메시지 기록을 하나의 트랜잭션으로 처리하여 데이터 유실을 방지합니다.
• 재처리 가능성: 메시지 전송이 실패하더라도 Outbox 테이블에 데이터가 남아 있어 재처리가 가능합니다.
• 유연성: Outbox 테이블을 기반으로 다양한 메시징 시스템과 연동할 수 있습니다.

4. 구현 예시

Outbox 테이블 구조는 다음과 같습니다:

CREATE TABLE Outbox (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    event_type VARCHAR(255) NOT NULL,
    payload TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    processed BOOLEAN DEFAULT FALSE
);

애플리케이션 로직은 데이터 저장과 메시지 기록을 트랜잭션으로 묶습니다:

@Transactional
public void saveDataAndEvent(Data data, OutboxEvent event) {
    dataRepository.save(data);
    outboxRepository.save(event);
}

---

Outbox 패턴의 대안들

Outbox 패턴은 강력한 데이터 일관성 보장 방법이지만, 모든 상황에 적합하지는 않을 수 있습니다. 아래는 Outbox 패턴을 대체하거나 보완할 수 있는 다른 아키텍처와 방법들입니다.

1. Transaction Log Tailoring (CDC)

CDC(Change Data Capture)는 데이터베이스의 트랜잭션 로그를 모니터링하여 데이터 변경 사항을 Kafka와 같은 메시징 시스템으로 전달하는 방식입니다.

• 장점: 애플리케이션 코드를 수정할 필요가 없고 실시간 데이터 스트리밍이 가능합니다.
• 단점: 설정이 복잡하며 데이터베이스 로그에 영향을 줄 수 있습니다.
• 사용 사례: 실시간 데이터 파이프라인.

---

2. Event Sourcing

Event Sourcing은 시스템 상태를 저장하지 않고, 발생한 모든 이벤트를 기록하여 상태를 재구성합니다.

• 장점: 시스템 복구 및 상태 추적이 용이하며 이벤트 변경 이력을 모두 보존합니다.
• 단점: 이벤트 로그 설계가 복잡하며 초기화 시간이 길 수 있습니다.
• 사용 사례: 금융 시스템, 복잡한 상태 관리 시스템.

---

3. Dual Write with Idempotency

데이터베이스와 메시지 브로커에 데이터를 별도로 기록하되, 중복 처리를 방지하는 로직을 구현합니다.

• 장점: 간단한 구현.
• 단점: 완전한 일관성을 보장하지 못하며 재처리 로직이 필요합니다.
• 사용 사례: 데이터 유실 가능성이 적은 비즈니스 로직.

---

4. Distributed Transactions (Two-Phase Commit, 2PC)

데이터베이스와 메시지 브로커가 모두 분산 트랜잭션을 지원할 경우, 두 시스템 간 트랜잭션을 한 번에 커밋하거나 롤백합니다.

• 장점: 완전한 트랜잭션 일관성을 보장.
• 단점: 네트워크 지연 및 성능 저하 문제.
• 사용 사례: 금융 서비스의 소규모 트랜잭션 처리.

---

5. Kafka Exactly-Once Semantics

Kafka의 Exactly-Once 메시징 기능을 활용하여 데이터베이스와 메시지 브로커 간 트랜잭션을 묶습니다.

• 장점: Kafka를 사용하는 환경에서 간단히 설정 가능.
• 단점: Kafka 환경에 종속적.
• 사용 사례: Kafka 기반 이벤트 처리 시스템.

---

결론

데이터베이스와 메시지 브로커 간 데이터 일관성을 보장하는 방법은 Outbox 패턴뿐만 아니라 여러 대안이 존재합니다. 각 방법은 다음과 같은 상황에서 적합하게 사용할 수 있습니다:

• 데이터 일관성 최우선: Outbox 패턴, CDC.
• 실시간 데이터 처리: CDC, Event Sourcing.
• 단순한 구현 필요: Dual Write with Idempotency.
• Kafka 중심 시스템: Kafka Exactly-Once Semantics.
• 완벽한 트랜잭션 보장: Distributed Transactions.

Outbox 패턴은 실용적이면서도 신뢰성이 높아 많은 시스템에서 기본 선택으로 사용됩니다. 하지만, 시스템 요구사항과 제약 사항에 따라 적합한 대안을 고려해보는 것이 중요합니다.

---

추가 자료

• Outbox 패턴 설계 사례
  Outbox 패턴과 @TransactionalEventListener를 비교하며 실무에서 Outbox 패턴을 설계하는 방법을 설명합니다.
• Kafka Exactly-Once Semantics 이해하기
  Kafka의 메시지 전송 보장 옵션에 대해 설명하며 Exactly-Once Semantics의 구현 방법과 한계를 다룹니다.
• Event Sourcing 맛보기 - 이론편
  Event Sourcing의 기본 개념과 장단점, 그리고 CQRS와의 관계를 상세히 설명하는 블로그 포스트입니다.