본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 스물 세번째 날입니다.
스물 두번째 날에는 이번 프로젝트에서는 푸시 서버를 페이크로 처리하는 이유에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 4. 서비스 부하 분산을 위한 분리 시작 >
Ch 1. 데이터베이스의 고가용성 확보와 성능 개선을 위한 리플리카 >
01. 왜 리플리카가 필요한가
입니다.
🛠️ 왜 리플리카를 구성하는가?
- MySQL 리플리카를 통한 성능 향상과 가용성 확보
- 서비스 규모가 커지고 트래픽이 증가하면, 단일 DB 인스턴스로는 성능과 안정성을 보장하기 어려워집니다. 이번 포스트에서는 이러한 문제를 해결하기 위한 첫 번째 시도, 바로 MySQL 리플리카 구성의 필요성과 그 이점, 그리고 우리가 어떤 전략을 선택했는지를 정리해보겠습니다.
🧩 지금까지의 구성
- 현재까지는 단일 MySQL 인스턴스를 이용하여 사용자 인증, 채팅, 푸시 알림 등 모든 기능을 처리해왔습니다. 단순한 구조라서 관리가 편리했지만, 점차 읽기/쓰기 부하가 커지고 장애에 대한 리스크도 커지고 있습니다. 따라서 소스(메인) DB와 리플리카(보조) DB를 구성하여 읽기 요청을 분산시키고, 시스템의 가용성을 높이는 구조로 전환합니다.
🔄 리플리카 구성의 주요 목적
✅ 성능 향상
- 읽기/쓰기 분리: 소스 DB는 쓰기 전용, 리플리카는 읽기 전용으로 분리하여 부하를 분산시킵니다.
- 읽기 성능 향상: 특히 조회 빈도가 높은 서비스에서는 큰 효과를 볼 수 있습니다.
✅ 가용성 확보
- 소스 DB가 장애가 나더라도 리플리카에서 읽기 요청은 지속 가능합니다.
- 비록 이번 구성에서는 페일오버 기능(자동 전환) 은 설정하지 않지만, 읽기 유지만으로도 전면 장애를 피할 수 있습니다.
❌ 백업과는 다르다?
- 리플리카를 백업 용도로 착각하기 쉬우나, 실시간 복제를 통해 소스 DB의 잘못된 데이터도 함께 전파될 수 있습니다. 진정한 백업은 스냅샷을 기반으로 시점 복원이 가능해야 하며, 리플리카는 이 용도로 적합하지 않습니다.
⚠️ 일관성과 복잡성
- 리플리카는 비동기 복제가 기본입니다. 이 때문에 최신 데이터를 읽지 못하는 경우가 발생할 수 있습니다.
- 만약 쓰기 직후의 데이터를 읽어야 한다면, 해당 요청은 소스 DB로 보내야 합니다.
- 또한, 설정 복잡도도 증가합니다. 복제 설정, 데이터 지연 처리, 분기 로직 등이 추가됩니다.
💸 비용과 운영 전략
- 물리적으로 인스턴스가 추가되므로 비용 증가는 불가피합니다.
- 이번 프로젝트에서는 1:1 구조, 소스→리플리카 단방향 복제, 리플리카 승격 없음 등의 제한을 두어 설정을 단순화합니다.
- 다만 추후 서비스 확장에 대비해 구성 전략의 유연성을 확보할 필요는 있습니다.
- 서비스 설계 시 "문제를 얼마나 미리 예측하고, 트레이드오프를 이해한 상태에서 선택했는가" 가 매우 중요합니다. 이번 리플리카 구성 역시 단순히 성능 향상만이 목적이 아니라, 신뢰성과 장애 대응력을 확보하기 위한 선택이라는 점에서 큰 의미가 있습니다.
- 무엇보다도 모든 선택에는 대가가 따릅니다. 성능을 얻는 대신 복잡성이 증가하고, 일관성을 완전히 보장하지 못한다는 점을 명확히 이해하고 도입하는 것이 핵심이라고 볼 수 있을 것 같습니다.
