아마존 Aurora

Amazon Aurora; Aurora; 아마존 오로라
MySQL·PostgreSQL과 호환되면서, 컴퓨팅과 분리된 3개 가용 영역 분산 스토리지를 쓰는 AWS의 클라우드용 관계형 데이터베이스 엔진

아마존 Aurora는 아마존 RDS에서 고를 수 있는 DB 엔진 중 하나이지만, 일반 RDS 엔진과 구조가 다르다. 일반 RDS는 DB 인스턴스마다 자기 EBS 볼륨을 가지고 복제본도 데이터를 따로 복사해 가진다. Aurora는 클러스터 볼륨이라는 공유 스토리지 하나를 쓰기 인스턴스와 읽기 인스턴스가 함께 본다. 그래서 복제본을 늘려도 데이터 복사가 필요 없고, 장애 조치가 빠르며, 스토리지가 자동으로 커진다.

기존 MySQL·PostgreSQL 애플리케이션의 코드, 드라이버, 도구를 거의 그대로 쓸 수 있다. RDS for MySQL·PostgreSQL에서 스냅샷 복원이나 복제로 옮겨 올 수 있다.

핵심 개념

항목	설명
DB 클러스터	쓰기 인스턴스(primary, writer) 1개와 읽기 인스턴스(Aurora 복제본, reader) 최대 15개, 그리고 이들이 공유하는 클러스터 볼륨으로 구성된다.
클러스터 볼륨	SSD 기반 가상 볼륨. 데이터 사본을 한 리전의 3개 가용 영역에 걸쳐 저장한다. 쓰기는 가용 영역에 걸친 스토리지 노드 6개에 동기 복제된다. 복제 수준은 DB 인스턴스 수와 무관하다.
자동 확장	데이터가 늘면 볼륨이 자동으로 커지고, 테이블을 지우면 공간이 반환된다. 최대 크기는 엔진 버전에 따라 다르며 최신 버전은 256TiB까지이다.
Aurora 복제본	같은 클러스터 볼륨을 읽는 읽기 전용 인스턴스. 복제 지연은 보통 100밀리초보다 훨씬 짧다. 장애 조치 대상이기도 하다.
스토리지 구성	Aurora Standard(I/O 요청당 과금)와 Aurora I/O-Optimized(I/O 요금 없이 인스턴스·스토리지 요금이 높음). I/O 비용이 전체 Aurora 비용의 25% 이상이면 I/O-Optimized가 유리하다.

엔드포인트

엔드포인트	연결 대상	용도
클러스터 엔드포인트(쓰기)	현재의 쓰기 인스턴스	쓰기와 DDL. 장애 조치로 새 쓰기 인스턴스가 정해져도 주소가 바뀌지 않는다.
리더 엔드포인트	읽기 인스턴스들	읽기 전용 연결을 Aurora 복제본들에 분산한다.
사용자 지정 엔드포인트	직접 고른 인스턴스 묶음	분석용 대형 인스턴스와 일반 조회용 인스턴스를 나누는 경우
인스턴스 엔드포인트	특정 인스턴스 하나	진단, 튜닝

고가용성과 장애 조치

쓰기 인스턴스에 문제가 생기면 Aurora가 자동으로 감지하고 Aurora 복제본 하나를 새 쓰기 인스턴스로 승격한다. 데이터가 이미 공유 볼륨에 있으므로 새 인스턴스를 처음부터 만드는 것보다 훨씬 빠르다.
복제본에 장애 조치 우선순위(tier)를 정해 어느 복제본이 먼저 승격될지 고를 수 있다.
복제본이 하나도 없으면 쓰기 인스턴스가 복구될 때까지 클러스터를 쓸 수 없다. 운영 환경에서는 다른 가용 영역에 복제본을 최소 하나 둔다.
데이터 자체는 인스턴스 수와 무관하게 3개 가용 영역에 저장되므로, 복제본은 데이터 보호보다 컴퓨팅 가용성과 읽기 확장을 위한 것이다.

아마존 Aurora Serverless

Aurora Serverless는 인스턴스 크기를 고정하지 않고, 지정한 최소·최대 범위 안에서 Aurora 용량 단위(ACU)로 용량을 자동 조절한다. ACU 하나는 메모리 약 2GiB와 그에 맞는 CPU·네트워크이다.

AWS 문서는 현재 v2 방식을 기준으로 Aurora Serverless를 설명한다. 0~256 ACU 범위에서 0.5 ACU 단위로 세밀하게 늘고 준다. 처리 중인 SQL이나 열린 트랜잭션을 멈추지 않고 확장한다.
최소 용량을 0 ACU로 두면 작업이 없을 때 자동으로 일시 중지되어 컴퓨팅 비용이 나오지 않는다.
한 클러스터 안에 서버리스 인스턴스와 프로비저닝 인스턴스를 섞을 수 있고, 다중 AZ 구성과 Aurora 복제본, 글로벌 데이터베이스도 쓸 수 있다.
사용량이 들쭉날쭉하거나 예측하기 어려운 애플리케이션, 여러 테넌트 DB, 개발·테스트 환경에 맞다. 부하가 꾸준히 높으면 프로비저닝 인스턴스와 예약 인스턴스가 더 쌀 수 있다.

Aurora 글로벌 데이터베이스

기본 DB 클러스터 하나와 다른 리전의 보조 클러스터로 이루어진 글로벌 데이터베이스

Aurora Global Database는 하나의 기본(primary) 리전과 최대 10개의 읽기 전용 보조(secondary) 리전으로 구성된다.

기본 리전의 변경 사항을 전용 인프라로 보조 리전에 복제하며, 지연은 보통 1초 미만이다. 복제가 기본 클러스터 성능에 주는 영향이 작다.
보조 리전 사용자는 가까운 리전에서 짧은 지연으로 읽는다. 쓰기 전달(write forwarding)을 켜면 보조 클러스터가 받은 쓰기를 기본 클러스터로 넘긴다.
리전 전체 장애 때 보조 리전을 새 기본 리전으로 승격해 기존 복제 방식보다 낮은 RPO·RTO로 복구한다. 계획된 리전 이동에는 데이터 손실 없는 전환(switchover)을 쓴다.
보조 클러스터는 읽기 전용이라 읽기 인스턴스를 최대 16개까지 둘 수 있다.

백트랙과 복제(cloning)

백트랙(Backtrack): Aurora MySQL에서 백업 복원 없이 클러스터를 지정 시각으로 되감는다. 새 클러스터를 만들지 않고 몇 분 안에 끝나므로, 실수로 테이블을 지운 직후 빠르게 되돌릴 때 쓴다. 미리 대상 백트랙 기간을 정해 켜야 하고 변경 기록 저장 요금이 나온다. Aurora PostgreSQL은 지원하지 않으며, 백업을 대체하지 않는다.
복제(Aurora cloning): 원본과 같은 데이터 페이지를 공유하는 새 클러스터를 copy-on-write 방식으로 만든다. 처음에는 추가 공간이 거의 들지 않고 변경된 페이지만 새로 저장한다. 운영 데이터로 테스트 환경을 빨리 만들 때 스냅샷 복원보다 빠르고 싸다.
특정 시점 복구: 자동 백업 보존 기간 안의 원하는 시각으로 새 클러스터를 복원한다.

RDS와 비교

구분	RDS for MySQL·PostgreSQL	아마존 Aurora
스토리지	인스턴스마다 EBS 볼륨, 크기를 지정(스토리지 자동 조정 가능)	공유 클러스터 볼륨, 자동 확장
데이터 사본	다중 AZ 대기 인스턴스나 복제본이 각자 사본 보유	항상 3개 가용 영역에 사본, 인스턴스 수와 무관
읽기 복제본	최대 15개, 엔진의 비동기 복제	Aurora 복제본 최대 15개, 공유 볼륨이라 지연이 매우 짧음
장애 조치	다중 AZ 인스턴스 배포는 보통 60~120초	복제본 승격으로 더 빠름
리전 간	리전 간 읽기 전용 복제본	글로벌 데이터베이스(보조 리전 최대 10개, 보통 1초 미만 지연)
서버리스	없음	Aurora Serverless v2
엔진	MySQL, PostgreSQL 외에 MariaDB, Oracle, SQL Server, Db2	MySQL, PostgreSQL 호환만
비용	작은 규모에서 대개 더 쌈	인스턴스 단가가 높지만 고가용성·성능이 필요한 대규모에서 유리

시험 포인트

MySQL·PostgreSQL 호환이면서 고가용성, 빠른 장애 조치, 많은 읽기 복제본이 필요하면 Aurora를 고른다. Oracle이나 SQL Server가 필요하면 Aurora는 오답이고 RDS를 쓴다.
읽기 부하 분산은 Aurora 복제본을 늘리고 애플리케이션의 읽기 연결을 리더 엔드포인트로 보낸다. 쓰기는 클러스터 엔드포인트로 보낸다.
여러 리전 사용자에게 짧은 지연의 읽기와 리전 장애 복구(낮은 RPO·RTO)가 필요하면 Aurora 글로벌 데이터베이스이다.
사용량이 예측 불가하거나 간헐적이며 관리 부담을 줄이려면 Aurora Serverless v2이다.
운영 데이터로 테스트 환경을 빠르고 싸게 만들려면 Aurora 복제(cloning), 방금 한 실수를 몇 분 만에 되돌리려면 백트랙(Aurora MySQL)이다.
I/O 비용이 큰 작업은 Aurora I/O-Optimized로 비용을 예측 가능하게 만든다.

같이 보기

참고 문헌