RDS Multi-AZ vs Read Replica: 언제 어떤 것을 선택해야 할까?
Multi-AZ는 고가용성(장애 조치)용, Read Replica는 읽기 성능 확장용입니다. SAA-C03 시험 필수 토픽인 두 기능의 차이점과 선택 기준을 정리합니다.
관련 시험 도메인
- Domain 2: Design Resilient Architectures
핵심 요약 (BLUF)
Multi-AZ는 고가용성(장애 조치)을 위한 동기식 복제이고, Read Replica는 읽기 성능 확장을 위한 비동기식 복제입니다. 프로덕션 환경에서는 Multi-AZ로 가용성을 확보하고, 읽기 부하가 높으면 Read Replica를 추가하세요. 둘은 상호 보완적입니다.
시험 팁
시험 핵심: Multi-AZ = 고가용성 + 자동 장애 조치 + 동기식, Read Replica = 읽기 확장 + 수동 승격 + 비동기식
Multi-AZ와 Read Replica 한눈에 비교
| 비교 항목 | Multi-AZ | Read Replica |
|---|---|---|
| 주요 목적 | 고가용성/장애 조치 | 읽기 성능 확장 |
| 복제 방식 | 동기식 | 비동기식 |
| 읽기 트래픽 처리 | ❌ 불가 | ✅ 가능 |
| 자동 장애 조치 | ✅ 지원 | ❌ 수동 승격 |
| 리전 | 동일 리전만 | 동일/다른 리전 |
| 개수 제한 | 1-2개 스탠바이 | 최대 15개 |
| 데이터 지연 | 없음 (동기식) | 있음 (비동기식) |
| 추가 비용 | 스탠바이 인스턴스 비용 | 복제본 인스턴스 비용 |
Multi-AZ 배포
Multi-AZ란?
Multi-AZ는 다른 가용 영역(AZ)에 동기식 스탠바이 복제본을 자동으로 유지하는 고가용성 기능입니다. 기본 인스턴스 장애 시 자동으로 스탠바이로 장애 조치됩니다.
Multi-AZ 구조 (Instance 배포):
AZ-a AZ-b
┌──────────────────┐ ┌──────────────────┐
│ Primary DB │ ──────> │ Standby DB │
│ (읽기/쓰기) │ 동기식 │ (대기 전용) │
└──────────────────┘ 복제 └──────────────────┘
↑
애플리케이션 연결
(단일 DNS 엔드포인트)
Multi-AZ 배포 유형
1. Multi-AZ DB Instance (1개 스탠바이)
- 프라이머리 + 1개 스탠바이
- 스탠바이는 읽기 트래픽 미지원
- 장애 조치 시간: 1-2분
2. Multi-AZ DB Cluster (2개 리더) - 신규
- 라이터 + 2개 리더 (3개 AZ 분산)
- 리더가 읽기 트래픽 처리
- 장애 조치 시간: ~35초
- 지원: MySQL, PostgreSQL
자동 장애 조치 트리거
다음 상황에서 자동으로 스탠바이로 장애 조치:
- 기본 인스턴스 장애
- 가용 영역 장애
- 인스턴스 유형 변경
- DB 엔진 패치
- 수동 장애 조치 (재부팅 시 선택)
장애 조치 프로세스
1. 기본 인스턴스 장애 감지
↓
2. DNS 레코드 업데이트 (동일 엔드포인트 유지)
↓
3. 스탠바이가 새 기본 인스턴스로 승격
↓
4. 애플리케이션 자동 재연결 (DNS 변경 없음)
소요 시간: RDS 1-2분, Aurora ~30초
시험 팁
시험 포인트: Multi-AZ 장애 조치 시 DNS 엔드포인트는 변경되지 않습니다. 애플리케이션 연결 문자열 변경 불필요.
Multi-AZ 적합한 사용 사례
- 프로덕션 워크로드: 다운타임 최소화 필수
- 규정 준수: 데이터 내구성 요구
- 자동 유지보수: 패치 시 다운타임 최소화
- AZ 장애 대비: 단일 AZ 장애로부터 보호
Read Replica (읽기 전용 복제본)
Read Replica란?
Read Replica는 비동기식으로 데이터를 복제하여 읽기 트래픽을 분산하는 기능입니다. 원본 DB의 읽기 부하를 줄이고 성능을 향상시킵니다.
Read Replica 구조:
┌──────────────────┐
│ Primary DB │───────────────────────────────┐
│ (읽기/쓰기) │ 비동기식 복제 │
└──────────────────┘ │
↑ ↓ ↓
쓰기 트래픽 ┌─────────────┐ ┌─────────────┐
│ Read Replica │ │ Read Replica │
│ (읽기 전용) │ │ (읽기 전용) │
└─────────────┘ └─────────────┘
↑ ↑
읽기 트래픽 읽기 트래픽
Read Replica 핵심 특징
| 특징 | 설명 |
|---|---|
| 최대 개수 | RDS 5개, Aurora 15개 |
| 리전 | 동일 리전 / 크로스 리전 |
| 복제 지연 | 밀리초~초 단위 (비동기) |
| 별도 엔드포인트 | 각 복제본마다 고유 DNS |
| 승격 가능 | 독립 DB로 승격 가능 |
Read Replica 활용 패턴
1. 읽기 분산 (Read Scaling)
Primary: INSERT, UPDATE, DELETE (쓰기)
Replica: SELECT (읽기) - 보고서, 분석, 검색
2. 크로스 리전 복제
서울 리전 (Primary) → 버지니아 리전 (Replica)
- 글로벌 사용자 지연 시간 감소
- 재해 복구 준비
3. 독립 DB로 승격
테스트 환경 구축:
Primary → Read Replica 생성 → 승격 → 독립 DB (테스트용)
Read Replica 승격
Read Replica를 독립적인 DB 인스턴스로 승격할 수 있습니다:
- 승격 후 더 이상 복제되지 않음
- 읽기/쓰기 모두 가능한 독립 DB
- 재해 복구 시 수동 승격으로 활용
승격 시나리오:
1. 원본 DB 장애 발생
2. Read Replica를 독립 DB로 수동 승격
3. 애플리케이션 연결 문자열 변경 (새 엔드포인트)
4. 새 DB로 서비스 재개
시험 팁
주의: Read Replica 승격은 수동 작업이며, 승격 후 엔드포인트가 변경됩니다. Multi-AZ 자동 장애 조치와 다릅니다.
Multi-AZ vs Read Replica 선택 기준
요구사항별 선택
| 요구사항 | 선택 |
|---|---|
| 자동 장애 조치 필요 | Multi-AZ |
| 읽기 성능 확장 필요 | Read Replica |
| 다운타임 최소화 | Multi-AZ |
| 보고서/분석 쿼리 분리 | Read Replica |
| 다른 리전에 복제 | Read Replica |
| 데이터 손실 최소화 | Multi-AZ (동기식) |
조합 사용 (권장)
프로덕션 환경에서는 둘을 함께 사용하는 것이 일반적입니다:
권장 아키텍처:
Multi-AZ (고가용성)
┌───────────────────────┐
│ │
AZ-a │ AZ-b │
┌─────────────┐ ┌─────────────┐ │
│ Primary │→ │ Standby │ │
│ (R/W) │ │ (장애조치) │ │
└─────────────┘ └─────────────┘ │
│ │
└───────────────────────┘
│
│ 비동기 복제
↓
┌─────────────┐ ┌─────────────┐
│ Read Replica│ │ Read Replica│
│ (읽기 전용) │ │ (읽기 전용) │
└─────────────┘ └─────────────┘
AZ-a AZ-c
Read Replica (읽기 확장)
시나리오별 솔루션
시나리오 1: 프로덕션 DB 고가용성
요구사항: 24/7 운영, 다운타임 최소화
해결: Multi-AZ 배포
이유: 자동 장애 조치로 1-2분 내 복구
시나리오 2: 읽기 부하 분산
요구사항: 대량의 SELECT 쿼리, 보고서 생성
해결: Read Replica 추가
이유: 읽기 트래픽을 복제본으로 분산
시나리오 3: 글로벌 사용자 지원
요구사항: 미국, 유럽 사용자 지연 시간 감소
해결: 크로스 리전 Read Replica
이유: 각 리전의 복제본에서 읽기 제공
시나리오 4: 재해 복구 (DR)
요구사항: 리전 장애 시 복구 방안
해결: 크로스 리전 Read Replica + 수동 승격
이유: 원본 리전 장애 시 다른 리전의 복제본 승격
시나리오 5: 분석 쿼리 분리
요구사항: OLTP 성능 영향 없이 분석 쿼리 실행
해결: Read Replica에서 분석 쿼리 실행
이유: 원본 DB 성능에 영향 없음
Aurora의 Read Replica
Aurora는 일반 RDS와 다른 방식으로 복제를 처리합니다:
Aurora vs RDS Read Replica
| 항목 | RDS Read Replica | Aurora Read Replica |
|---|---|---|
| 복제 방식 | 로그 기반 비동기 | 공유 스토리지 |
| 복제 지연 | 초~분 | 밀리초 |
| 최대 개수 | 5개 | 15개 |
| 자동 장애 조치 | ❌ | ✅ (Aurora 클러스터) |
| 엔드포인트 | 개별 엔드포인트 | 리더 엔드포인트 (자동 분산) |
Aurora 클러스터 엔드포인트
Aurora 엔드포인트:
1. 클러스터 엔드포인트 (Writer)
→ 쓰기 작업용, 현재 라이터로 연결
2. 리더 엔드포인트
→ 읽기 작업용, Read Replica 간 자동 로드밸런싱
3. 인스턴스 엔드포인트
→ 특정 인스턴스 직접 연결
시험 팁
시험 포인트: Aurora Read Replica는 자동 장애 조치 지원. 라이터 장애 시 Read Replica 중 하나가 자동으로 라이터로 승격됩니다 (~30초).
SAA-C03 시험 출제 포인트
- ✅ Multi-AZ 목적: 고가용성, 자동 장애 조치 (읽기 확장 X)
- ✅ Read Replica 목적: 읽기 성능 확장, 수동 승격
- ✅ 복제 방식: Multi-AZ = 동기식, Read Replica = 비동기식
- ✅ 장애 조치: Multi-AZ = 자동 (DNS 유지), Read Replica = 수동 (엔드포인트 변경)
- ✅ 크로스 리전: Read Replica만 다른 리전 지원
- ✅ Aurora: Read Replica도 자동 장애 조치 지원
시험 팁
시험 문제 예시: "회사는 RDS MySQL 데이터베이스를 운영 중입니다. 월간 보고서 생성 쿼리가 트랜잭션 성능에 영향을 주고 있습니다. 가장 비용 효율적인 솔루션은?" → 정답: Read Replica 생성 후 보고서 쿼리 실행 (Multi-AZ는 읽기 분산 미지원)
자주 묻는 질문 (FAQ)
Q: Multi-AZ의 스탠바이로 읽기 트래픽을 보낼 수 있나요?
아니요. Multi-AZ DB Instance의 스탠바이는 장애 조치 전용이며, 직접 연결할 수 없습니다. 읽기 트래픽 분산이 필요하면 Read Replica를 사용하세요. 단, Multi-AZ DB Cluster는 리더 인스턴스가 읽기 트래픽을 처리합니다.
Q: Read Replica에도 Multi-AZ를 설정할 수 있나요?
네. Read Replica 자체를 Multi-AZ로 구성하여 복제본의 가용성을 높일 수 있습니다. 크로스 리전 Read Replica의 재해 복구 시나리오에 유용합니다.
Q: Multi-AZ 장애 조치 시 데이터 손실이 있나요?
없습니다. Multi-AZ는 동기식 복제이므로 스탠바이에 항상 최신 데이터가 있습니다. 그러나 장애 조치 중 진행 중인 트랜잭션은 롤백될 수 있습니다.
Q: Read Replica의 복제 지연(Replication Lag)은 얼마나 되나요?
일반적으로 밀리초에서 수 초입니다. 네트워크 대역폭, 쓰기 부하, 복제본 인스턴스 성능에 따라 달라집니다. CloudWatch의 ReplicaLag 메트릭으로 모니터링하세요.
Q: 크로스 리전 Read Replica의 비용은?
데이터 전송 비용이 발생합니다. 리전 간 데이터 복제에 대해 아웃바운드 데이터 전송 요금이 부과됩니다. 동일 리전 내 복제는 무료입니다.
Q: Read Replica를 승격하면 복제가 중단되나요?
네. 승격된 인스턴스는 더 이상 원본 DB와 복제 관계가 없는 독립적인 DB가 됩니다. 다시 복제를 설정하려면 새 Read Replica를 생성해야 합니다.
관련 글
- Aurora vs RDS: 어떤 것을 선택해야 할까?
- DynamoDB 글로벌 테이블
- DR 전략 (Backup/Restore, Pilot Light, Warm Standby, Active-Active)