AWS DVA-C02 #25 RDS AZ vs Replicas

#개발자의도구들 #AWS시험 #AWSDVA-C02 #DVA-c02문제 #DVA-c02덤프

​

참고: ExamPotic Disscussion

문제 찾는법 : 여기 최하단

요구사항 분석

• 환경: On-prem → Amazon RDS for MySQL
• 워크로드: Read-heavy (읽기 쿼리 비중 높음)
• 목표: 최소한의 현재/미래 개발 노력으로 읽기 성능 최적화
• 전제:
• 읽기 부하를 분산할 수 있어야 함
• 관리/운영 오버헤드 낮아야 함
• 코드 수정이 있더라도 복잡하면 안 됨

보기 분석

A. Multi-AZ + 연결 수(pool) 증가

• Multi-AZ: 고가용성을 위한 동기식 복제 → 읽기 트래픽 분산 X
• Secondary(Standby)는 Failover 전용으로 쓰이며, 직접 쿼리 불가
• Connection pool 크기 증가는 동시 처리량은 늘릴 수 있지만 쿼리 자체 성능을 올려주지 않음

​

❌ 읽기 성능 개선과 무관

​

B. Multi-AZ + Secondary 읽기

​

❌ Multi-AZ의 Secondary는 읽기 전용으로 접근 불가

👉 AWS에서 이걸 직접 읽기 노드로 쓰게 허용하지 않는다.

​

C. RDS Read Replica + 코드에서 읽기 전용 엔드포인트 사용

✅ Read Replica : 비동기식 복제, 읽기 전용 노드: 읽기 부하 분산 가능

• 읽기 쿼리를 Replicas의 엔드포인트로 보내도록 변경하면된다.

​

D. 오픈소스 복제 + EC2에 MySQL

❌ 오버헤드 너무 높다.

차이 정리

Multi-AZ

• 목적: 고가용성(HA)
• 복제: 동기식
• Secondary: Standby 인스턴스 (Failover 시 Primary로 승격)
• 읽기 부하 분산: ❌ (읽기 쿼리 불가)
• 사용 예: DB 장애 대비, 자동 Failover, 데이터 내구성 확보

​

​

​

Read Replica

• 목적: 읽기 부하 분산, 보고서/분석 쿼리 분리
• 복제: 비동기식
• Secondary: Read-only 인스턴스
• 읽기 부하 분산: ✅ (읽기 전용 트래픽 처리)
• 사용 예: Read-heavy 애플리케이션, 장기 실행 쿼리 분리, 보고서 생성