SW BBANG K

프로덕션 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가 자동으로 쿼리를 라우팅해주지 않는다. 읽기/쓰기 분리는 애플리케이션 레벨 또는 프록시 레...

프로덕션 RDS 인스턴스를 처음 설정할 때 Multi-AZ 옵션을 보고 '이거 켜면 성능도 좋아지겠지?'라고 생각했다면, 그 가정이 장애 대응 중에 당신을 배신할 수 있다. Multi-AZ는 고가용성과 페일오버 를 위한 기능이지, 읽기 성능 향상을 위한 기능이 아니다. TL;DR: RDS Multi-AZ 핵심 요약 항목 Multi-AZ 동작 목적 고가용성 및 자동 페일오버 스탠바이 인스턴스 직접 접근 불가 (읽기/쓰기 모두 차단) 읽기 성능 향상 없음 — 읽기 스케일아웃은 Read Replica 사용 쓰기 성능 영향 동기 복제로 인한 소폭 지연 가능 페일오버 소요 시간 일반적으로 60~120초 (공식 보장 없음) 데이터 내구성 동기 복제로 RPO ≈ 0 자동 백업 스탠바이에서 수행 (프라이머리 I/O 영향 감소) RDS Multi-AZ가 실제로 하는 일 Multi-AZ를 활성화하면 AWS는 다른 가용 영역(AZ)에 스탠바이 인스턴스를 자동으로 프로비저닝한다. 프라이머리 인스턴스에 쓰기가 발생하면 Amazon RDS는 동기식 블록 수준 복제를 통해 스탠바이에 데이터를 미러링한다. 애플리케이션은 항상 프라이머리 엔드포인트 하나만 바라본다. 여기서 핵심은 동기(synchronous) 복제 라는 점이다. 프라이머리가 트랜잭션을 커밋하기 전에 스탠바이에도 기록이 완료되어야 한다. 이 구조 덕분에 페일오버 시 데이터 손실이 없지만, 반대로 스탠바이는 항상 '대기 중'이지 '서비스 중'이 아니다. graph LR App["애플리케이션"] -->|"단일 엔드포인트 (DNS)"| Primary["프라이머리 인스턴스 AZ-A"] Primary -->|"동기 ...