본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 서른 여덟번째 날입니다.
서른 일곱번째 날에는 Docker Compose를 사용한 로컬 데이터베이스 리플리카 구성에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 4. 서비스 부하 분산을 위한 분리 시작 >
Ch 1. 데이터베이스의 고가용성 확보와 성능 개선을 위한 리플리카 >
03. 스프링 부트 JPA 멀티 데이터소스 설정을 사용한 읽기 전용 데이터베이스 설정
입니다.
🛠️ 스프링 부트 JPA 멀티 데이터소스 설정 — 읽기 전용(리플리카) DB 적용
- 이번 주제는 쓰기 전용(소스/마스터)와 읽기 전용(리플리카) 데이터베이스를 분리하는 멀티 데이터소스 구성입니다.
- 목표는 @Transactional(readOnly=true) 트랜잭션이 자동으로 리플리카 DB로 라우팅되도록 만드는 것입니다.
🗄️ 1. MySQL 리플리카 구성
- Docker Compose로 MySQL 소스/리플리카 컨테이너 실행
- 초기화 스크립트에서 GTID 기반 복제 설정
- 복제 계정 생성, binlog 및 relaylog 설정
- 리플리카에 read_only=ON 적용
- MySQL Workbench에서 복제 정상 동작 확인
💡 이렇게 하면 쓰기 쿼리는 소스, 읽기 쿼리는 리플리카에서 처리할 준비가 완료됩니다.
🔀 2. RoutingDataSource 구현
- AbstractRoutingDataSource를 상속해 현재 트랜잭션이 읽기 전용인지 여부로 라우팅합니다.
🐌 3. Lazy Connection Proxy 적용
- 문제: 스프링이 엔티티 매니저 초기화 시점에 커넥션을 먼저 잡아버려서 트랜잭션의 readOnly 속성이 적용되지 않는 경우가 발생합니다.
- 해결 방법
- 라우팅 데이터소스를 LazyConnectionDataSourceProxy로 감싸 커넥션 획득을 지연
- 이렇게 하면 트랜잭션 속성이 먼저 적용된 후 커넥션이 생성됩니다.
🚀 4. 커넥션 풀 웜업
- 첫 요청 시 리플리카 풀 초기화로 인한 지연을 방지하기 위해 애플리케이션 시작 시 커넥션 미리 생성합니다.
⚠️ 5. 운영 시 주의점
- 복제 지연(replication lag) 발생 시 데이터 최신성이 떨어질 수 있음
- 민감한 읽기는 반드시 소스 DB를 사용
- 모니터링, 알람, 장애 전환 절차 필수
- JPA 1차 캐시 영향 고려
💡 6. 정리
- 멀티 데이터소스 구성은 단순한 성능 최적화가 아니라 일관성과 가용성을 함께 설계하는 작업입니다.
- 이번 방식(라우팅 + Lazy Proxy + 풀 웜업)은 도입 난이도 대비 효과가 좋아 초기 구축에 적합합니다.
- 추후 운영 데이터에 맞춰 라우팅 정책을 세분화하면 안정성과 성능을 모두 확보할 수 있습니다.
- 멀티 데이터소스는 단순히 “읽기/쓰기 분리”가 아닙니다. 네트워크, DB 복제 구조, 트랜잭션 경계, 장애 복구까지 함께 고려해야 실무에서 안전하게 동작합니다. 이번 예제 패턴은 확장성과 실용성이 뛰어나, 스타트업이나 초기 프로젝트에서 특히 유용하다고 생각합니다.
