Day 4 - Aurora: AWS가 RDBMS의 스토리지 레이어를 다시 쓴 이야기

Aurora는 2014년 re:Invent에서 처음 공개됐을 때 많은 사람을 어리둥절하게 만들었다. "MySQL 호환인데 MySQL이 아니다"라는 어색한 표현. AWS의 메시지는 명확했다 — SQL 엔진 코드는 MySQL/PostgreSQL을 거의 그대로 쓰지만, 그 아래의 스토리지·복제·트랜잭션 레이어를 클라우드 환경에 맞게 처음부터 재설계했다. 이 결정이 가져온 결과가 "MySQL 대비 5배, PostgreSQL 대비 3배 성능 + 자동 확장 스토리지 + 1초 미만 cross-region 복제"라는 숫자다.

DVA-C02에서 Aurora는 RDS와 묻는 각도가 다르다. RDS는 "관리형 DB의 trade-off"를 묻고, Aurora는 "왜 RDS로 부족한가, 어떤 시나리오에서 Aurora를 골라야 하는가"를 묻는다. 그 답을 이해하려면 Aurora의 스토리지 구조와 quorum 기반 복제를 알아야 한다. 오늘은 그 내부를 들여다본다.

Aurora의 탄생: "데이터베이스는 스토리지가 본질이다"

전통적인 MySQL/PostgreSQL은 1990년대 단일 서버 환경을 가정해서 설계됐다. binlog/WAL을 디스크에 쓰고, 백업은 그 디스크를 복사하고, 복제는 binlog를 다른 서버로 보내는 식이다. 이 모델을 클라우드에 그대로 옮기면 ① EBS 한 볼륨에 의존하므로 단일 AZ 장애에 취약 ② 복제는 비동기 binlog 기반이라 lag 발생 ③ 스토리지 확장은 수동 ④ 백업/복원은 인스턴스 크기에 비례하는 시간 — 이런 한계가 그대로 따라온다.

Aurora 논문(SIGMOD 2017 "Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases", Verbitski et al.)이 던진 핵심 통찰은 단순했다. "네트워크가 새로운 병목이다. 따라서 네트워크 트래픽을 줄이는 것이 곧 성능이다." 전통 DB는 commit 시점에 ① data page ② undo log ③ redo log ④ binlog ⑤ double-write buffer 등 같은 데이터를 여러 형태로 디스크에 쓴다. AWS 측정에 따르면 MySQL은 한 commit당 약 7.4번의 디스크 I/O가 발생한다.

Aurora는 이 중 redo log만 분산 스토리지에 보내고, 페이지 재구성은 스토리지 노드가 백그라운드로 처리한다. 결과적으로 I/O 횟수는 1/6 수준, 네트워크 트래픽은 7.7배 줄었다.

일반 MySQL의 commit:
  애플리케이션 → MySQL
                  ↓
              로컬 디스크 쓰기 (data page, redo log, undo log, binlog, double-write...)
                  ↓
              binlog 기반 replica 복제 (비동기)

Aurora의 commit:
  애플리케이션 → Aurora
                  ↓
              "redo log record"만 6개 스토리지 노드에 송신
                  ↓
              4/6에서 ack 받으면 commit 완료
              (스토리지 노드가 백그라운드로 data page 재구성)

Aurora 스토리지 노드는 단순한 EBS 볼륨이 아니다. redo log를 받아서 page를 reconstruct할 수 있는 작은 서버다. Aurora의 한 스토리지 노드는 들어오는 log record를 자기 로컬 디스크에 append하고, 그 log를 적용한 페이지 버전을 만들어 둔다. 읽기 요청이 "이 페이지의 특정 LSN 시점 버전"을 요구하면 스토리지 노드가 즉시 응답한다.

이 구조 덕분에 ① binlog가 사라지고 ② replica는 자체 스토리지 없이 primary와 같은 스토리지를 참조하며 ③ 백업은 사실상 무료(continuous backup) ④ 스토리지 확장은 자동(10GB 단위 segment를 추가/제거). 이것이 Aurora 차별점의 근원이다.

6 사본 × 3 AZ + Quorum: "어떤 조합의 실패에도 살아남는다"

Aurora 스토리지를 설명하는 대표적인 그림은 "6 copies across 3 AZs"다. 이 숫자는 임의로 정한 것이 아니라 분산 시스템의 fault tolerance 수학에서 유도한 값이다.

3 AZ × 2 copies = 6 사본

쓰기 quorum: V_w = 4 (6 사본 중 4개 ack 받으면 commit)
읽기 quorum: V_r = 3 (6 사본 중 3개에서 읽으면 valid)

V_w + V_r > N (4 + 3 > 6) → 강한 일관성 보장
2 × V_w > N (8 > 6) → 동시 쓰기 충돌 방지

이 설정이 보장하는 것:

• AZ 1개 + 추가 노드 1개 손실 = 읽기 가능 (남은 사본 3개로 V_r 만족)
• AZ 1개 전체 손실 = 쓰기 가능 (남은 사본 4개로 V_w 만족)
• AZ 2개 손실 = 데이터 손실 없음 (남은 사본 2개로 복구 가능)

Aurora의 (N=6, W=4, R=3)은 AZ 단위 장애와 노드 단위 장애를 함께 견디도록 고른 값이다.

Aurora Replica: 공유 스토리지가 만든 ms 단위 복제

RDS Read Replica는 각 replica가 자기 스토리지를 가지고 primary의 binlog를 받아 자기 디스크에 apply한다. 이 모델의 한계가 ① replica마다 스토리지 비용이 발생한다 ② lag는 binlog 전송 + apply 속도에 의존(보통 수 초 ~ 수십 초) ③ replica 추가 시 초기 동기화에 시간 소요.

Aurora Replica는 자체 스토리지가 없다. Primary와 같은 분산 스토리지를 공유한다. 그래서:

• 복제 lag는 보통 100ms보다 훨씬 짧다 (공식 문서 표현; 쓰기 부하가 크면 늘어난다)
• Replica 추가 시 즉시 사용 가능 (스토리지 복사 없음)
• 15개까지 확장 (RDS MySQL/PG/MariaDB도 소스당 최대 15개)
• 인스턴스 비용만 부담 (스토리지 비용 중복 없음)

⚠️ 함정: Aurora Replica의 페일오버 시간이 30초인 것은 인스턴스 클래스가 같을 때다. Primary와 다른 인스턴스 클래스의 replica가 있으면 페일오버 우선순위가 떨어지고, 페일오버 후 성능 저하가 일어날 수 있다. "Aurora 페일오버 후 성능 저하" 시나리오의 원인은 replica 인스턴스 크기 불일치일 수 있다. Tier 0-15 우선순위로 페일오버 순서를 명시할 수 있다.

Aurora 엔드포인트 5종: 어디로 연결할지 결정하는 도구

Aurora는 RDS와 달리 인스턴스 단위 endpoint가 아닌 클러스터 단위 endpoint가 기본이다. 5종을 구분해야 한다.

Reader Endpoint의 부하 분산은 DNS 레벨에서 일어난다. 같은 endpoint를 resolve하면 매번 다른 replica IP가 반환된다(TTL 5초). 이 때문에 두 가지 문제가 생긴다.

• 클라이언트가 connection을 유지하면 그 connection은 한 replica에 묶인다. connection pool이 작으면 부하가 균등하게 분산되지 않는다.
• DNS를 캐싱하는 stub resolver(Java DNS 기본 캐시는 무한)는 갱신하지 않는다.

실무에서는 ① 짧은 connection lifetime ② Aurora 클라이언트 라이브러리(MariaDB Connector/J Aurora cluster aware, Aurora Postgres JDBC wrapper) 사용 ③ RDS Proxy로 routing 위임 중 하나가 필요하다. "Reader Endpoint를 썼는데 한 replica에만 부하가 몰린다"는 시나리오의 원인은 connection 유지 + DNS 캐싱이다.

# 실무: 분석 워크로드를 custom endpoint로 격리
ANALYTICS_ENDPOINT = "myclu-analytics.cluster-custom-xxxx.region.rds.amazonaws.com"
OLTP_READER_ENDPOINT = "myclu.cluster-ro-xxxx.region.rds.amazonaws.com"
WRITER_ENDPOINT = "myclu.cluster-xxxx.region.rds.amazonaws.com"
 
def get_analytics_conn():
    return pymysql.connect(host=ANALYTICS_ENDPOINT, ...)
 
def get_oltp_read_conn():
    return pymysql.connect(host=OLTP_READER_ENDPOINT, ...)
 
def get_write_conn():
    return pymysql.connect(host=WRITER_ENDPOINT, ...)

Aurora Serverless v2: ACU의 비밀

Aurora Serverless는 트래픽에 따라 컴퓨트 용량이 자동으로 늘었다 줄었다 한다. 단위는 ACU(Aurora Capacity Unit) — 1 ACU ≈ 2GB 메모리 + 그에 상응하는 CPU/네트워크. v1과 v2의 차이는 시험에 나온다.

v1과 v2의 가장 큰 차이는 확장 메커니즘이다. v1은 새 인스턴스로 트래픽을 옮기는(scale-up) 방식 — 그래서 점프가 크고 느리다. v2는 대부분의 스케일링 이벤트에서 라이터/리더를 같은 호스트에 둔 채 용량을 조정하며, 진행 중인 DB 작업을 방해하지 않는다. 이것이 "미세 조정"의 근거다. v2는 "사용량 기반 과금이 가능한 정규 Aurora 인스턴스"에 가깝다.

사용 시나리오별 선택은 다음과 같다.

• 트래픽이 24시간 일정 → 일반 Aurora 인스턴스 (Reserved로 비용 절감)
• 트래픽이 주기적이지만 예측 가능 → Aurora + Auto Scaling for replicas
• 트래픽이 간헐적·예측 불가 → Aurora Serverless v2
• 개발/스테이징 환경 (밤에는 사용 안 함) → Aurora Serverless v2 (auto-pause 활성화)
• 데이터 API 호출이 주된 사용 → Aurora Serverless v2

Aurora Global Database: 1초 미만 cross-region 복제의 비결

Aurora Global Database는 primary 리전 1개 + secondary 리전 최대 10개로 구성된다. RDS Cross-Region Read Replica와 다른 점은 ① 전용 복제 인프라(스토리지 레벨 복제) ② 일반적으로 lag < 1초 ③ Secondary가 자체 read replica를 최대 16개 보유 가능 ④ managed failover RTO는 수 분 단위(지원 버전의 switchover는 보통 30초 미만).

[Primary Region: ap-northeast-2 서울]
  Aurora Writer + Replicas
       │
       │ (스토리지 레벨 replication, < 1초)
       │
       ├──→ [Secondary: us-east-1 버지니아]
       │      Read-only Aurora cluster
       │      자체 read replica 0-16개
       │
       └──→ [Secondary: eu-west-1 아일랜드]
              Read-only Aurora cluster
              자체 read replica 0-16개

Aurora Global Database의 복제는 redo log shipping에 가깝지만 binlog가 아니다. Primary의 스토리지 노드가 redo log를 추가로 secondary region의 스토리지 노드에게 직접 전송한다. 이 채널은 AWS backbone 네트워크(같은 백본 위에서 평균 RTT 100-200ms)를 사용하고, 압축·중복 제거가 적용되어 일반 인터넷 대비 효율적이다. 그 결과 cross-region lag이 일반적으로 1초 미만이다. "글로벌 분산 + 1초 미만 lag + RDBMS" 시나리오의 답은 Aurora Global Database다.

⚠️ 함정: Aurora Global Database의 secondary는 읽기 전용이다. 단순 write를 시도하면 read-only error. 또한 "관리되는 페일오버(managed failover)"는 명시적으로 트리거해야 하며 자동이 아니다 — primary region이 완전히 죽었을 때 운영자가 promote를 실행. 자동 페일오버가 필요하면 Route 53 health check + Lambda로 직접 자동화하거나 RDS Proxy를 활용한다. "Aurora Global Database가 자동으로 페일오버한다"는 보기는 함정이다.

Aurora Backtrack vs PITR: in-place 시간 여행

Aurora MySQL에는 RDS에 없는 기능 — Backtrack이 있다. 데이터를 과거 시점으로 새 인스턴스 생성 없이 되돌린다. 최대 72시간 전까지 가능. PITR은 새 인스턴스를 만들지만 Backtrack은 같은 인스턴스를 시간만 되돌린다.

가상의 사례로, 한 게임 회사 개발자가 production Aurora MySQL에 DELETE FROM users 를 WHERE 절 없이 실행했다(개발 DB와 헷갈림). Backtrack이 활성화돼 있어 콘솔에서 "5분 전으로 되돌리기" 한 번에 약 3분 만에 복구했다. PITR이었다면 ① 새 인스턴스 생성(30분) ② 데이터 export/import(시간 단위) ③ 애플리케이션 endpoint 전환이라는 복잡한 절차가 필요했을 것이다. "Aurora에서 빠른 실수 복구"는 Backtrack이 답이다.

Aurora Database Cloning: COW로 만든 즉시 클론

Aurora는 클러스터를 수 초 만에 클론할 수 있다. 클론은 같은 스토리지를 공유하면서 copy-on-write 방식으로 동작 — 클론에서 데이터를 수정해야 비로소 그 페이지만 새로 복사된다. 결과: ① 클론 생성 즉시 가능 ② 초기 비용 = 0 ③ 수정량만큼만 추가 스토리지 비용.

[Primary Aurora] ────┬──── [Clone A] (개발 환경)
                     │
                     ├──── [Clone B] (테스트 환경)
                     │
                     └──── [Clone C] (분석 워크로드)

처음엔 모두 같은 스토리지 페이지 공유
수정 발생 시 그 페이지만 클론 전용 복사 (COW)

production DB의 클론을 만들어 production-grade 데이터로 테스트하는 패턴이 있다. 일반 mysqldump/export는 TB 단위에서 수 시간 걸리지만, Aurora 클론은 거의 즉시 만들어진다. CI/CD 파이프라인에서 매 빌드마다 클론을 만들어 테스트하고 끝나면 삭제하는 워크플로우에도 쓸 수 있다.

RDS vs Aurora 결정표

정리

Aurora의 차별점은 "스토리지 레이어를 재설계했다"는 한 문장에서 파생된다.

• 6 사본 quorum이 가용성을 보장한다.
• 공유 스토리지가 replica를 ms 단위로 만든다.
• redo log shipping이 cross-region 복제를 1초 미만으로 만든다.
• copy-on-write가 클론을 즉시 만든다.

시험은 이 인과관계를 시나리오 형태로 묻는다. "어떤 요구사항에서 어떤 Aurora 기능이 답인가"를 판단해야 한다.

RDS는 "기존 DBMS를 클라우드에 옮긴" 1세대 관리형 DB, Aurora는 "DBMS를 클라우드 네이티브로 다시 설계한" 2세대다. DynamoDB는 "관계형 모델 자체를 버린" 또 다른 답이다. 같은 문제(데이터 영속성, 확장성, 가용성)에 세 가지 다른 답이 있다는 점을 이해하면 시험 시나리오를 풀 수 있다.

다음 글에서는 이번 주 전체(RDS + ElastiCache + Aurora)를 시나리오 중심으로 묶고, Week 7 종합 평가를 정리한다.