5,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음원 메타데이터 파일 하나에 Release 5,000건, Track 50,000건이 들어온다.\nMyBatis 시절엔 <foreach> 로 multi-value insert 를 쓰면 끝이었는데,\nJPA 로 오니 saveAll() 이 건별 INSERT 를 날리고 있었다.
hibernate.jdbc.batch_size: 1000 을 넣어도 달라지지 않았다. 경고도 로그도 없이.
영속성 컨텍스트는 엔티티를 ID 를 키로 관리한다. 그런데 GenerationType.IDENTITY 는\nAUTO_INCREMENT 라서 INSERT 를 실제로 실행해야 ID 를 알 수 있다.
persist() 시점에 ID 가 필요하므로 즉시 INSERT 할 수밖에 없다코드 차이는 애노테이션 한 줄인데, 이 동작 차이는 어디에도 표시되지 않는다.\nMyBatis 는 SQL 이 XML 에 그대로 보이니 이런 종류의 “조용한 비활성화”가 없다 —\nJPA 로 넘어올 때 가장 조심해야 할 지점이 바로 이 암묵성이라고 느꼈다.
\n같은 데이터(Release 1,000 / Track 10,000), 같은 트랜잭션 경계에서 쓰기 방식만 갈아끼웠다.\nTestcontainers MariaDB, 3회 반복 중앙값.
\n| 전략 | \n중앙값(ms) | \n처리량(건/초) | \n수행 작업 | \n
|---|---|---|---|
JPA IDENTITY | \n17,225 | \n581 | \n순수 INSERT | \n
JPA SEQUENCE (increment 1000) | \n418 | \n23,923 | \n순수 INSERT | \n
| JPA 앱할당 TSID | \n490 | \n20,408 | \n순수 INSERT | \n
| JDBC batchUpdate + UPSERT | \n1,205 | \n8,299 | \nUPSERT + 사후 SELECT | \n
| TSID + 사전 SELECT + UPSERT | \n1,254 | \n7,974 | \n사전 SELECT + UPSERT | \n
IDENTITY 와 SEQUENCE 의 차이가 41배다. 애노테이션 한 줄의 값이다.
\n측정 전 예측은 “JDBC 직접 제어가 제일 빠를 것”이었다. 결과는 SEQUENCE 의 1/3.
\n이유를 파 보니 표의 함정이 보였다. 전략마다 수행하는 작업이 다르다.\nJDBC 행은 “재전송 시 UPSERT” 라는 요구사항을 만족하는 비용까지 포함한 수치고,\nSEQUENCE 행은 순수 INSERT 만 한 수치다. 이 표는 “같은 SQL 의 속도 비교”가 아니라\n“각 전략이 만족하는 요구사항의 비용 비교” 였던 것이다.
\n후속 가설 “사후 SELECT 를 사전 SELECT 로 바꾸면 싸질 것”도 측정으로 기각됐다 —\n이런 조회는 결과셋 크기가 아니라 인덱스 탐색 횟수가 비용을 지배한다.
\n유통사가 같은 앨범을 정정 재전송하는 요구사항(UPSERT 멱등성)이 있어서\nJDBC batchUpdate + ON DUPLICATE KEY UPDATE 를 선택했다. 최고 속도 전략이 아니라\n요구사항을 가장 싸게 만족하는 전략이다. 순수 신규 적재만 있는 시스템이라면 SEQUENCE 가 맞다.
부수 팁: MariaDB JDBC 는 rewriteBatchedStatements=true 로 multi-value 재작성이 가능한데,\n이때 affected rows 가 SUCCESS_NO_INFO(-2) 로 뭉개질 수 있다.\n반환값에 로직을 걸면 안 되는 이유이며, 이 성질은 뒤의 Kafka 멱등성 글에서 다시 등장한다.
상세: ADR-0001
\n재생 이벤트(초당 수백 건)를 소비해 곡별 재생수를 집계한다. 재생수는 카운터다 —\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
\n