중복 처리 재처리 Backfill
3줄 요약
중복 처리 재처리 Backfill 챕터는 중복과 재처리를 장애 예외가 아니라 비동기·batch·stream 운영에서 항상 생길 수 있는 조건으로 다룬다.- 핵심은 event id, business key, checkpoint, processed table, 속도 제한, 검증 SQL을 통해 같은 입력을 다시 흘려도 결과가 안전한지 증명하는 것이다.
- Java/Spring 백엔드 개발자는 consumer, batch, outbox, CDC, backfill 작업에서 누락보다 중복을 택하는 이유와 중복을 흡수하는 설계를 설명해야 한다.
핵심 정리
중복 이벤트가 발생하는 이유: 중복은 broker 버그보다 producer retry, ack 실패, consumer crash, rebalance, outbox 재발행, CDC 재시작, 수동 replay에서 자연스럽게 생긴다.Idempotency와 Deduplication: idempotency는 결과가 한 번으로 수렴하게 만드는 설계이고, deduplication은 처리한 입력을 event id나 business key로 걸러내는 기술이다.Backfill 설계와 속도 제한: backfill은 과거 누락분을 다시 채우는 운영 작업이다. 작은 range, checkpoint, rate limit, stop condition, 검증 query가 필요하다.Reprocessing과 Checkpoint: reprocessing은 같은 입력을 다시 처리하는 일이고 checkpoint는 어디까지 성공했는지 남기는 좌표다. checkpoint만 믿고 검증을 빼면 오염이 고착된다.운영 데이터 재처리 Runbook: runbook은 누가, 언제, 어느 range를, 어떤 속도로, 어떤 검증 기준으로 다시 처리할지 남기는 운영 계약이다.- 이 챕터는 Web-Database의 단일 query/transaction이 아니라 이미 흐른 데이터를 다시 흘릴 때 중복과 부하를 제어하는 문제를 다룬다.
헷갈리는 지점
- 중복을 “없애야 할 버그”로만 보면 누락 위험이 커진다.
- 분산 처리에서는 누락보다 중복이 복구하기 쉬운 경우가 많다.
- 그래서 at-least-once와 idempotent consumer를 기본값으로 둔다.
- dedup table만 있으면 멱등하다고 착각하기 쉽다.
- dedup은 입력을 걸러내는 장치이고, business table의 unique key와 upsert도 함께 필요하다.
- 외부 API side effect에는 idempotency key가 별도로 필요할 수 있다.
- backfill을 단순 대량 SQL로 보면 운영 장애를 만들기 쉽다.
- batch size, sleep, replica lag, API latency, 중단 조건, 재시작 checkpoint가 함께 있어야 한다.
- 완료 후에는 처리 건수보다 source와 target의 의미 있는 합계가 맞는지 확인해야 한다.
확인 질문
- 이 챕터의 핵심 판단 기준은 무엇인가?
- 같은 입력이 두 번 들어와도 business 결과가 한 번으로 수렴하고, 재처리 범위와 checkpoint, 검증 SQL이 남는지다.
- Web-Database와의 경계는 무엇인가?
- Web-Database는 DB 내부 정합성과 query를 다루고, 이 챕터는 이미 흐른 event/batch 데이터를 다시 처리할 때의 중복·속도·검증을 다룬다.
- 개인 프로젝트에서 최소로 챙길 것은 무엇인가?
- processed event table, unique key/upsert, backfill checkpoint table, rate limit, source-target 합계 검증 SQL이다.