Amazon Aurora 멀티 마스터 구성
AWS RDS에서 사용 가능한 데이터베이스 엔진이자 AWS에서 개발하여 서비스하고 있는 데이터베이스 엔진인 Amazon Aurora DB의 멀티 마스터 구성(2개의 DB 인스턴스가 모두 마스터로 작동하여 양방향 복제가 이뤄지는 구성)에 대해 작성합니다.
오로라 멀티 마스터 구성은 2019년 8월 처음 서비스 시작하여 올해 5월 지원 리전이 확대되어 서울 리전에서도 이용이 가능해졌습니다. 현재 멀티 마스터 구성을 이용할 수 있는 리전은 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤), 아시아 태평양(뭄바이), 아시아 태평양(서울), 아시아 태평양(도쿄), EU(프랑크푸르트), EU(아일랜드)입니다.
미팅 중 문의가 있었던 부분(멀티 마스터 구성 가능여부 및 각 마스터를 별도로 인스턴스 타입 변경 가능한지)에 대해 조사 및 테스트 진행해본 내용 정리하여 공유합니다.
Aurora 멀티 마스터
오로라 멀티 마스터 구성의 기본 구성도는 아래와 같이 1개의 오로라 DB 클러스터가 2개의 쓰기 인스턴스를 가지고 있으며, 여러 가용 영역에 배치된 스토리지 노드(노드 볼륨)를 공유하고 있습니다.
1개의 쓰기 노드에서 변경사항이 발생하는 경우 6개의 스토리지 노드로 변경사항을 반영하여 클러스터간 동일한 데이터를 유지합니다. 오로라 멀티 마스터 구성에서는 두 DB 인스턴스가 Active-Active 상태로, 하나의 쓰기 인스턴스가 다운되어도 서비스가 유지될 수 있도록 고가용성을 보장합니다.
아래부터는 직접 오로라 멀티 마스터 구성을 생성하여 어떤 특징이 있는지 기재한 내용입니다.
1. RDS 데이터베이스 생성 페이지에서 엔진 옵션을 Amazon Aurora로 선택합니다. 에디션은 MySQL로 선택했습니다.
2. 복제 기능에서 기본 값인 단일 마스터가 아닌 다중 마스터로 선택합니다. MySQL 버전은 선택할 수 없고 오로지 MySQL 5.6 버전만 사용이 가능합니다. 기타 옵션은 필요에 따라 선택합니다.
3. 데이터베이스 생성이 완료되면 아래와 같이 클러스터 이름(premisan-test-auroradb)와 그 하위 메뉴로 2개의 쓰기 DB 인스턴스가 보여집니다.
4. RDS 엔드포인트의 경우 클러스터 엔드포인트와 각각의 쓰기 인스턴스별 엔드포인트가 별도로 있으며,
클러스터의 엔드포인트는 두 쓰기 인스턴스 중 하나의 엔드포인트를 CNAME 레코드로 가리키고 있습니다. 하나의 쓰기 인스턴스가 다운되면 바로 CNAME 레코드가 변경되면서 다른 쓰기 인스턴스를 가리키게 됩니다.
5. 두 쓰기 인스턴스는 다중 가용영역에 복제되어 있는 스토리지 노드로 변경 사항을 반영하기 때문에 두 DB 간 데이터는 동일하게 유지됩니다.
6. 또한 각각의 쓰기 인스턴스는 인스턴스 타입을 따로 변경 가능합니다.
하나의 쓰기 인스턴스가 인스턴스 타입 변경을 위해 다운되어 있는 동안 다른 쓰기 인스턴스가 DB쿼리를 처리하며, MySQL 리플리케이션처럼 DB 서버간 바이너리 로그를 복제하는 방식이 아니라, 쓰기 수행 시 쓰기 인스턴스 간 공유하고 있는 스토리지 노드에 변경 사항을 업데이트하는 것이기 때문에 인스턴스 타입 변경이 완료되는 동안에도 동일한 데이터가 유지됩니다.(인스턴스 타입 변경 진행 중에 생성한 데이터가 인스턴스 타입 변경 완료 후에 정상적으로 생성되어 있는 것 확인)
MySQL 리플리케이션 = 마스터서버에서 슬레이브 서버로 바이너리 로그를 복제하여 데이터 동기화(비동기식 복제로, 슬레이브 서버가 죽어서 바이너리 로그를 수신하지 못하면 데이터는 일치하지 않게 됨)
오로라 멀티 마스터 구성 = **복제된 스토리지를 공유**하고 있기 때문에 다운타임동안 발생한 변경사항이 모두 반영되고 있음인스턴스 타입 변경에 소요된 시간은 각각 5분, 7분으로 기존 MariaDB RDS의 인스턴스 타입 변경 시에 소요된 시간 8분과 큰 차이가 없습니다.(모두 거의 데이터가 없는 상태 기준)
7. 다운되었던 쓰기 인스턴스가 복구되어도 클러스터 엔드포인트의 CNAME은 변경된 상태를 유지합니다.
클러스터 엔드포인트(쓰기 인스턴스1 바라봄) -> 쓰기 인스턴스1 장애(혹은 유지보수를 위한 다운) -> 클러스터 엔드포인트(쓰기 인스턴스2 바라봄) -> 쓰기 인스턴스1 복구 -> 클러스터 엔드포인트(그대로 쓰기 인스턴스2을 바라보고 있음)8. 각 쓰기 인스턴스 별로 장애 조치 우선 순위라는 항목의 값은 있으나, 해당 값을 수정하는 부분은 찾지 못했습니다.
9. 또한 멀티 마스터 구성에서 최대 DB 인스턴스의 수는 2개로 이미 쓰기 인스턴스가 2개인 상태에서는 인스턴스 추가가 불가합니다.
10. 추가적인 읽기전용 복제본 생성은 불가했습니다.
결론
Aurora 멀티 마스터 구성 시 DB의 쓰기 워크도르를 분산하여 처리가 가능하며, 빠른 장애조치가 가능하고, 각각의 쓰기 인스턴스를 별도의 DB 인스턴스 타입으로 설정할 수 있다는 점이 장점으로 느껴졌습니다. 다만 자체적으로 분산된 충돌 감지 시스템으로 가지고 있어, 동일한 페이지에 쓰기 트랜잭션이 겹치는 경우 충돌이 발생한 트랜잭션은 롤백되는 점에서 어느정도 쓰기 충돌에 대한 대비는 되어 있다고는 하나, 인접한 테이블에 잦은 쓰기가 발생하는 작업이라면 하나의 쓰기 인스턴스를 통해 일관성을 유지하여 처리하는 것이 나을 것이란 생각이 들었습니다.