LLM WikiAccess-protected knowledge portal

WIKI

AWS RDS와 Aurora 심화: Multi-AZ, 읽기 복제본, Aurora 스토리지 레이어

RDS와 Aurora는 다른 제품이다 AWS에서 "관리형 MySQL"을 쓴다고 하면 두 선택지가 있다. Amazon RDS for MySQL 과 Amazon Aurora MySQL 호환 버전 이다. 이름도 비슷하고 SQL도 같은데 왜 다른 제품인가. RDS는 기존 MySQL 엔진을 EC2 위에서 관리해주는 서비스다. 패치·백업·페일오버를 자동화했지만, 스토리지 레이어는 기존 MySQL의 그것 그대로다. Aurora는 스토리지

경로human/study/content/cloud-native-databases/02-aws-rds-aurora-multiaz-replicas-storage.md
카테고리Study
태그#aurora #infra #multiaz #mysql #rds #replicas #storage #study

RDS와 Aurora는 다른 제품이다

AWS에서 "관리형 MySQL"을 쓴다고 하면 두 선택지가 있다. Amazon RDS for MySQL과 Amazon Aurora MySQL 호환 버전이다. 이름도 비슷하고 SQL도 같은데 왜 다른 제품인가.

RDS는 기존 MySQL 엔진을 EC2 위에서 관리해주는 서비스다. 패치·백업·페일오버를 자동화했지만, 스토리지 레이어는 기존 MySQL의 그것 그대로다.

Aurora는 스토리지 레이어 자체를 AWS가 완전히 재설계한 클라우드 네이티브 DB 엔진이다. MySQL/PostgreSQL과 SQL·드라이버 호환성은 유지하면서, 내부적으로는 전혀 다른 분산 스토리지 위에서 동작한다. 이 차이가 페일오버 속도, 읽기 확장성, 내구성에서 실질적 차이를 만든다.

Aurora 클러스터 스토리지 vs 표준 RDS 표준 RDS (MySQL/PostgreSQL) Primary Standby (Multi-AZ) 동기복제 Primary EBS Volume Standby EBS Volume 페일오버 시: DNS 전환 1~2분 Standby: 읽기 불가, 대기만 쓰기: 페이지 단위 복제 복제 lag: 수초~수십초 가능 Aurora 클러스터 Writer Reader 1 Reader N 최대 15개 Reader — 모두 동일 스토리지 공유 공유 클러스터 볼륨 (10 GB 세그먼트 × 6-way 복제 × 3 AZ) AZ-a seg ×2 노드 2개 AZ-b seg ×2 노드 2개 AZ-c seg ×2 노드 2개 redo log만 쿼럼 쓰기: 6개 중 4개 확인 후 commit 페이지 쓰기 없음: redo log record만 전송 페일오버: 30초 미만, 읽기 Reader가 승격 복제 lag: 일반적으로 10ms 미만 스토리지 자동 확장: 10GB 단위, 최대 128TiB
Aurora 스토리지 vs 표준 RDS 스토리지 비교

Aurora 스토리지 레이어 심화

Aurora의 가장 큰 차별점은 스토리지 레이어다. 이 부분을 이해해야 Aurora의 HA와 성능이 어디서 오는지 알 수 있다.

클러스터 볼륨: 6-way 복제

Aurora는 데이터를 저장할 때 3개 AZ 각각에 2개의 스토리지 노드를 배치해 총 6개에 복제한다. 이 6개 노드의 집합을 클러스터 볼륨(cluster volume)이라 부른다.

볼륨은 10GB 세그먼트 단위로 분할된다. 각 세그먼트는 보호 그룹(protection group)으로 독립적으로 관리된다. 세그먼트 단위이기 때문에 하나의 세그먼트에 장애가 나도 영향 범위가 10GB로 제한되고, 복구도 10GB 단위로 빠르게 처리할 수 있다.

redo log만 전송한다

표준 MySQL에서 쓰기 작업이 발생하면 데이터 페이지(16KB)가 복제되어 전송된다. Aurora는 다르다. redo log record만 네트워크를 통해 스토리지 노드에 전송한다. 데이터 페이지 변환(log → page application)은 스토리지 노드에서 처리한다.

이 설계의 효과는 두 가지다.

  1. 네트워크 트래픽 대폭 감소 — redo log는 변경된 바이트만 담기 때문에 페이지 전체를 보내는 것보다 수배~수십 배 작다.
  2. 복구 시간 단축 — 장애 후 재시작 시 redo log를 재적용할 필요가 없다. 스토리지 레이어가 이미 최신 상태다.

쿼럼 쓰기: 4/6

Aurora는 6개 스토리지 노드 중 4개에서 확인을 받아야 쓰기를 완료로 처리한다. 이 4/6 쿼럼(quorum) 덕분에 AZ 하나가 통째로 내려가도(2개 노드 손실) 여전히 4개 노드가 살아있어 쓰기가 계속된다.

쿼럼 내구성 분석:
- 6개 중 2개 손실 → 쓰기 가능 (4/6 충족), 읽기 가능 (3/6 충족)
- 6개 중 3개 손실 → 쓰기 불가 (4/6 미충족), 읽기 가능
- AZ 하나 장애 = 2개 노드 손실 → 쓰기 계속 가능

스토리지 자동 확장

클러스터 볼륨은 10GB 단위로 자동 확장되며, 최대 128TiB까지 늘어난다. 사용자가 스토리지 크기를 미리 지정할 필요가 없다. 줄어들지는 않는다는 점은 운영 시 주의사항이다 — 임시 대용량 작업(bulk insert, 백업 복원) 후에도 스토리지는 그 크기를 유지한다.

Multi-AZ: Instance 방식 vs Cluster 방식

RDS에는 고가용성을 위한 두 가지 다른 Multi-AZ 방식이 있다. 이름이 비슷해서 혼동하기 쉽다.

Multi-AZ DB Instance (기존 방식)

Multi-AZ DB Cluster (신규 방식, MySQL 8.0+, PostgreSQL 13+)

Multi-AZ Cluster는 최신 기능이다. 읽기 부하를 Standby로 일부 분산할 수 있고 페일오버가 빠르다는 장점이 있지만, 3 인스턴스 비용이 발생한다.

사용 시 고려:
- 단순 HA가 목적이면 Multi-AZ Instance (저렴)
- 읽기 분산 + 빠른 페일오버가 필요하면 Multi-AZ Cluster 또는 Aurora
- 복잡한 읽기 확장이 필요하면 Aurora (최대 15 Reader)

Read Replica: RDS vs Aurora

읽기 복제본도 두 서비스 간에 동작 방식이 다르다.

RDS Read Replica

Aurora Read Replica (Aurora Replica)

Aurora Replica가 빠른 이유는 단순하다. 데이터 복제가 없기 때문이다. Writer가 redo log를 스토리지 레이어에 쓰면, 모든 Reader가 같은 스토리지를 바라보므로 즉시 최신 데이터를 볼 수 있다.

Aurora Serverless v2

Aurora Serverless v2는 Aurora 프로비저닝된 인스턴스 타입 대신, 워크로드에 따라 컴퓨팅 용량이 자동으로 늘고 줄어드는 옵션이다.

ACU (Aurora Capacity Unit)

용량 단위는 ACU다. 1 ACU ≈ 2 GiB 메모리 + 비례하는 CPU + 네트워크.

설정 예:
min ACU: 0.5  (거의 idle 상태까지 축소)
max ACU: 128  (피크 시 최대 256 GiB 메모리까지 확장)

2024년 11월부터 최솟값을 0 ACU로 설정하는 scale-to-zero가 지원된다. 데이터베이스 활동이 없으면 컴퓨팅 비용이 완전히 0이 된다. 다만 재시작에 최대 15초가 소요된다.

최댓값은 기존 128 ACU에서 256 ACU(약 512 GiB 메모리)로 확장됐다.

Serverless v2 vs 프로비저닝 선택 기준

Serverless v2가 경제적인 경우:
- 평균 사용률이 피크 대비 60% 미만
- 개발·스테이징 환경 (야간 축소)
- 트래픽이 불규칙한 SaaS 테넌트 DB

프로비저닝이 경제적인 경우:
- 평균 사용률이 피크 대비 70% 이상
- Reserved Instance(1~3년)로 최대 72% 절약 가능
- 예측 가능한 steady workload

운영자가 알아야 할 모니터링 포인트

Aurora 핵심 CloudWatch 지표

지표의미주목 임계값
AuroraReplicaLagReader와 Writer 간 lag (ms)20ms 초과 시 알림
DatabaseConnections현재 연결 수max_connections의 80%
CommitLatencycommit 완료 시간 (ms)환경마다 다름, 기저선 대비 2배
DMLLatencyINSERT/UPDATE/DELETE 평균 시간기저선 대비 모니터링
EngineUptime마지막 재시작 이후 경과 시간예상치 못한 재시작 탐지
FreeableMemory사용 가능 메모리전체의 10% 미만 경고
VolumeBytesUsed클러스터 볼륨 사용량급격한 증가 모니터링

페일오버 대응

Aurora 페일오버는 자동이지만, 애플리케이션 연결이 빠르게 재연결되도록 준비해야 한다.

권장 패턴:
1. Cluster Endpoint 사용 — Writer 엔드포인트는 페일오버 후 자동으로 새 Writer를 가리킴
2. RDS Proxy 사용 — 페일오버 중 연결 풀을 유지, 애플리케이션 단절 최소화
3. Connection string에 연결 재시도 로직 추가
4. 읽기는 Reader Endpoint 또는 개별 Reader Endpoint 사용

RDS Proxy

커넥션 폭발(connection storm)이 우려되는 환경에서 RDS Proxy는 중간 연결 풀 역할을 한다. 수천 개의 애플리케이션 연결을 소수의 실제 DB 연결로 멀티플렉싱한다. Aurora 페일오버 시에도 Proxy가 연결을 유지해 애플리케이션 입장에서 단절이 최소화된다.

Aurora vs RDS 선택 요약

기준RDS for MySQL/PostgreSQLAurora
엔진 호환성표준 MySQL/PostgreSQL 완전 호환대부분 호환, 일부 차이 있음
스토리지EBS 기반, 용량 지정 필요클러스터 볼륨, 자동 확장
읽기 복제 lag수초~수십초10ms 미만
최대 Reader 수5개15개
페일오버 시간1~2분 (Multi-AZ Instance)30초 미만
스토리지 내구성AZ 단위3 AZ × 2 = 6-way 복제
가격RDS 대비 낮음RDS 대비 약 20% 높음
최적 용도표준 워크로드, 비용 절감고가용성, 읽기 확장, 빠른 복구

가격이 중요하고 표준 기능으로 충분하다면 RDS. 복제 lag·페일오버 속도·읽기 확장성이 중요하다면 Aurora가 합리적 선택이다.

References