개요
최근 3개월 동안 비용 절감 및 최적화로 다양한 AWS 서비스를 사용 및 개선하였습니다.
그 중에서는 가장 높은 비용을 차지하는 Amazon RDS 및 RDS Aurora도 있었습니다.
그 중에서 Amazon RDS를 배웠지만 Amazon RDS Aurora에 대해서 잘 모르는 것 같아서 추가 학습을 했습니다.
Amazon Aurora란?
Amazon Aurora Architecture 살펴보기
Aurora Cluster Volume
Read Replica란?
Read Replica와 Failover이란?
AWS Wrapper for JDBC Driver
Aurora Global Database 살펴보기
Aurora Global Database with Write Fowarding 살펴보기
Aurora Global Database Failvoer 전략 살펴보기
Aurora MySQL : writing less
Aurora PostgreSQL : writing less
일반적인 PostgreSQL과 WAL, Block 등
Amazon Aurora란?
Amazon RDS는 관리형 데이터베이스 임에도 자동 스케일링이 되지 않습니다. - [Ref]
Amazon Aurora는 클라우드 네이티브 데이터베이스로서
Cloud Native Database라는 특징을 가지고 있습니다.
그 특징에 걸맞게 Amazon RDS보다 더 강력한 관리형 기능들을 제공하여 운영 및 비용 효율성을 개선하는데 도움이 됩니다.
Amazon Aurora의 최소 타입에 대한 이야기
Amazon RDS에 비해서 Amazon Aurora는 최소 타입이 큰 편에 속합니다. 따라서 최소 비용의 관점으로 보면 오히려 비쌀 수 있습니다.
RDS는 db.t4g.micro를 지원하지만 Aurora는 db.t4g.medium 부터 지원합니다.
Amazon Aurora Architecture 살펴보기
Amazon Aurora와 Amazon RDS를 구분하는 가장 큰 차이점은 스토리지입니다.
Amazon RDS는 인스턴스 별로 EBS Volume을 가지고 특별한 가용영역에 배포됩니다.
하지만 Amazon Aurora는 다중 가용영역에 배포된 Clustered Volume*을 사용합니다.
즉, Aurora의 Primary Instance나 Read Replica 모두 단일 Clustered 볼륨을 사용하게 된다는 점입니다.
Aurora Clustere Volume
Aurora Primary Instance에 쓰기 작업이 지시되면 로그 레코드에 기록이 됩니다.
단, 이 로그 레코드는 6개의 복사본을 가지며 Cluster Volume 내에서 미러링 됩니다.
이러한 쓰기 작업은 일부 스토리지가 다운되더라도 최소 4개 이상의 완료가 달성되면 작업이 완료된 것으로 간주할 수 있습니다. 이 부분은 정족수 충족 합의와 유사합니다. - [Ref]
하지만 쓰기 작업은 시퀀스 넘버(Sequence Number) 관점에서처리되기 때문에, 실제로는 1개의 작업만 진행됩니다.
Read Replica란?
Amazon Aurora도 RDS와 같이 Rea Replica를 생성할 수 있습니다.
최대 15개의 Read Replica를 생성가능하며 서로 다른 인스턴스 타입을 사용이 가능합니다.
Read Replica와 Failover이란?
Read Replica가 1개 이상 존재하는
Amazon Aurora의 Primary Instance에 장애가 발생하면 Read Replica가 승격됩니다.
이는 Amazon RDS의 Multi-AZ의 대기 인스턴스와 유사하지만, 실제로 사용 가능한 인스턴스가 있는 것이므로 비용적으로도 훨씬 합리적입니다.
AWS Wrapper for JDBC Driver
일반적으로 Aurora Primary Instance에 장애가 발생한 경우
Read Replica를 승격시켜서 Primary Instance로 만들 수 있습니다.
하지만 이 경우에 Route53 DNS 전파에 30초 이상의 시간이 걸립니다.
jdbc:mysql://하지만 AWS Wrapper for JDBC Driver를 사용하면 이 시간이 10초 내외로 단축됩니다.
jdbc:mysql://~jdbc:aws-wrapper:mysql://자세한 내용은 AWS re:Invent 2022 - Deep dive into Amazon Aurora and its innovations (DAT326)을 참고해주세요.
Aurora Global Database 살펴보기
Multi-Region에서 데이터베이스를 운영하고 싶을 때
Amazon Aurora Global Database를 사용할 수 있습니다.
아래는 2개의 Region에 2개의 Cluster Volume을 가지고 있는 워크로드 구성입니다.
좌측에는 Primary DB Cluster와 Primary Instance/Read Replcia가 위치하고 있습니다.
우측에는 Secondary DB Cluster와 Read Replica가 존재하고 있습니다.
Primary DB Cluster의 Primary Instance에 삽입된 데이터는 Primary Cluster Volume에서 일정 주기로 Replication agents*를 통해서 Secondary Cluster Volume으로 복제됩니다.
Amazon Aurora Global Database에서는 최대 5개까지 DB Cluster 배포가 가능합니다.
개별 DB Cluster가 서로 다른 인스턴스 타입 혹은 서버리스 타입으로 배포가 가능하며
때로는 Cluster Volume만 복제하고 Read Replica를 배포하지 않을 수도 있습니다.
Aurora Global Database with Write Fowarding 살펴보기
위와 같은 구성에서 Secondary DB Cluster 등에 쓰기 작업이 시도되면 실패할 것입니다.
하지만 --enable-global-write-fowarding 옵션을 활성화하면 어드 DB Cluster에 쓰기 작업을 시도해도 최종적으로 Primary DB Cluster의 Primary Instance로 그 요청이 전달됩니다.
Aurora Global Database Failover 전략 살펴보기
앞서 Read Replica가 활성화된 Aurora의 경우 자동으로 재해 복구가 진행됨을 배웠습니다. - [Ref]
하지만 Aurora Global Database를 사용 중이라면 아래와 같은 요구사항이 있을 수 있습니다.
Primary DB Cluster가 마비되어 Replica DB Cluster를 승격시켜야 하는 경우
서비스 사용자의 지리적 위치를 고려하여 Replication DB Cluster를 승격해야 하는 경우
장애 상황에서 1번에서는 Replica DB Cluster를 승격을 시키면 됩니다. 이 경우 기존의 DB Cluster는 분리되며 복구가 되더라도 다시 통합되지 않습니다.
2번 경우에서는 관리형 계획 복구(Managed Planned Failover) 기능*을 사용하여 Primary DB Cluster 변경할 수 있습니다.
이 경우 일시적으로 기존 Primary DB Cluster의 Primary Instance에 대한 쓰기 작업이 중단되며, 데이터 동기화가 다되었는지 검증(Verify)하고 Primary DB Cluster가 교체될때까지 쓰기 작업에 장애가 발생할 수 있습니다.
Aurora MySQL : writing less
일반적인 MySQL은 이중쓰기 버퍼(Doublewrite Buffer)와 블록(Block)과 데이터파일(Datafile)이 존재합니다.
Aurora MySQL은 해당 개념을 사용하지 않아 속도가 더 빠릅니다.
또한 일반 MySQL의 블록(Block)의 크기가 16 KB 인데 Linux의 블록은 4 KB인 것으로 인해서 충돌이 발생하여 복구 트랜잭션이 발생할 수 있습니다. 이 작업은 일반 MySQL에서 수 분 이상의 시간이 걸립니다.
하지만 Aurora MySQL에서는 복구 트랜잭션이 거의 발생하지 않으며, 하더라도 수 초 이내에 완료가 됩니다.
Aurora PostgreSQL : writing less
일반적인 PostgreSQL은 블록(Block)과 데이터파일(Datafile), 체크포인트(Checkpoint)이 존재합니다.
Aurora PostgreSQL은 해당 개념을 사용하지 않아 기본적인 속도가 더 빠릅니다.
또한 일반 PostgreSQL의 블록(Block)의 크기가 8 KB 인데 Linux의 블록은 4 KB인 것으로 인해서 충돌이 발생하여 복구 트랜잭션이 발생할 수 있습니다. 이 작업은 일반 PostgreSQL에서 수 분 이상의 시간이 걸립니다.
하지만 Aurora PostgreSQL에서는 복구 트랜잭션이 거의 발생하지 않으며, 하더라도 수 초 이내에 완료가 됩니다.
일반적인 PostgreSQL과 WAL, Block 등
일반 PostgreSQL은 WAL(Write Ahead Log)* 작업이 선행됩니다. - [Ref]
업데이트 쿼리를 실행하면 메모리 위에 블록(Block)*을 가집니다.
블록에는 원본 튜플(행)과 새 튜플(행)이 위치하며 이 정보가 로그 스트림으로 전송이 됩니다.
어느 순간 체크포인트(Checkpoint)가 필요하며
이 순간에 쌓인 블록(Block)을 다른 장소에 백업을 해야 합니다. 이것이 일반적인 PostgreSQL의 작동 과정입니다.
PostgreSQL의 블록 크기는 8KB인데, Linux는 4KB이기 때문에 시스템이 충돌하여 문제가 발생할 수 있습니다. 문제가 발생하면 PostgreSQL이 Recovery Transaction을 실행하지만 이 시간은 몇 분의 장애를 발생시킵니다. 커뮤니티에서도 블록 크기 변경에 대한 내용이 많습니다. - [Ref]
일반적인 PostgreSQL에 대한 자세한 내용은 PostgreSQL Architecture 이해하기에서 다루겠습니다.
하지만 Aurora PostgreSQL에서는 블록(Block) 단위로 체크포인트(Checkpoint)를 제어하지 않습니다. 오직 업데이트 쿼리에 대한 백업 작업이 이루어지며 밀리초(ms) 단위의 지연시간이 발생합니다.
Aurora PosgreSQL에서도 충돌이 발생하지만 이 과정의 수정은 몇초 안에 해결이 됩니다.
Aurora Storage Node
앞서 위에서 Aurora에는 Custer Volume이 있음을 알았습니다.
읽기 및 쓰기 작업에 대해서 Cluster Volume에 데이터를 저장하고 조회하는 작업을 처리하는 것을 저장 노드(Storage Node)*라고 부릅니다. - [Ref]
일반적인 MySQL, PostgreSQL이 다양한 절차를 사용하는 반면, Aurora for MySQL, PostgreSQL는 매우 직관적인 프로세스를 가집니다.