2014년 AWS re:Invent에서 Aurora가 발표됐을 때 많은 DBA들이 의심했다. "MySQL을 그냥 관리형으로 올린 게 아니냐"는 것이었다. 아니다. Aurora의 내부를 들여다보면 이야기가 완전히 다르다. Amazon은 전통적인 관계형 DB 아키텍처의 근본적 제약 — 스토리지가 단일 서버에 붙어있다는 것 — 을 공유 분산 스토리지로 해체했다. 이 결정이 만드는 차이가 "왜 Aurora는 같은 MySQL이면서 더 빠르고 더 안전한가"를 설명한다.
전통적인 MySQL RDS(Multi-AZ 포함)는 이렇게 생겼다. Primary 인스턴스 하나가 EBS 볼륨 하나에 데이터를 쓴다. Multi-AZ를 쓰면 그 EBS 데이터 전체를 Standby 인스턴스의 EBS로 블록 단위로 복제한다. Read Replica를 추가하면 binlog를 통해 각 Replica의 EBS에 데이터를 다시 쓴다. 결국 데이터가 N개의 EBS 볼륨에 N벌 존재한다.
이 구조의 문제: 페일오버가 느리다. Standby로 전환하려면 Standby가 완전히 최신 상태인지 확인하고, 새 Primary로 승격하고, DNS를 변경해야 한다. Read Replica를 5개 추가하면 Primary에서 binlog가 5곳으로 나가야 한다. 스토리지 확장은 각 인스턴스의 EBS를 별도로 관리해야 한다.
Aurora의 해결책은 스토리지 레이어를 완전히 분리하는 것이었다