{ "componentChunkName": "component---src-templates-blog-template-js", "path": "/Music_Pipeline_01/", "result": {"data":{"cur":{"id":"cb71b72b-21f2-5639-868c-b331fd519ed5","html":"

왜 이 프로젝트인가

\n

MyBatis/MariaDB 중심으로 4~5년을 일했고, JPA·Kafka·Redis 는 “써봤다”와 “설계할 수 있다” 사이 어딘가에 있었다.\n그 간극을 메우려고 음악 스트리밍 서비스의 백엔드 데이터 파이프라인을 축소 구현했다.

\n

두 개의 큰 흐름으로 구성된다.

\n
    \n
  1. 음원 메타데이터 입수 — 유통사가 보내는 DDEX 스타일 XML 을 스트리밍 파싱·검증해 배치 적재
    2. \n
  2. 재생 이벤트 처리 — Kafka 로 초당 수백 건의 재생 이벤트를 수집, 멱등하게 집계해 실시간 차트 제공
    3. \n
\n

이 도메인을 고른 이유는 두 흐름의 실패 모델이 정반대라서다.\n입수는 “파일 하나가 크고 실패가 부분적” — 트랜잭션 경계 문제.\n이벤트는 “건수가 많고 중복이 정상” — 멱등성 문제.\n한 프로젝트 안에서 서로 다른 정합성 전략을 비교할 수 있다.

\n\n

마일스톤 지도

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
마일스톤내용시리즈 글
M1도메인 모델링, 배치 insert 최적화, 실패 기록·재처리02, 03
M2Kafka 파이프라인 — 멱등 집계, DLQ, poison pill04, 05
M3실시간 TOP 100 차트 + Redis 캐싱06
M4성능 검증 — N+1 수치 비교, 트랜잭션 반증, k6 부하07
M5HLS 오디오 스트리밍 (선택 모듈)08
번외로컬 Docker DB 가 랜섬 공격당한 이야기09
\n

프로젝트를 관통한 세 가지 원칙

\n

1. 결정은 ADR 로 남긴다

\n

ADR(Architecture Decision Record, 아키텍처 의사결정 기록)은 Michael Nygard 가 제안한\n문서 형식이다. 아키텍처에 영향을 주는 결정 하나마다 “상황(Context) → 결정(Decision) →\n결과(Consequences)” 구조의 짧은 문서를 번호 붙여 남기고, 결정이 바뀌면 문서를 고치는 게\n아니라 새 ADR 이 이전 것을 대체(supersede)한다고 기록한다 — 코드에 깃 히스토리가 있듯\n결정에도 이력을 남기는 것이다.

\n

이 프로젝트는 여기에 “검토한 대안들”과 “재검토 트리거”를 더해 6편을 썼다.\n코드가 보여주지 못하는 것은 “왜 그렇게 했나”보다 “무엇을 하지 않기로 했나” 다.\n기각안의 기각 사유가 없으면 6개월 뒤에 같은 논의를 반복한다.

\n

2. 측정 없이 믿지 않는다 — 기각된 가설도 기록한다

\n

이 프로젝트에서 사전 예측이 측정으로 뒤집힌 것이 네 번이다.

\n
    \n
  1. “JDBC batch 가 제일 빠를 것” → 아니었다 (수행하는 작업이 다르다)
    2. \n
  2. “fetch join 이 N+1 의 정답” → 쿼리는 줄지만 메모리 페이징이라는 숨은 비용
    3. \n
  3. “DB 가 느려서 캐시가 필요” → 저부하에선 캐시 없이도 p95 5ms
    4. \n
  4. “온디맨드 패키징도 1초쯤” → 실측 5.4초
    5. \n
\n

틀린 예측이 왜 틀렸는지가 맞은 결정보다 배운 게 많았다. 각 글에서 자세히 다룬다.

\n

3. 깨뜨려서 증명한다

\n

“두 번 호출해도 결과가 같더라”는 함수의 성질 확인일 뿐이다. 실제로 문제 상황을 만들어야 증명이 된다.

\n\n

다음 글부터 마일스톤 순서로 간다. 첫 주제는 JPA 로 넘어온 MyBatis 개발자가\n가장 먼저 부딪히는 벽 — 배치 insert 가 41배 느려지는 이유다.

\n
\n
\n\n
","excerpt":"왜 이 프로젝트인가 MyBatis/MariaDB 중심으로 4~5년을 일했고, JPA·Kafka·Redis 는 “써봤다”와 “설계할 수 있다” 사이 어딘가에 있었다.\n그 간극을 메우려고 음악 스트리밍 서비스의 백엔드 데이터 파이프라인을 축소 구현했다. 두 개의 큰 흐름으로 구성된다. 음원 메타데이터 입수 — 유통사가 보내는 DDEX 스타일 XML 을 스트리밍 파싱·검증해 배치 적재 재생 이벤트 처리 — Kafka 로 초당 수백 건의 재생 이벤트를 수집, 멱등하게 집계해 실시간 차트 제공 이 도메인을 고른 이유는 두 흐름의 실패 모델이 정반대라서다.\n입수는 “파일 하나가 크고 실패가 부분적” — 트랜잭션 경계 문제.\n이벤트는 “건수가 많고 중복이 정상” — 멱등성 문제.\n한 프로젝트 안에서 서로 다른 정합성 전략을 비교할 수 있다. 저장소: github.com/Shim8934/media-project 스택: Java 21, Spring Boot 3.4, JPA + JdbcTemplat…","frontmatter":{"date":"July 24, 2026","title":"음악 스트리밍 파이프라인 만들기 - 01. 프로젝트 소개와 세 가지 원칙","categories":"Music_Pipeline","author":"shim8934","emoji":"🎵"},"fields":{"slug":"/Music_Pipeline_01/"}},"next":{"id":"75c81465-2e74-5a62-8afe-eeaed6f49935","html":"

TIL 08. 서버 네트워크 기본

\n
\n

이번 장에서는 서버 내부의 설정 중 윈도와 리눅스 서버에서 네트워크를 각각 어떻게 설정하고 현재 네트워크 상태를 어떻게 확인할 수 있는지가 주관점이다.

\n
\n
\n
\n

1. 서버의 네트워크 설정 및 확인 (OS 별로 정리)

\n

1) 리눅스 서버 네트워크

\n
(1) CentOS의 네트워크 설정
\n\n
\n\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n
CentOS의 인터페이스 설정 시 주요 항목
ONBOOT부팅 시 인터페이스를 활성화시킬 것인지 결정(yes / no)
BOOTPROTO부팅 시 사용할 프로토콜 (none, dhcp, static)
IPADDRIP 주소
NETMASK서브넷 마스크
예) 255.255.255.0
PREFIX서브넷 마스크(비트 값으로 표기)
예) 24
GATEWAY게이트웨이 주소
DNS1주 DNS 정보 입력
DNS2보조 DNS
\n\n \n \"CentOS_NIC\"\n \n
\n\n
\n
* ifconfig (Linux) & ipconfig (Window)
\n\n

​\t위의 예시는 ifcfg-enp0s8 인터페이스를 다운시킨 후, ifconfig를 통한 정보 확인 과정이다. 기존에 출력하던 ip 주소, netmask 등의 정보가 표기되지 않는 것을 확인할 수 있다.

\n
\n
(2) 우분투 서버 네트워크
\n\n
\n

2) 윈도우 서버 네트워크

\n\n
\n
\n

2. 서버의 라우팅 테이블

\n
\n

이번 단원에서는 서버의 라우팅 동작을 이해하기 위한 라우팅 테이블 확인 방법에 초점을 둔다.

\n

이번에 살펴볼 항목들은 아래와 같다.

\n
    \n
  1. 목적지 (Destination)
    2. \n
  2. 서브넷 (Genmask)
    3. \n
  3. 게이트웨이 (Gateway)
    4. \n
  4. 인터페이스 (face)
    5. \n
  5. 우선순위 (Metric)
    6. \n
\n
\n

1. 라우팅 테이블 출력 시 출력 항목

\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n
서버 라우팅 테이블 항목
10.10.20.02410.10.10.1eth110
목적지서브넷게이트웨이인터페이스우선순위
\n\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n
라우팅 테이블 항목 부가 설명
1. 목적지와 서브넷서버가 통신하려는 목적지 IP 주소에 맞는 라우팅을 선택하는 기준점.
라우팅할 때 목적지 네트워크 주소와 서브넷으로 표현되는 목적지 네트워크 범위 내에 서버가 통신하려는 IP 주소가 속한 라우팅 테이블을 선택하게 된다.
2. 게이트웨이선택된 목적지로 가기 위해 서버에서 선택하는 넥스트 홉.
만약 서버에 두 개 이상의 네트워크 카드(NIC)가 존재한다면 원하는 네트워크 카드의 게이트웨이로 지정해 주어야 한다.
3. 인터페이스서버의 네트워크 카드를 의미하며, 라우팅에서 어떤 물리적인 경로로 패킷을 내보낼지 설정한다.
4. 우선순위동일한 라우팅 테이블이 두 개 이상 존재할 때 어떤 라우팅 테이블을 선택할지 정하는 값이다. 이 값이 낮을 수록 우선순위가 높아진다.
\n
\n

2. 리눅스 서버의 라우팅 확인 및 관리

\n
1. 라우팅 테이블 확인
\n
    \n
  1. \n

    ip route

    \n\n

    \n \n \n

    \n
    2. \n
\n

​\t

\n
    \n
  1. \n

    netstat -r

    \n\n

    \n \n \n

    \n\n

    \n \n \n

    \n
    2. \n
\n
\n
2. 라우팅 테이블 추가하는 설정
\n
    \n
  1. \n

    임시적 라우팅 테이블 추가

    \n
      \n
    1. \n

      route add / del (추가 / 삭제)

      \n
      route add { -host | -net } Target[/prefix] [gw GW] [metric M] [[dev] If]   # 추가\r\nroute del { -host | -net } Target[/prefix] [gw GW] [metric M] [[dev] If]   # 삭제
      \n
      2. \n
    2. \n

      이 명령어 뿐만 아니라 ip route 옵션 뒤에 add 옵션을 사용하는 것도 동일하게 추가할 수 있다.

      \n
      3. \n
    3. \n

      디폴트 라우팅 설정 - 일반 라우팅 설정과 동일하지만 목적지 네트워크를 default로 표기해 설정할 수 있다.

      \n
      route add default gw 10.1.1.1 dev eth0   # 추가\r\nroute del default gw 10.1.1.1 dev eth0   # 추가
      \n
      4. \n
    \n\n
    2. \n
\n
\n
    \n
  1. 영구적 라우팅 설정
    2. \n
\n
1) Cent OS의 영구적 라우팅 설정
\n\n
\n
2) 우분투의 영구적 라우팅 설정
\n\n
\n
3) 윈도우 서버의 라우팅 설정
\n\n
\n
    \n
  1. \n

    PRINT

    \n\n

    \n \n \n

    \n
    \n\n
    \n
    2. \n
  2. \n

    ADD

    \n\n
    \n
    3. \n
  3. \n

    DELETE

    \n\n
    \n
    4. \n
  4. \n

    CHANGE

    \n\n
    5. \n
\n
\n
\n

3. 네트워크 확인을 위한 명령어

\n

1) ping (Packet InterNet Groper)

\n\n
ping [옵션] 목적지_IP 주소
\n\n
\n
(1) 리눅스 ping 옵션
\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n
리눅스 ping 명령어 옵션
-c
count		ping을 보내는 패킷(ECHO_REQUEST)을 몇 번 보내고 종료할 것인지를 지정
-i
interval		패킷을 보내는 시간 간격. 기본 설정값은 1초. 슈퍼 유저의 경우, 0.2 이하로 설정 가능
-I
interface		패킷을 보낼 때, 출발지 주소를 지정. 실제 IP 값을 지정하거나 인터페이스 이름을 지정하면 출발지 주소가 변경됨. 이 옵션을 사용하지 않는 경우, 라우팅 테이블에 의해 나가는 인터페이스(Outgoint-Interface)의 IP 주소가 출발지 주소가 됨.
-s
packetsize		패킷 크기를 지정. 기본 설정값은 56바이트(8바이트의 ICMP 헤더가 추가로 붙어 64바이트를 송신)
\n
\n
(2) 윈도우 ping 옵션
\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n
윈도우 ping 명령어 옵션
-n
count		ping을 보내는 패킷(ECHO_REQUEST)을 몇 번 보내고 종료할 것인지를 지정
기본 설정은 4회 전송
-t중지할 때까지 지정한 호스트로 ping을 지속적으로 전송
-S
srcaddr		사용할 원본 IP 주소로, 리눅스의 -I 옵션과 동일
-l
size		패킷 크기를 지정. 기본 설정값은 32바이트
-r
count		count 홉의 경로 기록(최대 9홉까지 설정 가능)
\n
\n

2) netstat (network statistics)

\n\n
(1) 리눅스 netstat 옵션
\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n
리눅스 netstat 명령어 옵션
-a
--all		모든 연결과 수신 대기 포트 표시
-n
--numeric		주소와 포트 번호를 숫자 형식으로 표시 (예: http → 80 )
-r
--route		라우팅 테이블 표시
-i
--interfaces		인터페이스별 입출력 패킷 통계
-s
--statistics		네트워크에 통계 데이터 출력
-p
--programs		PID와 프로그램 이름 출력
-t
--tcp		TCP만 출력 (TCP, TCPv6)
-4 / -6IPv4나 IPv6에 대해 출력
\n
\n
(2) 윈도우 netstat 옵션
\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n
윈도우 netstat 명령어 옵션
-a모든 연결과 수신 대기 포트 표시
-n주소와 포트 번호를 숫자 형식으로 표시 (예: http → 80 )
-r라우팅 테이블 표시
-e이더넷 통계를 표시. 이 옵션은 -s 옵션과 함께 사용 가능
-s프로토콜별 통계를 표시. 기본적으로 IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP 및 UDPv6에 대한 통계를 표시한다.
-p 옵션을 사용해 기본값의 일부 집합에 대한 통계만 표시
-p
--proto		proto로 지정한 프로토콜의 연결을 표시.
proto는 TCP, UDP, TCPv6, UDPv6 중 하나로, -s 옵션과 함께 사용해 프로토콜별 통계를 표시할 경우, proto는 IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP 및 UDPv6 중 하나를 사용
\n
\n
\n
\n\n
","frontmatter":{"date":"August 01, 2022","title":"TIL 08. 서버 네트워크 기본","categories":"IT_엔지니어를_위한_네트워크_입문","author":"shim8934","emoji":"😄"},"fields":{"slug":"/IT엔지니어를_위한_네트워크_입문_08/"}},"prev":{"id":"c5d7d09a-9e82-5065-a87f-08c6c0216000","html":"

문제

\n

음원 메타데이터 파일 하나에 Release 5,000건, Track 50,000건이 들어온다.\nMyBatis 시절엔 <foreach> 로 multi-value insert 를 쓰면 끝이었는데,\nJPA 로 오니 saveAll() 이 건별 INSERT 를 날리고 있었다.

\n

hibernate.jdbc.batch_size: 1000 을 넣어도 달라지지 않았다. 경고도 로그도 없이.

\n

원인 — IDENTITY 는 batch 를 조용히 끈다

\n

영속성 컨텍스트는 엔티티를 ID 를 키로 관리한다. 그런데 GenerationType.IDENTITY 는\nAUTO_INCREMENT 라서 INSERT 를 실제로 실행해야 ID 를 알 수 있다.

\n\n

코드 차이는 애노테이션 한 줄인데, 이 동작 차이는 어디에도 표시되지 않는다.\nMyBatis 는 SQL 이 XML 에 그대로 보이니 이런 종류의 “조용한 비활성화”가 없다 —\nJPA 로 넘어올 때 가장 조심해야 할 지점이 바로 이 암묵성이라고 느꼈다.

\n

5가지 전략을 같은 조건에서 측정

\n

같은 데이터(Release 1,000 / Track 10,000), 같은 트랜잭션 경계에서 쓰기 방식만 갈아끼웠다.\nTestcontainers MariaDB, 3회 반복 중앙값.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
전략중앙값(ms)처리량(건/초)수행 작업
JPA IDENTITY17,225581순수 INSERT
JPA SEQUENCE (increment 1000)41823,923순수 INSERT
JPA 앱할당 TSID49020,408순수 INSERT
JDBC batchUpdate + UPSERT1,2058,299UPSERT + 사후 SELECT
TSID + 사전 SELECT + UPSERT1,2547,974사전 SELECT + UPSERT
\n

IDENTITY 와 SEQUENCE 의 차이가 41배다. 애노테이션 한 줄의 값이다.

\n

기각된 가설 — 이 표에서 제일 배운 것

\n

측정 전 예측은 “JDBC 직접 제어가 제일 빠를 것”이었다. 결과는 SEQUENCE 의 1/3.

\n

이유를 파 보니 표의 함정이 보였다. 전략마다 수행하는 작업이 다르다.\nJDBC 행은 “재전송 시 UPSERT” 라는 요구사항을 만족하는 비용까지 포함한 수치고,\nSEQUENCE 행은 순수 INSERT 만 한 수치다. 이 표는 “같은 SQL 의 속도 비교”가 아니라\n“각 전략이 만족하는 요구사항의 비용 비교” 였던 것이다.

\n

후속 가설 “사후 SELECT 를 사전 SELECT 로 바꾸면 싸질 것”도 측정으로 기각됐다 —\n이런 조회는 결과셋 크기가 아니라 인덱스 탐색 횟수가 비용을 지배한다.

\n

최종 선택

\n

유통사가 같은 앨범을 정정 재전송하는 요구사항(UPSERT 멱등성)이 있어서\nJDBC batchUpdate + ON DUPLICATE KEY UPDATE 를 선택했다. 최고 속도 전략이 아니라\n요구사항을 가장 싸게 만족하는 전략이다. 순수 신규 적재만 있는 시스템이라면 SEQUENCE 가 맞다.

\n

부수 팁: MariaDB JDBC 는 rewriteBatchedStatements=true 로 multi-value 재작성이 가능한데,\n이때 affected rows 가 SUCCESS_NO_INFO(-2) 로 뭉개질 수 있다.\n반환값에 로직을 걸면 안 되는 이유이며, 이 성질은 뒤의 Kafka 멱등성 글에서 다시 등장한다.

\n

상세: ADR-0001

\n
\n
\n\n
","frontmatter":{"date":"July 24, 2026","title":"음악 스트리밍 파이프라인 만들기 - 02. JPA 배치 insert, IDENTITY가 41배 느린 이유","categories":"Music_Pipeline","author":"shim8934","emoji":"🚀"},"fields":{"slug":"/Music_Pipeline_02/"}},"site":{"siteMetadata":{"siteUrl":"https://shim8934.github.io","comments":{"utterances":{"repo":"Shim8934/shim8934.github.io"}}}}},"pageContext":{"slug":"/Music_Pipeline_01/","nextSlug":"/IT엔지니어를_위한_네트워크_입문_08/","prevSlug":"/Music_Pipeline_02/"}}, "staticQueryHashes": ["1073350324","1956554647","2938748437"]}