MySQL의 5배, PostgreSQL의 3배 성능. 6개 복제본 자동 유지. 128TB 자동 확장. RDS의 편리함 위에 '클라우드 네이티브' 스토리지를 올린 Aurora — 왜 만들어졌고, 어떻게 다르며, 언제 써야 하는지를 SIGMOD 논문부터 실전 사례까지 풀어본다.
이 시리즈의 RDS 글에서 관리형 데이터베이스의 편리함을 다뤘다. 패치, 백업, 복구, 스케일링을 AWS가 알아서 해준다. 충분히 좋다.
그런데 AWS는 2014년, RDS와 별도로 Aurora를 만들었다. 같은 회사가 같은 문제를 왜 다시 풀었을까?
답은 RDS의 구조적 한계에 있다. RDS는 기존 오픈소스 DB(MySQL, PostgreSQL)를 그대로 클라우드에 올린 것이다. DB 엔진 자체는 수십 년 전에 단일 서버를 위해 설계됐다. 이 엔진을 관리형으로 만든 것은 혁신이지만, DB 엔진의 근본 구조는 바뀌지 않았다.
RDS의 한계:
"DB 엔진의 상위 호환 API를 유지하면서, 스토리지를 클라우드에 맞게 완전히 새로 설계하면 어떨까?"
이것이 Aurora의 핵심 아이디어다.
Aurora의 기술적 혁신은 2017년 ACM SIGMOD(데이터 관리 분야 최고 학회)에서 발표된 논문으로 공개됐다:
"Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases" (Verbitski 등, 2017)
이 논문의 핵심 통찰:
"기존 데이터베이스의 병목은 더 이상 컴퓨팅이 아니라 네트워크다. 클라우드 환경에서 DB 인스턴스와 스토리지 사이의 네트워크 트래픽이 성능을 결정한다."
전통적 DB에서 데이터를 쓸 때, DB 엔진은 스토리지에 여러 종류의 데이터를 보낸다:
이 모든 것이 네트워크를 통해 EBS로 전송된다. Multi-AZ에서는 이것이 2배로.
Aurora의 혁명: "스토리지에 로그만 보낸다." 데이터 페이지 재구성은 스토리지 레이어가 직접 한다. 네트워크 트래픽이 기존 대비 약 1/6으로 감소.
Aurora는 데이터를 3개 AZ에 걸쳐 6개 복제본으로 자동 저장한다. 쿼럼 기반으로 작동:
이것이 의미하는 바:
RDS의 Read Replica가 최대 5개인 반면, Aurora는 최대 15개. 그리고 결정적 차이:
| 기준 | RDS (MySQL/PostgreSQL) | Aurora (MySQL/PostgreSQL 호환) |
|---|---|---|
| 스토리지 | EBS 볼륨 (인스턴스 종속) | 분산 스토리지 (독립, 3 AZ) |
| 복제본 | 최대 5개 | 최대 15개 |
| 복제 지연 | 수 초~수십 초 | 보통 < 20ms |
| 페일오버 시간 | ~60초 | ~30초 (Replica가 있으면 더 빠름) |
| 스토리지 최대 | 64TB (수동 확장) | 128TB (자동 확장) |
| 성능 | 표준 MySQL/PostgreSQL | MySQL 5배, PostgreSQL 3배 |
| 백업 | 자동 스냅샷 + PITR | 연속 백업 (S3에 자동) |
| 서버리스 | ✗ | Aurora Serverless v2 |
| 글로벌 DB | Cross-Region Replica | Aurora Global Database (~1초 지연) |
| 비용 | 저렴 (인스턴스 + EBS) | RDS 대비 ~20% 높음 |
2022년 GA 출시된 Aurora Serverless v2는 DB 용량을 ACU(Aurora Capacity Unit) 단위로 자동 조절한다.
글로벌 서비스를 운영하면: 서울에 DB가 있는데, 뉴욕 사용자가 접속하면 쿼리마다 300ms 지연. 각 리전에 DB를 따로 두면 데이터 동기화 문제.
Aurora Global Database의 해법: 한 리전에 Primary, 최대 5개의 다른 리전에 Secondary 클러스터를 자동으로 복제한다.
RDS 글에서 다룬 보안 원칙이 Aurora에도 동일하게 적용된다. 추가로 Aurora 고유의 보안 기능:
ALTER TABLE을 잘못 실행해서 데이터를 날렸다면? 기존 방식: 스냅샷에서 새 인스턴스를 만들어 데이터를 복구 (수십 분~수 시간). Backtrack: 현재 DB를 해당 시점으로 되감기 (수 초). 단, Backtrack 윈도우(최대 72시간) 안에서만 가능하므로 미리 활성화해야 한다.| 항목 | 설명 | 비고 |
|---|---|---|
| 인스턴스 | 시간당 과금 | RDS 대비 ~20% 높음 |
| 스토리지 | $0.10/GB/월 (서울) | 사용한 만큼만. 10GB 단위 자동 증가 |
| I/O | 읽기/쓰기 요청당 과금 | 표준: $0.20/100만 I/O, I/O 최적화: 포함 |
| 백업 | 스토리지 크기까지 무료 | 초과분 $0.021/GB/월 |
| Serverless v2 | ACU-시간당 과금 | $0.12/ACU-시간 (서울) |
db.r6g.large 기준 (서울 리전):
| RDS PostgreSQL | Aurora PostgreSQL | |
|---|---|---|
| 인스턴스 (월) | ~$196 | ~$235 (+20%) |
| 스토리지 100GB | ~$12 (gp3) | ~$10 (사용량 기반) |
| Multi-AZ | ~$392 (인스턴스 2배) | 추가 비용 없음 (스토리지 복제 포함) |
| Read Replica 1개 | ~12 | ~$235 (스토리지 공유, 추가 비용 없음) |
| 총 (Multi-AZ + 1 Replica) | ~$616/월 | ~$470/월 |
Samsung SmartThings는 전 세계 수억 대의 IoT 기기 데이터를 Aurora Global Database로 관리한다. 미국 Primary + 유럽/아시아 Secondary로 구성하여, 각 리전에서 로컬 수준의 읽기 성능을 제공한다.
Airbnb는 자체 관리 PostgreSQL에서 Aurora PostgreSQL로 마이그레이션했다:
Dow Jones(월스트리트저널 발행)는 Aurora를 사용하여 실시간 뉴스 서비스를 운영한다. 속보 발생 시 트래픽이 10배 이상 급증하지만, Aurora의 읽기 Replica와 자동 스케일링으로 대응한다.
4억 명 이상의 사용자를 가진 Duolingo는 Aurora Serverless v2를 활용하여, 새벽에는 최소 용량, 피크 타임에는 자동 확장으로 DB 비용을 40% 절감했다.
| 상황 | 이유 | 대안 |
|---|---|---|
| 비용이 가장 중요, 고가용성 불필요 | Aurora가 RDS보다 비쌈 | RDS (단일 AZ) |
| MySQL/PostgreSQL 외의 DB 필요 | Aurora는 두 가지만 호환 | RDS (Oracle, SQL Server) |
| OLAP (대규모 분석) | Aurora는 OLTP에 최적화 | Redshift |
| 키-값 초고속 조회 | 관계형 DB 오버스펙 | DynamoDB |
| 완전 서버리스, 사용량 0일 때 비용 0원 | Serverless v2도 최소 0.5 ACU | DynamoDB 온디맨드 |
RDS 글에서 언급한 Aurora DSQL은 여러 리전에 걸쳐 강력한 일관성을 보장하는 분산 SQL 데이터베이스다. Google Spanner에 대한 AWS의 대답:
수평 샤딩을 자동으로 해주는 Aurora의 확장. 기존 Aurora는 Writer가 1개뿐이라 쓰기 확장에 한계가 있었다. Limitless는 테이블을 자동으로 샤딩하여 여러 Writer에 분산한다.
RDS는 기존 DB를 클라우드에 올린 것이다. Aurora는 기존 DB를 클라우드를 위해 다시 만든 것이다.
차이는 스토리지 레이어에 있다. "The log is the database" — 로그만 전송하고, 스토리지가 스스로 데이터를 재구성하는 이 설계가 6개 복제본, 10초 복구, 128TB 자동 확장, 15개 Replica를 가능하게 했다.
이 시리즈에서 다룬 데이터베이스 선택 최종 가이드:
| 요구사항 | 추천 | 이유 |
|---|---|---|
| 간단한 CRUD, 비용 최우선 | RDS | 가장 저렴 |
| 프로덕션, 고가용성 필수 | Aurora | 6 복제본, 빠른 페일오버, Replica 확장 |
| 서버리스 DB | Aurora Serverless v2 | 자동 스케일링, 유휴 비용 최소 |
| 초고속 키-값 | DynamoDB | ms 미만 응답 |
| 대규모 분석 (OLAP) | Redshift | 컬럼나 스토리지, MPP |
| 텍스트/벡터 검색 | OpenSearch | 역색인, k-NN |
코어닷투데이의 프로덕션 데이터베이스는 Aurora PostgreSQL이다. AI 서비스의 메타데이터, 사용자 데이터, 추론 이력이 Aurora에 안전하게 저장되고, pgvector로 벡터 검색이 수행되며, 6개 복제본으로 데이터가 보호되고, Serverless v2로 비용이 최적화된다. "클라우드를 위해 재설계된 DB" — Aurora의 약속이 실현되는 현장이다.