메타데이터와 집계만 있던 파이프라인에 실제 재생 경로를 붙였다.\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이전 직장에서 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
\nM3 작업 중 bootRun 이 Unknown database 'music_pipeline' 으로 실패했다.\n어제까지 멀쩡했던 로컬 DB 다. 안에 들어가 보니:
SHOW DATABASES;\n-- RECOVER_YOUR_DATA ← ???\n-- information_schema\n-- mysql\n-- ...\n-- music_pipeline 이 없다RECOVER_YOUR_DATA 데이터베이스 안에는 이런 내용이 있었다.
\n\nAll your data was backed up by us. You must pay 0.013 bitcoin to …\nor in 48 hours, your data will be publicly disclosed and deleted.
\n
노출된 MySQL/MariaDB 를 스캔해서 약한 비밀번호로 로그인하고, DB 를 삭제한 뒤\n랜섬 노트를 남기는 자동화 봇의 전형적인 수법이다.
\n거창한 취약점이 아니다. 조합이 문제였다.
\n# docker-compose.yml (사고 전)\nports:\n - \"3307:3306\" # = 0.0.0.0:3307, IPv6 [::]:3307 까지 바인딩\nenvironment:\n MARIADB_ROOT_PASSWORD: root # 개발용 \"임시\" 비밀번호Docker 포트 매핑의 기본값은 모든 인터페이스(0.0.0.0)다. “로컬 개발용이니까”라고\n쓴 root/root 와 만나는 순간, 네트워크에서 접근 가능한 무인 DB 가 된다.\n공유기 NAT 뒤라고 안심할 수 없다 — IPv6 는 공인 주소가 직접 붙는 경우가 많고,\n같은 네트워크의 감염된 기기가 경유지가 되기도 한다.
ports:\n - \"127.0.0.1:3307:3306\"\n - \"127.0.0.1:9092:9092\"\n - \"127.0.0.1:16379:6379\"mysql.user 에 주입된 계정이 없는지 확인.복원이 몇 분에 끝난 것은 우연이 아니라 “파일이 아니라 재현 방법을 버전관리한다”\n원칙 덕이었다. 데이터가 전부 스크립트에서 재생성되는 구조면 랜섬은 협박이 못 된다.
\n