음원 메타데이터 파일 하나에 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
\nMyBatis/MariaDB 중심으로 4~5년을 일했고, JPA·Kafka·Redis 는 “써봤다”와 “설계할 수 있다” 사이 어딘가에 있었다.\n그 간극을 메우려고 음악 스트리밍 서비스의 백엔드 데이터 파이프라인을 축소 구현했다.
\n두 개의 큰 흐름으로 구성된다.
\n이 도메인을 고른 이유는 두 흐름의 실패 모델이 정반대라서다.\n입수는 “파일 하나가 크고 실패가 부분적” — 트랜잭션 경계 문제.\n이벤트는 “건수가 많고 중복이 정상” — 멱등성 문제.\n한 프로젝트 안에서 서로 다른 정합성 전략을 비교할 수 있다.
\n| 마일스톤 | \n내용 | \n시리즈 글 | \n
|---|---|---|
| M1 | \n도메인 모델링, 배치 insert 최적화, 실패 기록·재처리 | \n02, 03 | \n
| M2 | \nKafka 파이프라인 — 멱등 집계, DLQ, poison pill | \n04, 05 | \n
| M3 | \n실시간 TOP 100 차트 + Redis 캐싱 | \n06 | \n
| M4 | \n성능 검증 — N+1 수치 비교, 트랜잭션 반증, k6 부하 | \n07 | \n
| M5 | \nHLS 오디오 스트리밍 (선택 모듈) | \n08 | \n
| 번외 | \n로컬 Docker DB 가 랜섬 공격당한 이야기 | \n09 | \n
ADR(Architecture Decision Record, 아키텍처 의사결정 기록)은 Michael Nygard 가 제안한\n문서 형식이다. 아키텍처에 영향을 주는 결정 하나마다 “상황(Context) → 결정(Decision) →\n결과(Consequences)” 구조의 짧은 문서를 번호 붙여 남기고, 결정이 바뀌면 문서를 고치는 게\n아니라 새 ADR 이 이전 것을 대체(supersede)한다고 기록한다 — 코드에 깃 히스토리가 있듯\n결정에도 이력을 남기는 것이다.
\n이 프로젝트는 여기에 “검토한 대안들”과 “재검토 트리거”를 더해 6편을 썼다.\n코드가 보여주지 못하는 것은 “왜 그렇게 했나”보다 “무엇을 하지 않기로 했나” 다.\n기각안의 기각 사유가 없으면 6개월 뒤에 같은 논의를 반복한다.
\n이 프로젝트에서 사전 예측이 측정으로 뒤집힌 것이 네 번이다.
\n틀린 예측이 왜 틀렸는지가 맞은 결정보다 배운 게 많았다. 각 글에서 자세히 다룬다.
\n“두 번 호출해도 결과가 같더라”는 함수의 성질 확인일 뿐이다. 실제로 문제 상황을 만들어야 증명이 된다.
\n다음 글부터 마일스톤 순서로 간다. 첫 주제는 JPA 로 넘어온 MyBatis 개발자가\n가장 먼저 부딪히는 벽 — 배치 insert 가 41배 느려지는 이유다.
\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