.png){kind=small}
안녕하세요. AWS에서 데이터베이스를 선택할 때 가장 먼저 마주하는 고민이 있습니다.
"그냥 익숙한 RDS MySQL을 쓸까? 아니면 AWS가 그렇게 자랑하는 Aurora를 써볼까?"
얼핏 보면 둘 다 똑같은 MySQL/PostgreSQL 엔진을 사용하는 관리형 DB처럼 보입니다. 하지만 이 둘은 엔진 뚜껑을 열어보면 아예 다른 구조로 동작합니다.
오늘은 전통적인 강자 RDS와 클라우드 네이티브의 정점 Aurora의 차이점을 아키텍처 관점에서 비교해 드립니다.
1. Amazon RDS : “관리를 대신 해주는 든든한 서버”
RDS(Relational Database Service)는 우리가 온프레미스에서 쓰던 DB 서버를 그대로 클라우드로 옮겨서, 관리만 편하게 만든 것입니다.
구조: EC2 인스턴스에 EBS(블록 스토리지)를 붙여서 DB를 설치한 구조와 유사합니다.
특징:
프로비저닝, 패치, 백업을 AWS가 자동화해 줍니다.
Multi-AZ (고가용성): 장애 대비를 위해 Standby 인스턴스를 하나 더 띄우고, **동기식(Synchronous)**으로 데이터를 복제합니다.
한계: 스토리지와 컴퓨팅이 묶여 있습니다. 데이터가 늘어나면 스토리지 용량을 늘려야 하고, 이 과정에서 퍼포먼스 영향이 있을 수 있습니다.
2. Amazon Aurora : "클라우드를 위해 다시 태어난 DB"
Aurora는 AWS가 **"클라우드 환경에 최적화된 DB는 어떠해야 하는가?"**를 고민하고 바닥부터 다시 설계한 서비스입니다. 가장 큰 핵심은 **"컴퓨팅과 스토리지의 완벽한 분리"**입니다.
핵심 차이 1: 스토리지 아키텍처 (The Storage Volume)
RDS: 내가 할당한 EBS 볼륨에 데이터를 씁니다.
Aurora: 가상화된 분산 스토리지 볼륨을 사용합니다.
데이터를 저장하자마자 3개의 가용 영역(AZ)에 6개의 복제본으로 쪼개져 저장됩니다.
스토리지가 10GB 단위로 최대 128TB까지 자동으로 늘어납니다. (용량 산정 불필요)
장점: 디스크 I/O 병목이 획기적으로 줄어듭니다. (RDS 대비 MySQL 5배, PostgreSQL 3배 성능)
핵심 차이 2: 읽기 복제본 (Read Replica)과 지연 시간
RDS: 읽기 전용 복제본(Read Replica)을 만들면, 마스터 DB의 데이터를 비동기로 복사해 와야 합니다. (복제 지연 발생 가능)
Aurora: 마스터와 복제본이 같은 스토리지(Cluster Volume)를 공유합니다.
데이터를 복사할 필요가 없습니다. 그냥 같은 디스크를 바라보면 되니까요.
복제 지연(Lag)이 거의 없고(ms 단위), 복제본을 최대 15개까지 순식간에 늘릴 수 있습니다.
핵심 차이 3: 장애 복구 속도 (Failover)
RDS: 마스터가 죽으면 Standby가 승격되는 데 보통 60초~120초가 걸립니다. (DNS 변경 시간 포함)
Aurora: 마스터가 죽으면 읽기 복제본 중 하나가 즉시 마스터로 승격됩니다. 이 과정이 30초 이내로 매우 빠릅니다. 심지어 스토리지 문제가 생겨도 자가 치유(Self-healing) 기능이 작동합니다.
3. 요약: 언제 무엇을 써야 할까?
마치며
**"그래서 뭘 써요?"**라고 물으신다면, 저는 이렇게 추천합니다.
스타트업 초기/개발 서버: RDS로 시작하세요. 비용 효율적이고 충분히 좋습니다.
서비스가 급성장하거나 쇼핑몰 이벤트가 많다면: Aurora로 마이그레이션하세요. 트래픽 폭주 시 읽기 복제본 확장의 유연함과 장애 복구 속도는 돈값을 톡톡히 합니다.
