이전 직장에서 N+1 로 60~90초 걸리던 조회를 개선한 경험이 있는데, MyBatis 환경이었다.\nJPA 환경에서 같은 문제를 재현하고 개선 전략을 수치로 비교하고 싶었다.
\n앨범 목록 API(앨범 + 대표 아티스트명 + 트랙 목록)를 만들었다. Album→Artist(ToOne),\nAlbum→Tracks(OneToMany) 모두 LAZY. 리포지토리는 findAll(Pageable) 하나 —\n코드 어디에도 반복 조회가 없다. 그런데:
앨범 30개 조회 = 쿼리 61개 이상 (목록 1 + artist 30 + tracks 30)쿼리는 리포지토리가 아니라 DTO 변환 중(지연 로딩 접근)에 나간다. 이게 N+1 이 늦게\n발견되는 이유다. MyBatis 는 resultMap 의 collection 쿼리가 XML 에 보이는데, JPA 는\ngetMainArtist().getName() 한 줄이 조용히 SELECT 를 만든다. 그리고 응답은 완전히\n정확하다 — N+1 은 틀린 결과가 아니라 느린 결과라서 기능 테스트로는 절대 안 잡힌다.
측정은 Hibernate Statistics(PrepareStatementCount)로 했다. “느린 것 같다”가 아니라\n쿼리 수를 직접 센다.
앨범 200 / 트랙 2,000 / 페이지 50, 3회 중앙값. 지표를 두 개 봤다 —\n쿼리 수와 함께 Album 엔티티 로드 수(EntityLoadCount).
\n| 전략 | \n쿼리 수 | \nAlbum 로드 수 | \n중앙값 | \n
|---|---|---|---|
| NAIVE (LAZY 순회) | \n102 | \n50 | \n110ms | \n
| fetch join | \n2 | \n200 | \n33ms | \n
@EntityGraph | \n2 | \n200 | \n22ms | \n
default_batch_fetch_size=100 | \n4 | \n50 | \n- | \n
쿼리 수만 보면 fetch join 완승(102→2)이다. 그런데 로드 수가 이상하다.\n페이지는 50개를 요청했는데 전체 200개를 로드했다.
\n컬렉션 fetch join 에 페이징을 걸면 Hibernate 는 LIMIT 을 SQL 로 못 내린다 —\n한 앨범이 트랙 수만큼 여러 행으로 뻥튀기된 결과에서 50행을 자르면 앨범 50개가\n아니기 때문이다. 대신 전체를 메모리에 올려놓고 자른다 (로그의 HHH90003004 경고).\n앨범이 200개라 33ms 지, 200만 개면 OOM 이다. @EntityGraph 도 SQL 형태가 같아\n함정을 그대로 공유한다 — 차이는 선언 방식이지 성능이 아니다.
페이징을 DB 에 남기는 컬렉션 해법은 batch fetch 뿐이었다 (쿼리 4개, 로드 50개).
\ndefault_batch_fetch_size 는 SessionFactory 설정이라 쿼리 단위로 켤 수 없다.\n그래서 벤치마크도 별도 테스트 컨텍스트가 필요했는데, 그 클래스에서 실행되는\n서비스 코드는 NAIVE 벤치마크와 한 글자도 다르지 않다. 같은 코드가 설정 한 줄로\n102쿼리 → 4쿼리가 된다. 동작 원리는 LAZY 프록시 초기화 시 영속성 컨텍스트의 같은 타입\n미초기화 프록시를 batch_size 개까지 모아 IN 쿼리 하나로 로딩하는 것.
open-in-view: false 전제라 DTO 변환은 @Transactional(readOnly=true) 안에서.\nOSIV 로 미루면 편하지만 트랜잭션 밖 커넥션 점유를 편의로 포장하는 것이다벤치마크 코드: AlbumFetchStrategyBenchmarkTest
\n집계 테이블 기반 “실시간 TOP 100 차트” API. 모든 사용자가 같은 것을 본다 —\n전형적인 읽기 편중 + 핫키 하나 워크로드다. 결정이 세 겹이었다.
\n“Redis 차트면 ZINCRBY + ZREVRANGE 지” 싶었는데, 기각했다. 결정타는 멱등성이다.
\n컨슈머가 같은 배치를 재처리하면 DB 는 event_id UNIQUE 로 걸러내지만\nZINCRBY 는 그대로 두 번 더해진다. 04편에서 세운 멱등성 체계 밖에 비원자\n이중 쓰기 경로를 만드는 구조다. Redis 에도 중복 판정을 만들면 되지만, 그건 같은\n체계를 두 번 구현하는 것이다. DB 집계(TOP 100 쿼리) + 캐시로 갔다.\n설계 결정은 독립적이지 않다 — 앞의 결정이 뒤의 선택지를 제약한다.
Write-through 는 기각: 쓰기 주체(컨슈머, 초당 수백 건)와 읽기 주체(차트 API)가 달라서,\n아무도 안 읽는 사이에도 집계마다 TOP 100 재계산을 강요하는 꼴이다.\n차트는 엔티티 캐시가 아니라 쿼리 결과 캐시라 읽기 쪽에서 채우는 게 자연스럽다.
\n물리 TTL 하나만 쓰면 만료 순간 동시 요청 전부가 DB 로 몰린다.\n캐시가 가장 필요한 순간에 캐시가 없다.
\nsoft TTL 30s : 논리 만료. 지나면 stale — 즉시 응답하고 갱신은 백그라운드 1개 스레드만\nhard TTL 120s : 물리 만료. Redis 가 실제로 지운다\n완전 미스 : ReentrantLock 단일 비행 — 1개 요청만 DB, 나머지는 대기 후 재확인\nRedis 장애 : DB 직접 조회 폴백 — 캐시는 성능 장치지 가용성 의존점이 아니다soft >= hard 설정은 기동 실패로 막았다 — stale 서빙 창이 없으면 이 구조가 무의미해진다.\n04편의 TTL 부등식과 같은 패턴: 설정값을 안전성 조건으로 다룬다.| 검증 대상 | \n방법 | \n
|---|---|
| 캐시 히트 | \nDB 를 바꾼 뒤 응답이 안 바뀌는 것으로 증명 (호출 횟수 카운팅보다 견고) | \n
| stale 동작 | \n30초 대기 대신 generatedAt 을 과거로 조작한 캐시를 주입 | \n
| 단일 비행 | \n빈 캐시에 10 스레드 동시 진입 → DB 호출 정확히 1회 단언 | \n
| Redis 장애 | \n컨테이너를 멈추지 않는다 — 빈 포트를 바라보는 커넥션 팩토리를 조립. 장애는 기다리는 게 아니라 만드는 것 | \n
k6 로 캐시 ON/OFF 를 비교했다 (별도 글 예정인 M4 부하 테스트의 일부).
\n| 시나리오 | \n처리량 | \np95 | \n
|---|---|---|
| 50 VU, 캐시 ON | \n479 rps | \n4.2ms | \n
| 50 VU, 캐시 OFF | \n478 rps | \n5.0ms | \n
| 200 VU 풀부하, 캐시 ON | \n4,167 rps | \n55.7ms | \n
| 200 VU 풀부하, 캐시 OFF | \n3,562 rps | \n99.3ms | \n
| Redis 정지 (캐시 ON) | \n81 rps | \n523ms · 실패율 0% | \n
저부하에서는 캐시가 무의미했다. 인덱스 타고 버퍼 풀에 올라간 DB 도 p95 5ms 다.\n“DB 가 느려서 캐시를 얹는다”는 전제가 이 규모에선 측정으로 기각된 것.\n캐시의 진짜 역할은 고부하에서 드러났다 — 응답을 빠르게 하는 게 아니라\nDB 를 병목에서 제거한다 (p95 43% 감소, 남은 지연은 웹 계층으로 병목 이동).
\nRedis 를 정지시킨 상태에서도 1,650 요청 실패율 0% — 다만 전 요청이 타임아웃\n500ms 를 태우고 폴백했다. “다음 개선은 서킷 브레이커”라는 결론까지가 측정의 산출물이다.
\n상세: ADR-0005
\n메타데이터와 집계만 있던 파이프라인에 실제 재생 경로를 붙였다.\n제약: 기존 코드 무변경 — streaming/ 패키지와 audio_asset 테이블만 추가.
원본 음원은 ffmpeg 합성 사인파다. 저작권 문제가 없고, 길이를 track.duration_ms\n와 정확히 일치시킬 수 있어 검증이 깨끗하며, 저장소엔 바이너리 대신 재현 방법을\n버전관리한다. 트랙마다 주파수를 trackId 에서 유도해서 “다른 트랙인데 같은 소리” 같은\n배선 오류를 귀로 잡을 수 있게 했다.
media-store/{trackId}/\n├─ master.m3u8 마스터 플레이리스트: \"무엇을 고를 수 있나\" (EXT-X-STREAM-INF)\n├─ v64k/playlist.m3u8 미디어 플레이리스트: \"어떤 순서로 재생하나\" (EXTINF, ENDLIST)\n├─ v64k/seg_000.ts ... MPEG-TS 세그먼트 (AAC)\n└─ v128k/...variant 인코딩·분할은 ffmpeg 에 맡기고 마스터 플레이리스트는 직접 썼다 —\nBANDWIDTH(비트레이트 + TS 오버헤드)와 CODECS(“mp4a.40.2” = AAC-LC)가 어디서\n오는지 코드에 남는다. 플레이어는 이 두 값으로 다운로드 전에 variant 를 고른다.\nABR 의 선택 근거가 마스터에 선언돼 있다는 게 HLS 구조의 핵심이다.
검증은 ffprobe 교차 검증 — 우리가 만든 산출물을 우리가 아닌 도구가\n“AAC + MPEG-TS, 길이 N초”로 읽는지 확인한다. 생성기와 검증기가 같으면 순환 논증이다.
\n같은 문제(“파일 일부만 전송”)를 자르는 주체가 다르다.
\n| \n | Range (프로그레시브) | \nHLS | \n
|---|---|---|
| 자르는 주체 | \n클라이언트, 바이트 단위 | \n서버, 미디어 단위(미리) | \n
| 탐색 | \nRange: bytes=N- 재요청 | \n다른 세그먼트 요청 | \n
| 화질 전환 | \n표현 불가 | \nvariant 의 같은 시점 세그먼트 | \n
| CDN | \n부분 요청이라 비효율 | \n세그먼트 = 완결된 정적 파일 | \n
Spring 은 ResponseEntity<Resource> 를 반환하면 Range 를 자동 처리한다 —\n세그먼트에 bytes=0-99 를 보내면 206 + Content-Range 가 온다. HLS 플레이어는 안\n쓰지만 두 방식의 차이를 설명하는 살아 있는 데모가 된다.
패키징을 입수 후 미리 할 것인가, 첫 재생 요청 때 할 것인가. 측정을 위해\naudio_asset 테이블에 packaging_ms/storage_bytes 컬럼을 스키마 단계에 넣었다.
실카탈로그 21트랙(평균 220초) 측정:
\n| 지표 | \n값 | \n
|---|---|
| 패키징 시간 | \n평균 5.4초 (2.6~7.9초) | \n
| 스토리지 | \n5.51 MB/트랙 (비트레이트 역산과 일치) | \n
| 5만 트랙 외삽 | \n269 GB, 8워커 병렬 약 9.4시간 | \n
가설은 “온디맨드도 1초쯤이면 쓸 만하다”였다. 실측 5.4초로 기각. 음악 재생의 기대\n반응시간은 백 ms 대다. Zipf 분포로 “롱테일은 안 들으니 아끼자”는 온디맨드 옹호 논리도\n뒤집으면 “롱테일 청취자만 5초 페널티”다. 사전 생성을 기본으로, 온디맨드는 같은\n준비 경로를 쓰므로 한계 비용 0 으로 보조·복구용으로 남겼다.
\n새 도메인인데 새 개념이 거의 없었다.
\nUNIQUE(track_id) INSERT 원자성 (M1 재처리 claim 패턴)패턴의 재사용이 곧 설계 일관성이라는 게 이 모듈의 결론이다.
\n\n