Architectureadvanced검토 2026.08

Outbox Relay와 CDC

Outbox를 Polling 또는 로그 기반 CDC로 전달하는 흐름과 실패 복구를 비교한다.

#outbox#CDC#Debezium#polling

Overview

Outbox Relay는 저장된 Event를 Broker로 옮긴다. Polling Publisher는 Table을 Query하고, Log-based CDC는 MySQL Binlog나 PostgreSQL WAL의 변경을 읽는다. 선택은 규모보다 운영 역량, 지연 목표, DB 권한과 복구 방식에 달려 있다.

핵심 용어

용어설명
Polling일정 주기로 NEW Row를 조회하고 Claim해 발행
CDCTransaction Log의 Insert/Update/Delete를 Change Event로 변환
Claim/Lease여러 Relay가 같은 Row를 동시에 처리하지 않도록 임시 소유권 부여
OffsetCDC가 어디까지 읽었는지 나타내는 복구 위치
Poison Event반복 실패해 정상 흐름을 막는 Event

왜 필요한가

Outbox Row는 저장만으로 가치가 없다. Relay가 느리거나 멈추면 DB는 정상인데 다른 서비스의 View가 오래된 상태가 된다. 전달 방식뿐 아니라 재시작, 중복, 실패 격리, 정리까지 설계해야 한다.

핵심 원리와 내부 동작

Polling은 FOR UPDATE SKIP LOCKED 등으로 Batch를 Claim하고 Publish 후 완료 처리한다. 단순하고 Application이 소유하지만 빈 Poll과 DB Query 부하, Poll 간격만큼 지연이 있다. CDC는 Commit 순서가 기록된 Log를 읽어 저지연·대량 전달에 유리하지만 Connector, Offset, Schema, Snapshot 운영이 추가된다.

flowchart LR; A[Business + Outbox Commit] --> B{Relay}; B -->|Polling| C[Claim rows]; B -->|CDC| D[Read WAL/Binlog]; C --> E[Broker]; D --> E; E --> F[Idempotent Consumer]

Example

SELECT *
FROM outbox
WHERE status = 'NEW' AND available_at <= now()
ORDER BY created_at
FOR UPDATE SKIP LOCKED
LIMIT 100;

Claim 후 오래 걸리는 Network 호출을 DB Transaction 안에서 수행하면 Lock이 길어진다. 짧게 CLAIMED로 바꾸고 Commit한 뒤 발행하며 Lease 만료로 복구하는 방식이 일반적이다.

실무에서 발생하는 문제와 Trade-off

Relay가 여러 대면 경쟁과 순서가 생긴다. 단일 Relay는 단순하지만 병목과 단일 장애점이 된다. CDC는 삭제도 잡고 Source DB Query를 줄이지만 DBA 권한, Log 보존, Connector Upgrade와 Snapshot 폭주를 다뤄야 한다. Schema 변경 시 과거 Consumer가 새 Payload를 읽을 수 있어야 한다.

흔한 오해

  • CDC 자체가 Outbox의 원자성을 만드는 것이 아니다. Transaction Log에 업무 변경만 있으면 내부 DB Schema가 그대로 외부 계약이 될 수 있다.
  • Publish 성공 Ack를 받았어도 상태 저장 실패로 중복될 수 있다.
  • 순서가 필요하면 Global 순서보다 Aggregate별 Partition Key와 Sequence를 먼저 검토한다.

Production Considerations

Relay Lag, Offset Lag, Oldest Event Age, Claim 만료, 실패 원인별 수를 경보한다. Poison Event는 무한 Retry 대신 격리하고 재처리 Tool을 둔다. Outbox Index, Partition/Archive, Log 보존량과 Snapshot 시간을 Capacity Test한다.

Claim Lease, Backoff, 장애 조합, 수동 Replay와 Retention의 상세 운영 기준은 Durable Outbox 운영 설계에서 확인한다.

다른 사람에게 설명한다면

30초: “Outbox Relay는 DB에 쌓인 이벤트를 Broker로 옮깁니다. 간단한 Polling과 Binlog/WAL을 읽는 CDC가 있고, 둘 다 장애 시 중복될 수 있으므로 멱등 처리가 필요합니다.”

2분: Polling의 Claim/Lease와 CDC의 Log/Offset을 비교하고, Publish-상태갱신 사이 Crash, Poison Event, Schema Evolution, Lag 지표까지 설명한다.

Interview Questions

  1. Polling과 CDC의 부하·지연·운영 Trade-off는?
  2. SKIP LOCKED가 무엇을 해결하는가?
  3. CDC Offset 유실과 Log 만료가 만나면?
  4. Outbox Cleanup은 왜 필요한가?

Transactional Outbox, Durable Outbox 운영 설계, 멱등성·중복·순서와 함께 본다.

SOURCE REFERENCES

이 문서의 근거

본문은 Dev Atlas 안에서 완결되며, 검증이 필요할 때만 원문을 확인할 수 있습니다.

원문 출처 보기 1