[database] Amazon Aurora

RDS 공통(Multi-AZ 개념·Read Replica·Blue/Green 등)은 rds. 이 노트는 Aurora 고유(공유 스토리지·엔드포인트·Global Database·Serverless·Backtrack)에 집중.

One-Line Summary

Amazon Aurora는 AWS가 만든 MySQL·PostgreSQL 호환 클라우드 네이티브 관계형 DB다. 컴퓨트와 분리된 분산 공유 스토리지(3개 AZ에 6중 복제, 자동 확장) 위에서 동작해, 일반 RDS보다 높은 성능·빠른 복제·자동 확장·글로벌 DR을 제공한다. 시험 핵심은 공유 스토리지 구조 / 엔드포인트(writer·reader) / Global Database / Serverless v2 / Backtrack 이다.

뭔지 (What / Why) — RDS와 뭐가 다른가

일반 RDS는 인스턴스마다 EBS 볼륨을 갖고, 복제는 엔진 수준으로 복사한다. Aurora는 근본이 다르다: 스토리지를 컴퓨트에서 분리해 여러 인스턴스가 하나의 분산 스토리지 볼륨을 공유한다.

        [Writer]      [Reader]   [Reader] …최대 15
            \            |         /
        ┌────────────────────────────────┐
        │  공유 분산 스토리지 볼륨          │  ← 3개 AZ에 6중 복제, self-healing
        │  10GB 단위 자동 확장(최대 128TB) │
        └────────────────────────────────┘

이 구조 덕분에:

읽기 복제본이 같은 스토리지를 보므로 복제 지연이 거의 없다(RDS Read Replica의 비동기 지연과 대비).
스토리지가 자동 확장되고, 한 AZ가 죽어도 데이터는 다른 복제본으로 유지(self-healing).
성능이 일반 RDS MySQL/PostgreSQL보다 높다.

"MySQL/PostgreSQL 호환인데 더 높은 성능·확장·글로벌"이면 Aurora. 호환성은 그대로라 기존 앱을 거의 안 고친다.

Abbreviations

약어	풀네임	의미
`ACU`	Aurora Capacity Unit	Aurora Serverless의 용량 단위(메모리+CPU)
`RPO`	Recovery Point Objective	허용 데이터 손실 시점
`RTO`	Recovery Time Objective	허용 복구 시간

Aurora Replica & 엔드포인트 (빈출)

Aurora는 최대 15개 Aurora Replica를 두고, 엔드포인트로 트래픽을 나눠 받는다. 앱은 IP가 아니라 엔드포인트에 붙는다.

엔드포인트	역할
Cluster(Writer) endpoint	항상 현재 writer를 가리킴(쓰기). failover 시 자동으로 새 writer로
Reader endpoint	여러 Aurora Replica로 읽기 로드밸런싱
Custom endpoint	특정 인스턴스 집합(예: 분석용 큰 인스턴스)만 묶어 라우팅

failover: writer 장애 시 Replica 하나가 자동 승격(우선순위 tier 지정 가능), 보통 30초 내.
고가용성을 위해 Replica를 다른 AZ에 두면 인스턴스 장애에도 자동 전환.

"쓰기는 한 곳, 읽기는 자동 분산" = writer/reader 엔드포인트. "복제 지연 없이 읽기 확장" = Aurora Replica(공유 스토리지).

Aurora Global Database (빈출 — 글로벌·DR)

1개 주 리전 + 최대 5개 보조 리전을 두고, 스토리지 레벨로 1초 미만 복제한다.

항목	내용
목적	글로벌 저지연 읽기 + 리전 단위 DR
복제	전용 인프라로 < 1초(앱 부하 영향 최소)
DR 지표	RPO ~1초, RTO < 1분(보조 리전 승격)
승격	주 리전 장애 시 보조 리전을 주로 승격

"관계형 DB의 다중 리전 DR·글로벌 읽기" = Aurora Global Database(Cross-Region Read Replica보다 빠르고 관리 쉬움).

Aurora Serverless v2 (빈출 — 가변 워크로드)

용량(ACU)을 워크로드에 맞춰 자동으로 미세 조정한다. 용량 계획 없이 쓴다.

언제	내용
예측 어려운/간헐적 트래픽	자동 스케일 업/다운, 사용한 용량만 과금
개발/테스트, 급변 워크로드	프로비저닝 관리 불필요

"트래픽이 들쭉날쭉/예측 불가한 관계형" = Aurora Serverless v2. 상시 고정 부하면 프로비저닝 인스턴스가 저렴할 수 있음.

그 밖의 Aurora 고유 기능

기능	내용
Backtrack (Aurora MySQL)	복원 없이 DB를 몇 초 전 시점으로 되감기(in-place) — 실수 복구 빠름
Fast Cloning	copy-on-write로 즉시 복제본 생성(테스트/개발용, 스토리지 절약)
백업	스토리지에 연속 백업 + PITR, 성능 영향 없음
Aurora Machine Learning	SQL에서 SageMaker/Comprehend 호출(니치)

Backtrack(되감기) ↔ 스냅샷 복원(새 인스턴스 생성) 구분. "빠르게 이전 시점으로 되돌리기" = Backtrack.

실무 활용 사례

고성능 상용 서비스: RDS MySQL 한계 → Aurora로 성능·15 저지연 복제.
글로벌 서비스 + DR: Aurora Global Database로 지역별 읽기 + 리전 장애 대비.
SaaS 멀티테넌트/개발환경: Fast Cloning으로 즉시 테스트 복제.
불규칙 트래픽 앱: Aurora Serverless v2로 용량 자동 조정.

Common Wrong Directions

오답 방향	왜 부족한가
Aurora를 RDS와 완전 별개로 암기	RDS 계열의 고성능 MySQL/PostgreSQL 호환 엔진
글로벌 관계형 DR에 Cross-Region RR만	Aurora Global Database가 더 빠르고(<1초) 관리 쉬움
Aurora Replica가 복제 지연이 크다고 봄	공유 스토리지라 지연 거의 없음(RDS 비동기 RR과 다름)
가변 워크로드에 큰 프로비저닝 인스턴스	Aurora Serverless v2
실수 데이터 복구에 무조건 스냅샷 복원	Aurora MySQL은 Backtrack으로 되감기

Exam Triggers

문제에서 이런 표현이 나오면	떠올릴 것
"MySQL/PostgreSQL compatible, higher performance/scale"	Aurora
"multi-region, low-latency global reads, region-level DR"	Aurora Global Database
"read scaling with minimal replication lag"	Aurora Replica + reader endpoint
"variable/unpredictable workload, auto-scale capacity"	Aurora Serverless v2
"rewind database to a recent point without restore"	Backtrack
"quickly create a test copy of the DB"	Fast Cloning
"writer changes on failover, app keeps same endpoint"	Cluster(writer) endpoint

Memory Sentence

Aurora는 컴퓨트와 분리된 공유 스토리지(3AZ 6중 복제·자동확장) 위의 MySQL/PostgreSQL 호환 고성능 DB다. writer/reader 엔드포인트로 쓰기·읽기를 나누고, Aurora Replica는 지연 거의 없이 읽기 확장·자동 failover. 글로벌·DR은 Global Database(<1초, RTO<1분), 가변 워크로드는 Serverless v2, 실수 복구는 Backtrack, 테스트 복제는 Fast Cloning.