재생 이벤트(초당 수백 건)를 소비해 곡별 재생수를 집계한다. 재생수는 카운터다 —\n두 번 더하면 그냥 틀리고, 틀렸다는 사실조차 알기 어렵다.
\n그리고 Kafka 는 at-least-once 다. 리밸런싱, 오프셋 커밋 전 종료, 운영자의 오프셋 리셋,\nmax.poll.interval.ms 초과 — 컨슈머는 정상 동작 중에도 같은 메시지를 다시 받는다.\n중복 소비는 장애가 아니라 전제 조건이다.
”enable.idempotence=true 켰으니 안전하다”는 말이 자주 나온다. 아니다.
| 설정 | \n막는 것 | \n못 막는 것 | \n
|---|---|---|
| 프로듀서 멱등성 | \n프로듀서 재시도로 인한 브로커 측 중복 저장 | \n컨슈머 재소비 | \n
| Kafka 트랜잭션(EOS) | \nKafka→Kafka 경로의 중복 | \n외부 DB 쓰기 | \n
컨슈머가 DB 에 쓰는 순간, Kafka 가 주는 보장은 끝난다. 멱등성은 우리 몫이다.
\n| 대안 | \n판단 | \n
|---|---|
| A. eventId UNIQUE + 신규분만 집계 | \n✅ 채택 | \n
| B. 오프셋을 DB 에 저장, 집계와 한 트랜잭션 | \n이론상 가장 정확하지만 기각 | \n
| C. Kafka EOS | \n외부 DB 라 적용 불가 (오해 방지용으로 문서에 남김) | \n
| D. 중복 허용 + 주기 재집계 | \n규모가 커지면 A 와 조합 재검토 | \n
B 를 기각한 결정타는 성능이 아니라 검증 가능성이었다. A 는 중복을 일부러\n만들어(오프셋 되감기) 테스트로 증명할 수 있다. B 는 리밸런싱 시나리오 재현이 훨씬\n어려워 “아마 맞을 것”에 기대게 된다. 덤으로 B 는 kafka-consumer-groups.sh 로\nlag 을 보는 표준 운영 도구를 포기해야 한다.
1. 배치 내부 중복 제거 (LinkedHashMap)\n2. 기처리 eventId 선조회 SELECT ... WHERE event_id IN (...)\n3. 신규분만 원본 적재 INSERT IGNORE batch\n4. 트랙별 델타 합산 후 UPSERT play_count = play_count + VALUES(...)rewriteBatchedStatements\n때문에 affected rows 가 -2 로 뭉개질 수 있다. 집계 정확성이 드라이버 설정에\n의존하는 것은 수용 불가. 선조회가 SELECT 한 번 비싸지만 결정적이다.원본 이벤트는 초당 500건이면 하루 4,300만 행이라 TTL 로 지워야 한다.\n그런데 원본 행이 곧 멱등성 판정 근거다 — 지운 뒤 도착한 중복은 신규로 집계된다.
\nTTL(play_event) > retention.ms(play-events)브로커가 이미 지운 메시지는 재소비될 수 없으므로, 이 부등식이 성립하면 중복이 도착할 수\n있는 기간 동안 판정 근거가 반드시 남아 있다. 처음엔 문서에 “두 값을 같이 움직여야 한다”고\n적었는데, 사람이 기억해야 하는 제약은 언젠가 깨진다. 그래서 기동 시점에 검증해\n어기면 애플리케이션이 뜨지 않게 만들었다(fail fast).
\nAdminClient.alterConsumerGroupOffsets 로 오프셋을 0으로 되감아 120건을 전량\n재소비시키고 카운터 불변을 단언했다. 핵심은 duplicate 메트릭을 함께 단언한 것 —\n이게 없으면 “재소비가 안 일어나서 그대로”인 경우와 구분되지 않는다.\n테스트가 실제로 문제를 만들었는지부터 확인해야 다음 단언이 의미를 갖는다.
덤으로 얻은 교훈: @BeforeEach 에서 DB 를 비워도 토픽의 메시지는 남는다.\n오프셋을 되감으면 다른 테스트가 발행한 이벤트까지 살아난다. 이벤트 기반 시스템에서\n“DB 정리 = 깨끗한 상태”는 성립하지 않는다 — 운영에서도 똑같다.
상세: ADR-0003
\n5,000건짜리 입수 파일 처리 중 3,001번째에서 실패하면 어떻게 해야 하나.
\n가장 쉬운 답은 “파일 전체를 한 트랜잭션으로 묶고 실패하면 전량 롤백”이다.\n깨끗해 보이지만, 이 프로젝트에서 이 답을 일부러 구현해서 깨뜨렸다. 결론부터:
\n\n\n전량 롤백은 데이터만 되돌리는 게 아니라 실패 원인 기록까지 지운다.\n그 파일을 다시 넣으면 같은 지점에서 같은 실패를 반복한다.
\n
| 작업 | \n전파 속성 | \n이유 | \n
|---|---|---|
| Delivery 등록 | \nREQUIRES_NEW (즉시 커밋) | \nmessageId UNIQUE 가 중복 실행 차단 장치 — 커밋돼야 다른 트랜잭션에 보인다 | \n
| 검증 실패 기록 | \nREQUIRES_NEW | \n롤백에 휩쓸리면 안 된다. 실패 기록은 재처리의 입력이다 | \n
| 청크(500건) 적재 | \nREQUIRED | \n커밋 단위. 건별 커밋은 fsync 비용, 파일 전체는 undo/락 비용 | \n
| 사후 검증 실패 | \n보상 삭제 | \n이미 커밋된 것은 롤백으로 못 되돌린다 | \n
스트리밍 파싱(StAX)이라 헤더의 ReleaseCount 와 실제 개수가 맞는지는 파일 끝까지\n읽어야 안다. 그때는 이미 여러 청크가 커밋된 뒤다. 그래서 앨범마다 delivery_id 를\n추적 컬럼으로 남기고, 사후 검증 실패 시 “이 파일이 넣은 것만” 지운다.\n트랜잭션으로 못 되돌리는 것을 보상 트랜잭션으로 되돌리는 패턴이다.
@Transactional 은 Spring 프록시가 가로채서 동작한다. 같은 클래스 안에서\nthis.recordFailure() 로 부르면 프록시를 안 거치므로 애노테이션이 조용히 무시된다.\nREQUIRES_NEW 를 붙여놨는데 실패 기록이 롤백에 휩쓸려 사라지는, 원인 찾기 어려운 버그가 된다.
해결은 트랜잭션 경계를 소유하는 별도 빈(IngestTransactionSupport)을 두는 것.\nself-injection 이나 AopContext 도 있지만, 별도 클래스가 “여기가 경계다”를 구조로 드러낸다.\nMyBatis 시절엔 트랜잭션을 한 곳에서 명시적으로 열고 닫아 이 함정을 밟을 일이 적었다 —\n선언적 트랜잭션의 편리함은 이런 암묵성과 맞바꾼 것이다.
이 패턴은 프로젝트에서 세 번 재사용됐다 (입수, TTL 정리 배치, HLS 자산 준비).
\n주장만으로는 부족해서, 기각한 설계를 일부러 재현하는 테스트를 만들었다.
\n| 시나리오 | \n결과 | \n
|---|---|
| 실패 기록을 REQUIRED 로 + 호출자 롤백 | \n기록 소멸 — “왜 실패했는지 모르는 채 데이터만 없는” 상태 | \n
| 실제 구현(REQUIRES_NEW) + 같은 롤백 | \n기록 생존 | \n
| 청크1 커밋 후 청크2 실패 | \n청크1 잔존(전부도 0도 아님) → 보상 삭제가 마무리 | \n
| 파일 전체 단일 트랜잭션 | \n원자성은 완벽, 실패 기록까지 소멸 | \n
네 번째 줄이 이 글의 요지다. “깨끗한 롤백”의 실체는 디버깅 근거의 소실이었다.
\n상세: ADR-0002
\n깨진 JSON 메시지 하나가 파티션에 들어오면 무슨 일이 벌어지나.
\n무한 재시도 설정이라면 그 메시지가 파티션 전체를 막는다(head-of-line blocking).\n뒤에 쌓인 정상 메시지 수만 건이 한 건 때문에 처리되지 않는다. 이게 poison pill 이다.
\nM1 입수에서 “재시도 가능(DB 장애) vs 불가(검증 실패)“를 갈랐던 원칙을 그대로 재적용했다.
\n| 실패 유형 | \n판단 | \n처리 | \n
|---|---|---|
| 역직렬화 실패 | \n백 번 다시 읽어도 같은 바이트는 같은 실패 | \n재시도 없이 즉시 DLQ | \n
| 처리 실패 (DB 등) | \n일시적일 수 있다 | \n지수 backoff(0.5s→1s→2s) 3회 → DLQ | \n
ErrorHandlingDeserializer 가 역직렬화 실패를 예외가 아니라 “값”(null + 원인 헤더)으로\n바꿔준다 — 리스너까지 도달해야 우리가 제어권을 갖는다.DLQ 발행에 기존 JsonSerializer 템플릿을 재사용했더니, 깨진 원본 byte[] 가\nbase64 문자열로 이중 인코딩되어 실렸다. 원본 보존이 DLQ 의 존재 이유인데 증거를\n훼손한 셈. DeadLetterPublishingRecoverer 에 Map<Class<?>, KafkaOperations> 로\nbyte[] 전용 템플릿(ByteArraySerializer)을 따로 매핑해야 한다.
1번을 고치며 DLQ 템플릿의 key 직렬화까지 ByteArray 로 바꿨더니 이번엔 키에서 터졌다.\n역직렬화가 실패한 것은 value 뿐이고 key 는 여전히 String 이다. 이 실패가 연쇄를\n일으켰다 — DLQ 발행 실패 → 에러 핸들러 실패 → 배치 전체 재시도. DLQ 경로 자체가\npoison pill 이 될 수 있다는 것을 몸으로 배웠다.
\n배치 리스너에서 예외를 그냥 던지면 배치 전체가 실패 처리된다.\nBatchListenerFailedException 으로 실패 인덱스를 지정하지 않으면, 깨진 메시지\n앞의 정상 메시지까지 도매금으로 묶인다. “깨진 메시지가 섞인 배치에서 정상 메시지는\n살아남는다”를 테스트로 고정해 두었다.
KafkaHeaders.DLT_* 로 바꿔 단다. 검증할 때 이걸 몰라서 또 한 번 헤맸다상세: ADR-0004
\n