RDS와 Aurora: 고가용성, 확장, 백업 설계

RDS의 역할

Amazon RDS는 관계형 데이터베이스의 프로비저닝, 패치, 백업, 장애 조치 같은 운영 작업을 AWS가 관리하는 서비스다. 애플리케이션은 SQL과 데이터 모델에 집중할 수 있지만, 스키마와 쿼리 튜닝, 용량 계획은 여전히 사용자의 책임이다.

지원 엔진에는 MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server, IBM Db2가 있으며, Amazon Aurora는 MySQL 또는 PostgreSQL 호환 엔진을 제공한다.

RDS Custom

RDS Custom은 운영체제와 데이터베이스 환경에 더 깊은 제어가 필요한 워크로드를 위한 옵션이다. 일반 RDS보다 관리 책임이 커지므로, 패키지·설정에 직접 접근해야 하는 레거시 또는 벤더 애플리케이션인지 먼저 확인한다.

Multi-AZ와 읽기 전용 복제본

둘 다 복제를 사용하지만 목적이 다르다.

구분	Multi-AZ	Read Replica
주목적	고가용성과 장애 조치	읽기 성능 확장
복제	일반적으로 동기식	비동기식
애플리케이션 읽기	배포 방식에 따라 다름	읽기 엔드포인트로 직접 사용
장애 시	관리형 자동 장애 조치	승격은 별도 결정
리전	같은 리전의 여러 AZ	같은 리전 또는 교차 리전 지원 가능

Multi-AZ DB instance와 DB cluster

Multi-AZ DB instance는 기본 인스턴스와 다른 AZ의 대기 복제본으로 구성된다. 대기 복제본은 읽기 트래픽에 사용하지 않으며, 장애 시 동일한 DB 엔드포인트가 새 기본 인스턴스를 가리킨다.
Multi-AZ DB cluster는 3개 AZ에 writer 1개와 reader 역할도 수행할 수 있는 readable standby 2개를 둔다. 쓰기 가용성과 읽기 확장을 함께 개선한다.

따라서 “Multi-AZ의 standby는 항상 읽을 수 없다”라고 외우면 안 된다. 어떤 배포 옵션인지 구분해야 한다.

스토리지와 확장

RDS 스토리지는 General Purpose SSD와 Provisioned IOPS SSD 등을 워크로드에 맞게 선택한다. Storage Auto Scaling은 임계값에 도달하면 설정한 최대치까지 저장 공간을 늘려 주지만 자동으로 줄이지는 않는다.

읽기 병목: 읽기 전용 복제본, 캐시, 쿼리·인덱스 최적화
쓰기·CPU 병목: 더 큰 인스턴스, 엔진별 샤딩 또는 애플리케이션 구조 변경
연결 폭증: RDS Proxy로 연결 풀링
반복 조회: ElastiCache로 결과·세션 캐싱

RDS Proxy

RDS Proxy는 애플리케이션과 DB 사이에서 연결을 풀링하고 재사용한다. Lambda처럼 짧은 실행이 대량으로 발생하거나 DB 연결 수가 급증하는 환경에서 특히 유용하다.

데이터베이스 장애 조치 시 애플리케이션 연결 복구 시간을 줄이는 데 도움을 준다.
자격 증명은 AWS Secrets Manager와 연동할 수 있고, 클라이언트 인증에 IAM DB 인증도 구성할 수 있다.
프록시가 성능 문제를 모두 해결하지는 않는다. 장시간 트랜잭션, 세션 상태 고정, 연결 핀닝 여부를 함께 확인한다.

Aurora

Aurora는 MySQL·PostgreSQL 호환 관계형 데이터베이스다. 컴퓨팅 인스턴스와 분산 스토리지를 분리하고, 여러 AZ에 걸쳐 저장 복사본을 유지한다.

클러스터 볼륨은 자동으로 확장되며 여러 AZ에 데이터를 복제한다.
Writer endpoint는 현재 쓰기 인스턴스를 가리킨다.
Reader endpoint는 읽기 복제본 사이에서 연결을 분산한다.
읽기 복제본을 추가해 읽기 처리량과 장애 조치 대상을 확보할 수 있다.
Aurora Serverless v2는 세밀한 용량 단위로 자동 확장하며 변동이 큰 워크로드에 적합하다.

Aurora Global Database

하나의 기본 리전과 여러 보조 리전으로 구성해 전 세계 읽기 지연을 줄이고 리전 재해 복구를 지원한다. 리전 간 복제는 전용 인프라를 사용하지만 비동기식이므로 RPO가 0이라고 가정하지 않는다. 장애 조치 방식에 따라 일반적으로 RTO는 분 단위, RPO는 초 단위 목표로 설계한다.

백업과 복구

자동 백업: 설정한 보존 기간 안에서 특정 시점 복구(PITR)를 제공한다.
수동 스냅샷: 직접 삭제할 때까지 유지되며 장기 보관이나 복제에 적합하다.
복구는 기존 DB를 되감는 방식이 아니라 새 DB 인스턴스 또는 클러스터를 생성한다.
교차 리전·교차 계정 복사에서는 스냅샷 권한과 KMS 키 정책을 함께 확인한다.

백업 보유 여부와 실제 복구 가능 여부는 다르다. 목표 RPO/RTO에 맞춰 복구 훈련과 애플리케이션 엔드포인트 전환까지 검증해야 한다.

보안 설계

DB를 프라이빗 서브넷에 두고, 애플리케이션 보안 그룹만 DB 포트에 접근하도록 제한한다.
전송 중 암호화에는 TLS를 사용하고 인증서 검증을 활성화한다.
저장 데이터 암호화는 KMS와 통합되며 데이터, 로그, 백업, 스냅샷, 읽기 복제본에 적용된다.
IAM DB 인증을 지원하는 엔진에서는 단기 토큰을 사용할 수 있다.
Secrets Manager로 비밀번호 저장과 회전을 자동화한다.
CloudWatch, Enhanced Monitoring, Performance Insights, 엔진 로그로 운영 상태를 관찰한다.

암호화 여부와 KMS 키는 생성 전에 계획하는 것이 안전하다. 직접 변경이 지원되지 않는 구성은 암호화된 스냅샷 복사 후 새 DB로 복원하는 마이그레이션이 필요할 수 있다.

RDS와 ElastiCache

ElastiCache는 Redis/Valkey 또는 Memcached 기반 인메모리 캐시다. RDS를 대체하는 영구 관계형 DB가 아니라, 반복 읽기와 세션·임시 데이터를 빠르게 처리해 DB 부하를 줄이는 계층이다. 캐시 무효화, TTL, 장애 시 원본 DB로 돌아가는 동작을 설계해야 한다.

선택 체크리스트

가용성이 목표인가, 읽기 확장이 목표인가?
엔진 호환성과 운영 제어 수준은 어디까지 필요한가?
연결 수가 병목이라면 RDS Proxy가 적합한가?
리전 장애 시 허용 가능한 RPO/RTO는 얼마인가?
백업 복원과 DNS·애플리케이션 전환을 실제로 시험했는가?