1. 배경 — 스냅샷 + 뷰 스왑 구조

광고 플랫폼에서 dimension 테이블(user_dimension)을 주기적으로 스냅샷으로 생성하고, 서비스 쿼리는 항상 고정된 뷰(view)를 바라보게 운영하고 있다.

배치 파이프라인은 Spring Batch + Kotlin + MySQL 8.0(Aurora) 조합이며, 뷰만 스왑하면 서비스는 무중단으로 최신 스냅샷을 볼 수 있도록 설계한 상태였다.

이런 구조 덕분에 데이터 적재와 서비스 트래픽을 분리할 수 있어 운영이 훨씬 안전해졌다.

2. 문제 발견 — 배치가 점점 느려진다

배치 로그에서 이런 패턴을 발견했다.

Saver completed | batch=10000 | time=0.76 s
Saver completed | batch=10000 | time=1.04 s
Saver completed | batch=10000 | time=1.71 s
Saver completed | batch=10000 | time=2.02 s
...
Saver completed | batch=10000 | time=4.05 s

• 초반엔 1만 건당 0.7~0.8초 → 점점 늘어나 3~4초까지 걸림.
• 배치 크기를 줄여 5천 건 단위로 바꾸면 초반엔 다시 빨라졌지만, 특정 시점 이후 또 서서히 느려졌다.

3. 원인 추적 — 모든 용의자 점검

• 커넥션 풀 부족?

  → max_connections=3000, Threads_connected≈65 → 여유 충분

• InnoDB 체크포인트 / redo flush?

  → 스파이크는 있었지만, 꾸준히 증가하는 패턴 설명은 부족

• binlog 로테이션? GC pause?

  → 타임라인 대조했지만 1:1로 맞지 않음

➡️ 여러 가능성을 지운 뒤, “점점 느려지는 패턴”이라는 힌트에 집중했다.

4. 범인 — PK 랜덤에 따른 B+Tree 페이지 스플릿

• InnoDB는 데이터를 **클러스터드 인덱스(B+Tree)**에 PK 순서로 저장한다.
• 랜덤 PK(예: UUID v4)를 계속 넣으면 중간 끼워 넣기 발생.