안녕하세요. 회사와 함께 성장하고 싶은 KOSE입니다.
이번 포스팅은 Amazon Aurora에 대한 정리를 진행하고자 합니다!
1. Aurora
Amazon Aurora는 고성능 상용 데이터베이스의 성능과 가용성에
오픈소스 데이터베이스의 간편함, 비용 효율성을 결합하였습니다.
클라우드르 위해 구축된 MySQL 및 PostgreSQL 호환 관계형 데이터베이스입니다.
Aurora는 표준 MySQL 데이터베이스보다 최대 5배 빠르고, 표준 PostgreSQL 데이터베이스보다 3배가 빠릅니다.
비용 또한, 절감되며 하드웨어 프로저닝, 데이터베이스 설정, 패치 및 백업 같은 작업을 자동화하는 RDS에서 aurora를 관리합니다
* 하드웨어 프로저닝: 데이터베이스를 호스팅 하기 위해 필요한 서버 및 스토리지 리소스를 준비하고 할당하는 과정
(CPU, 디스크 공간, 네트워크 용량 등을 결정하고 설정함)
2. RDS와 차이점
RDS는 가용영역 내부에 RDS가 존재하며, RDS는 EC2와 EBS로 구성되어 있습니다.
* EBS: Amazon Web Service에서 제공하는 Elastic Block Store의 약자입니다.
AWS 클라우드에서 사용할 수 있는 영구적인 스토리지 블록 디바이스를 제공합니다.
EBS는 네트워크를 통해 EC2 인스턴스에 연결되며,
데이터베이스와 같이 지속적인 스토리지가 필요한 애플리케이션에 적합합니다.
동일한 리전의 여러 개의 가용영역으로 나눠있는 RDS는 VPC 그룹 내에서 보안 처리가 이루어지게 됩니다.
Multi AZ 사용시 primary - standby로 읽기 전용 DB로 복제됩니다
(standBy DB는 접근 불가능, failover 발생 시 RDS StandBy가 Primary로 승격)
이러한 구조는 접근 불가능한 DB를 생성하여 싱크를 맞추는 과정이 필요하므로 안정성은 증가하지만,
비용이 두배가 증가합니다.
multi AZ와 다른 개념으로 RDS 읽기 전용 리플리카라는 개념이 있습니다.
읽기 전용 리플리카는 데이터베이스 읽기 성능을 향상하기 위한 방법으로, 비동기로 데이터를 복제합니다.
쓰기 쿼리는 Primary에 전송된다면, 읽기 전용 요청은 리플리카에서 처리되어 부하 분산 역할을 수행합니다.
(읽기 전용 리플리카는 DNS 주소가 있습니다)
Aurora DB는 클러스터 구성으로 되어있으며, 이 클러스터에는 하나 이상의 DB 인스턴스가 포함됩니다.
클러스터 볼륨은 여러 가용 영역에 걸쳐 자동으로 복제되고 분산됩니다. 이는 여러 물리적 위치에 저장하므로 높은 내구성과
가용성을 지니고 있습니다.
이때, Aurora는 스토리지 계층을 데이터베이스 엔진과 밀접하게 통합하여 네트워크 지연을 줄이고 I/O 작업을 최적화합니다.
여기서 궁금했던 점은, 어떠한 이유로 클러스터 노드로 처리하는 것이 I/O 작업을 최적화할 수 있는지입니다.
Aurora는 전통적인 RDS와 비교하여 밀접하게 통합된 아키텍처를 가지고 있는데, 인스턴스가 스토리지와 효율적으로 통신할 수 있도록
설계가 되어 있기 때문에 I/O 지연시간을 줄이고 클러스터 간 스토리지 계층에서 데이터 관리를 최적화한다고 생각하였습니다.
또한, RDS는 EBS 스토리지를 사용하게 되는데, 생성 시 EBS 용량을 지정해서 사용해야 합니다.
Aurora는 필요한 스토리지를 자동으로 확장해 주는 방법을 적용하므로
RDS와 비교했을 때 유연한 자동 확장이 더 용이하다고 볼 수 있습니다.
3. AWS Aurora 특징
Aurora는 다음의 장점 및 특징을 가지고 있습니다.
- 분산 스토리지: Aurora는 고가용성과 내구성을 위해 설계된 분산 스토리지 시스템을 사용합니다.
위의 사진처럼 여러 가용 영역에 걸쳐 복제되어 저장하므로 하나의 AZ에 장애가 발생해도 데이터 손실이 없고 가용성이 유지됩니다. - 자동 복제: Aurora는 데이터를 자동으로 여섯 개의 복제본으로 저장합니다. 이 복제본은 세 개 이상의 물리적으로 분산된 AZ에 존재하게 되는데, 단일 인스턴스 장애가 전체 데이터베이스 시스템 장애로 이어지지 않음을 의미합니다.
만약 위에처럼 개별 분산 스토리지가 장애가 난다면 총 6개의 복제본에 저장하므로 4개 이상의 쓰기 작업이 가능하다면
쓰기가 정상적으로 처리됩니다 (읽기는 3개 이상 정상적이라면 읽기 능력이 유효합니다)
혹은 인스턴스가 장애 난다면 failover로 읽기 인스턴스가 승격하여 쓰기 처리를 수행할 수 있습니다.
여기서 궁금한 점은 쓰기/읽기의 엔드포인트가 다른데, 만약 쓰기 엔드포인트가 장애날 때,
서버에서는 이를 어떻게 인지하고 승격한 엔드포인트로 요청을 보낼까요?
이는 Amazon Aurora에서 클러스터 엔드포인트를 제공함으로 해결할 수 있습니다.
클러스터 엔드포인트는 항상 Writer의 인스턴스를 가리킵니다. 이는 특정 DNS의 주소를 알 필요 없이 클러스터 엔드포인트로
쓰기 요청을 처리할 수 있습니다.
반면 읽기 전용 리플리카가 에러가 난다면, 어떻게 처리될까요?
리플리카들은 개별적인 DNS가 아닌 공통된 DNS를 가집니다.
만약 읽기 전용 엔드포인트로 요청을 보내면 Aurora는 내부적인 로드 밸런싱 메커니즘을 통해 해당 요청을 Reader로 라우팅 합니다.
즉 클라이언트 입장에서는 다수의 리플리카 인스턴스에 대한 각각의 DNS를 알 필요 없이 읽기 전용 엔드포인트로 요청을 보내게 됩니다.
여기서, 장애가 발생하면 Aurora는 해당 인스턴스를 자동으로 로드 밸런싱 풀에서 제거하고, 다른 Reader로 라우팅 하게 됩니다.
이어서 Aurora는 다음의 특징을 가집니다.
- 스토리지 확장성: Aurora는 사용한 만큼 비용을 지불하는 방식으로 데이터베이스 스토리지를 자동으로 확장합니다.
- 성능: Aurora는 표준 MySQL 및 PostgreSQL보다 훨씬 높은 성능을 제공합니다.
이는 Aurora가 데이터베이스 버퍼 풀, 리두 로깅 및 페이지 리플레이와 같은 데이터베이스 엔진의 핵심 부분을 최적화하여 제공하기 때문입니다. - 복구 속도: Aurora는 데이터베이스의 물리적인 복사본을 만드는 대신 변경 사항 로그를 저장하기 때문에, 복구 속도가 매우 빠릅니다.
- 고가용성과 장애 조치: Aurora는 고가용성을 위해 설계되었으며, 인스턴스 장애 시에 장애 조치 시간이 RDS에 비해 훨씬 짧습니다.
- Backtrack 제공: 데이터베이스를 이전 시점으로 되돌릴 수 있는 기능을 제공합니다
이 기능을 통해 특정 시점의 상태 이전으로 데이터베이스를 되돌릴 수 있습니다.
이상으로 Aurora에 대한 정리를 마치도록 하겠습니다! 추가되는 내용은 계속 업데이트하며 정리하도록 하겠습니다!
잘못된 점이나 수정 필요한 부분은 댓글 부탁드립니다!
감사합니다!!!
참고: AWS 강의실 https://www.youtube.com/@AWSClassroom
참고: AWS 강의실 RDS https://www.youtube.com/watch?v=koDIV5QMw38
참고: AWS 강의실 Aurora https://www.youtube.com/watch?v=RImUPhD8X-o
참고: https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html