[database] Amazon RDS

DB 서비스 선택 큰 그림은 database-overview. Aurora는 RDS 계열이지만 별도 심화가 크므로 aurora로 분리.

One-Line Summary

Amazon RDS는 관계형 DB(MySQL·PostgreSQL·MariaDB·Oracle·SQL Server·Db2)를 관리형으로 제공한다 — 백업·패치·복구·모니터링을 AWS가 대신한다. 시험 핵심은 Multi-AZ(HA) vs Read Replica(읽기 확장) vs RDS Proxy(연결 관리) vs Blue/Green(안전한 변경) 을 정확히 가르는 것이다.

뭔지 (What / Why)

DB를 EC2에 직접 깔면 백업·패치·failover·복제·모니터링을 전부 손으로 운영해야 한다. RDS는 이 운영 부담을 걷어내고 엔진은 그대로(표준 SQL·기존 앱 호환) 쓰게 해준다.

"기존 앱이 SQL/트랜잭션/관계형 스키마를 요구한다" = RDS(또는 Aurora). RDS가 관리해 주는 건 운영이지, SQL 호환성을 바꾸는 게 아니다.

Abbreviations

약어	풀네임	의미
`RDS`	Relational Database Service	관리형 관계형 DB
`AZ`	Availability Zone	리전 내 독립 가용 영역
`RR`	Read Replica	읽기 전용 복제본
`PITR`	Point-In-Time Recovery	특정 시점 복구
`IOPS`	Input/Output Operations Per Second	초당 I/O 작업 수

스토리지 타입

스토리지	언제
General Purpose SSD (gp3/gp2)	일반 워크로드, 비용/성능 균형(신규 기본)
Provisioned IOPS SSD (io1/io2)	높은 IOPS·낮은 지연이 필요한 I/O 집약 DB

Storage Auto Scaling: 임계치 도달 시 스토리지 자동 확장(용량 부족 장애 예방).

고가용성 — Multi-AZ (빈출)

Multi-AZ DB instance

주 인스턴스를 다른 AZ의 대기(standby)로 동기 복제하고, 장애 시 자동 failover한다.

Primary (AZ-a) ──동기 복제──► Standby (AZ-c)
   장애 발생 → DNS가 standby로 자동 전환 (앱은 같은 엔드포인트 사용)

항목	내용
목적	고가용성·자동 failover
복제	동기
standby 읽기	불가(대기 전용)
읽기 성능 향상	❌

핵심 함정: 일반 Multi-AZ standby는 읽기 트래픽을 처리하지 않는다. 성능이 아니라 장애 대비용이다.

Multi-AZ DB cluster

1 writer + 읽기 가능한 2 standby를 3개 AZ에 배치. HA에 더해 읽기 처리량까지 얻는다(standby가 읽기 가능).

항목	내용
구성	1 writer + 2 readable standby(3 AZ)
읽기	가능
failover	빠름

"Multi-AZ인데 readable standby / 더 빠른 failover / 쓰기 지연 감소" = Multi-AZ DB cluster.

읽기 확장 — Read Replica (빈출)

비동기 복제한 읽기 전용 복제본. 읽기 부하를 분산한다.

항목	내용
목적	읽기 확장(리포팅·조회 offload)
복제	비동기(약간의 지연 가능)
개수	엔진별 최대 5~15개
승격	독립 DB로 promote 가능(수동)
위치	같은 AZ/다른 AZ/다른 리전

Cross-Region Read Replica

다른 리전에 읽기 복제본을 둔다 → ① 리전 DR ② 해당 지역 사용자에게 가까운 읽기 ③ 리전 이전.

"읽기가 많다/리포팅 offload" = Read Replica. "다른 리전 DR·글로벌 읽기" = Cross-Region RR(관계형 글로벌은 Aurora Global Database도 후보).

Multi-AZ vs Read Replica (가장 자주 나오는 구분)

구분	Multi-AZ instance	Multi-AZ cluster	Read Replica
주 목적	HA	HA + 읽기 확장	읽기 확장
복제	동기	준동기	비동기
읽기 처리	❌	✅	✅
failover	자동	자동(빠름)	수동 승격

Multi-AZ=HA, Read Replica=읽기 성능. 단 Multi-AZ cluster의 standby는 읽기 가능.

RDS Proxy (빈출 — Lambda 연결 폭증)

앱과 DB 사이에서 DB 연결을 풀링·재사용하는 완전관리형 프록시.

Lambda(수천 동시 실행) ─► RDS Proxy(연결 풀) ─► RDS/Aurora

문제 상황	RDS Proxy가 맞는 이유
Lambda가 DB 연결을 과도하게 생성(connection storm)	연결 풀링/재사용
짧은 연결이 폭증	재사용으로 부담 감소
failover 시 앱 안정성	연결 유지로 failover 체감 시간 단축

중요: RDS Proxy는 쿼리 결과를 캐시하지 않는다. 데이터 캐시는 ElastiCache, DynamoDB 캐시는 DAX. RDS Proxy는 연결 관리.

RDS Blue/Green Deployment

운영(Blue)과 동기화된 staging(Green) 을 만들어 버전 업그레이드·스키마 변경을 검증한 뒤 1분 이내 switchover로 전환한다.

"DB 변경을 안전하게 테스트하고 짧은 중단으로 전환" = Blue/Green.

백업 & 암호화

항목	내용
자동 백업	PITR 지원, 보존 0~35일
수동 스냅샷	삭제 전까지 보존, 리전·계정 간 복사 가능
저장 위치	내부적으로 S3(관리형)
암호화	KMS(at-rest) — 생성 시 활성화(기존 미암호화는 스냅샷 복사로 암호화), 전송 중 TLS

함정: "미암호화 RDS를 암호화하라" → 직접 토글 불가 → 암호화 스냅샷으로 복원. 자세한 키는 security/kms.

실무 활용 사례

HA 운영 DB: Multi-AZ instance로 AZ 장애 자동 failover.
읽기 폭증 리포팅: Read Replica 여러 개로 조회 offload.
글로벌 DR: Cross-Region Read Replica로 다른 리전 대비.
서버리스 백엔드: Lambda + RDS Proxy로 connection storm 방지.
버전 업그레이드: Blue/Green으로 무중단에 가깝게 전환.

Common Wrong Directions

오답 방향	왜 부족한가
Multi-AZ를 읽기 성능용으로	일반 standby는 읽기 안 함 → Read Replica
Read Replica를 HA 정답으로	주 목적은 읽기 확장 → HA는 Multi-AZ
RDS Proxy를 캐시로	연결 풀링 → 캐시는 ElastiCache
미암호화 DB를 그 자리에서 암호화	스냅샷 복사로 암호화본 생성
글로벌 저지연 관계형에 단일 리전 RDS	Cross-Region RR / Aurora Global Database

Exam Triggers

문제에서 이런 표현이 나오면	떠올릴 것
"high availability / automatic failover / standby"	Multi-AZ instance
"readable standby / faster failover"	Multi-AZ cluster
"offload read traffic / reporting"	Read Replica
"cross-region DR / geo-local reads"	Cross-Region Read Replica
"too many connections from Lambda"	RDS Proxy
"safe upgrade with minimal downtime"	Blue/Green
"point-in-time restore"	자동 백업(PITR)
"encrypt an existing unencrypted DB"	암호화 스냅샷 복원

Memory Sentence

RDS는 관계형 DB를 관리형으로 제공한다. HA는 Multi-AZ(동기 standby·자동 failover, 읽기 불가), 읽기 확장은 Read Replica(비동기·읽기 전용), 글로벌/DR은 Cross-Region RR, 연결 폭증은 RDS Proxy, 안전한 변경은 Blue/Green. 백업은 PITR·스냅샷, 암호화는 KMS(생성 시, 기존은 스냅샷 복사).