RDS 읽기 전용 복제본으로 SELECT 부하 분산하기 — Multi-AZ와의 차이점까지
프로덕션 RDS 인스턴스의 CPU가 SELECT 쿼리 때문에 80%를 넘어서는 순간, 대부분의 엔지니어는 인스턴스를 스케일업하거나 캐시 레이어를 먼저 떠올린다. 하지만 읽기 부하가 명확히 분리 가능한 구조라면, RDS 읽기 전용 복제본(Read Replica)이 가장 직접적인 해결책이다. 문제는 Read Replica와 Multi-AZ를 혼동해서 잘못된 선택을 하는 경우가 생각보다 많다는 점이다. TL;DR — Read Replica vs. Multi-AZ 핵심 비교 항목 Read Replica Multi-AZ 주목적 읽기 부하 분산 (성능) 자동 장애 조치 (가용성) 복제 방식 비동기 복제 동기 복제 엔드포인트 별도 엔드포인트 제공 단일 엔드포인트 (자동 전환) 읽기 트래픽 수신 가능 (직접 연결) 불가 (Standby는 읽기 불가) 독립 승격 가능 (독립 DB로 승격) 자동 장애 조치만 지원 리전 간 배포 가능 (Cross-Region) 단일 리전 내 다중 AZ 비용 구조 Replica 인스턴스 비용 추가 Standby 인스턴스 비용 추가 RDS 읽기 전용 복제본이 동작하는 방식 Read Replica는 소스 DB 인스턴스의 변경 사항을 비동기적으로 수신한다. MySQL과 MariaDB는 바이너리 로그(binlog) 기반 복제를 사용하고, PostgreSQL은 물리적 복제 슬롯(WAL 스트리밍)을 사용한다. 이 비동기 특성 때문에 Replica에는 항상 약간의 복제 지연(replication lag)이 존재할 수 있다 — 최신 데이터가 반드시 필요한 쿼리에는 적합하지 않다. 애플리케이션은 소스 인스턴스의 엔드포인트와 별개로 Replica 전용 엔드포인트에 직접 연결해야 한다. RDS가 자동으로 쿼리를 라우팅해주지 않는다. 읽기/쓰기 분리는 애플리케이션 레벨 또는 프록시 레...