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 기반 복제를 알아야 한다. 오늘은 그 내부를 들여다본다.
전통적인 MySQL/PostgreSQL은 1990년대 단일 서버 환경을 가정해서 설계됐다. binlog/WAL을 디스크에 쓰고, 백업은 그 디스크를 복사하고, 복제는 binlog를 다른 서버로 보내는 식이다