Slave

동시 접속자가 증가하면, DB에 전달되는 부하 또한 증가하게 됩니다. 아직 심각한 성능 저하를 경험하지는 못했지만, 사내 서비스에 사용자가 점차 늘어나는 상황에서 단일 DB 구조의 잠재적 문제를 미리 파악해 장애를 방지해야겠다고 판단했습니다. Clustering, Replication, Sharding 등 다양한 선택지 중 해당 프로젝트에 가장 적합한 Replication을 선택하게 되었습니다. 선택한 이유와 Replication을 적용하면서 확인한 성능 개선 결과를 공유하겠습니다. 😣 단일 DB의 한계단일 DB는 모든 쓰기/읽기 요청이 한 곳에 집중되어 트래픽이 증가할 경우 성능 저하를 피할 수 없고, 장애 발생 시 전체 서비스가 중단될 수밖에 없습니다.'그럼 성능을 올리면 되잖아?'라고 생각할 수 ..

🫢 문제 상황Spring Boot에서 Master/Slave 패턴으로 DB 구조를 구현했지만, @Transaction(readOnly = true)로 설정한 메서드가 계속 Master DB(3306)로 접근하는 문제가 발생하였습니다. Slave DB(3307)로 라우팅되어야 하지만 실제로는 읽기 전용 설정이 false로 인식되는 문제가 발생하고 있었습니다. ⚙️ 환경설정DB 설정(application.yml)spring: datasource: master: hikari: driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/bank?serverTimezone=Asia/S..

Master/Slave 패턴이란 ?우리가 서비스를 이용하다 보면 보통 등록, 수정 보다 조회 요청이 많다는 것을 알 수 있습니다. 이때 사용자가 증가함에 따라 해당 요청을 처리하기 위해 DB에 많은 트랜잭션을 처리해야 하는데 이 요청으로 DB서버가 다운되면 서비스를 이용할 수 없게 될 것입니다.Master와 Slave는 이러한 문제를 해결하기 위해 설계된 DB 아키텍처로 Master에서는 등록과 수정, 삭제와 같은 작업을 처리하고, 이를 Slave에 복제고, 조회 요청은 Slave에서 처리하도록 트래픽을 분산합니다. 이로써 만약 Master 서버가 다운 되어도 Slave 서버를 마스터로 승격하여 서비스 복구를 빠르게 할 수 있어 고가용성이 증가됩니다.Master DatabaseMaster DB는 서비스의..