Amazon Aurora (Aurora) 알아보기

이 글에서는 Amazon Aurora DB 엔진에 대해서 설명합니다. 

목차

• Amazon Aurora (Aurora) 개요
• Amazon Aurora를 Amazon RDS와 함께 사용하는 방법
• Amazon Aurora DB 클러스터
• Amazon Aurora Storage 엔진 소개

Amazon Aurora (Aurora) 개요

---

Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 고성능 관계형 데이터베이스 엔진입니다.

호환성 및 이점:

Aurora는 MySQL 및 PostgreSQL과의 호환성을 가지며, 기존 코드, 도구 및 애플리케이션을 그대로 사용할 수 있습니다. 특히 일부 워크로드에서는 MySQL의 처리량을 최대 5배, PostgreSQL의 처리량을 최대 3배까지 제공할 수 있습니다.

 

고성능 스토리지:

Aurora에는 고성능 스토리지 하위시스템이 포함되어 있으며, MySQL 및 PostgreSQL과 호환되는 데이터베이스 엔진이 빠른 분산형 스토리지를 활용하도록 설계되었습니다. Aurora 클러스터 볼륨 크기는 최대 128 tebibytes (TiB)까지 증가할 수 있습니다.

 

자동화된 데이터베이스 클러스터링 및 복제:

Aurora는 데이터베이스 클러스터링 및 복제를 자동화하고 표준화하여 데이터베이스 구성 및 관리의 어려운 측면을 해결합니다.

 

Amazon RDS와의 관계:

Aurora는 Amazon Relational Database Service(Amazon RDS)의 일부로 제공되며, 클라우드에서 관계형 데이터베이스 설치, 운영 및 크기 조정을 쉽게 할 수 있도록 도와줍니다.

 

Amazon Aurora를 Amazon RDS와 함께 사용하는 방법

---

다음 사항은 Amazon Aurora가 Amazon RDS에서 사용 가능한 표준 MySQL 및 PostgreSQL 엔진과 어떻게 관련되는지를 보여줍니다.

항목	내용
Amazon Aurora와 Amazon RDS의 관계	Amazon RDS에서 Aurora MySQL 또는 Aurora PostgreSQL을 DB 엔진 옵션으로 선택하여 새 데이터베이스 서버 설정
Aurora의 Amazon RDS 기능 활용	Aurora는 Amazon RDS 관리 기능 활용하여 프로비저닝, 패치 적용, 백업, 복구, 장애 감지 및 복구 등 데이터베이스 작업 처리
Aurora의 클러스터링 및 복제	Aurora 관리 작업은 전체 데이터베이스 서버 클러스터를 포함하며 자동 클러스터링, 복제, 스토리지 할당으로 간편한 설정, 작동 및 확장 가능
데이터 마이그레이션	스냅샷 생성, 복원 및 단방향 복제를 통해 Amazon RDS의 데이터를 Aurora로 이전 가능하며, 버튼식 마이그레이션 도구 사용하여 애플리케이션 전환 가능

 

Amazon Aurora DB 클러스터

Amazon Aurora DB cluster는 하나 이상의 DB 인스턴스와 이 DB 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성됩니다. Aurora 클러스터 볼륨은 다중 가용 영역을 아우르는 가상 데이터베이스 스토리지 볼륨으로서, 각 가용 영역에는 DB 클러스터 데이터의 사본이 있습니다. Aurora DB 클러스터는 다음과 같이 두 가지 유형의 DB 인스턴스로 구성됩니다.

• 기본 DB 인스턴스 – 읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨의 모든 데이터 수정을 실행합니다. Aurora DB 클러스터마다 기본 DB 인스턴스가 하나씩 있습니다.
• Aurora 복제본 – 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원합니다. 각 Aurora DB 클러스터는 기본 DB 인스턴스에 더해 최대 15개까지 Aurora 복제본을 구성할 수 있습니다. Aurora 복제본을 별도의 가용 영역에 배치하여 고가용성을 유지합니다. Aurora는 기본 DB 인스턴스를 사용할 수 없는 경우 자동으로 Aurora 복제본으로 장애 조치합니다. Aurora 복제본에 대해 장애 조치 우선 순위를 지정할 수 있습니다. 또한 Aurora 복제본은 기본 DB 인스턴스에서 읽기 워크로드를 오프로드할 수 있습니다.

다음은 클러스터 볼륨과 Aurora DB 클러스터에 속하는 기본 DB 인스턴스 및 Aurora 복제본 사이의 관계를 나타낸 다이어그램입니다.

Aurora 클러스터를 보면 컴퓨팅 용량과 스토리지가 분리되어 있습니다. 예를 들어 DB 인스턴스가 1개뿐인 Aurora 구성은 계속해서 클러스터입니다. 기본 스토리지 볼륨에는 여러 가용 영역(AZ)으로 분산된 다수의 스토리지 노드가 포함되어 있기 때문입니다.

Aurora DB 클러스터의 입출력(I/O) 작업은 Writer DB 인스턴스인지 Reader DB 인스턴스인지에 관계없이 동일한 방식으로 계산됩니다. 자세한 내용은 Amazon Aurora DB 클러스터의 스토리지 구성 섹션을 참조하세요.

참고: https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html

 

아마존 오로라 아키텍처

아마존 오로라는 공유 스토리지를 사용하는 것으로 보인다. 

참고: https://www.slideshare.net/awskorea/d3s02internal-architecture-of-amazon-aurora-level-400pdf

 

Amazon Aurora Storage 엔진 소개

데이터베이스 스토리지의 진화

많은 고객들이 Direct Attached Storage(DAS)를 사용하여 데이터베이스 데이터를 저장합니다. 대기업 고객은 Storage Area Network(SAN)을 사용하기도 합니다. 이러한 접근 방식에는 다음과 같은 여러가지 문제가 있습니다:

 

• SAN은 비용이 많이 듭니다. 많은 수의 소규모 고개들은 SAN을 관리하는데 필요한 물리적인 SAN 인프라 또는 스토리지 전문성을 확보하기 힘듭니다.
• 디스크 스토리지는 성능을 위해 수평 확장이 복잡합니다. 효율적으로 운영하더라도, DAS와 SAN은 확장할 수 있는 한계가 여전히 존재합니다.
• DAS 및 SAN 인프라는 단일 물리적 데이터 센터에 존재합니다. 정전이나 네트워크 중단으로 단일 데이터 센터가 손상되면 데이터베이스 서버를 사용할 수 없습니다.
• 홍수, 지진 또는 기타 자연 재해로 인해 데이터 센터가 파괴되면 데이터가 손실 될 수 있습니다. 데이터 백업을 오프 사이트에 보관하면 새 위치에서 데이터베이스 서버를 다시 온라인 상태로 복구하는 데 몇 분에서 며칠 정도 걸릴 수 있습니다.

Amazon Aurora 스토리지 엔진 소개

Amazon Aurora는 클라우드를 활용하도록 설계되었습니다.

 

개념적으로 Amazon Aurora 스토리지 엔진은 한 리전(Region)의 여러 AWS 가용 영역(Availability Zone)에 걸친 분산된 SAN 입니다. AZ는 단일 또는 복수개의 물리적 데이터 센터로 구성된 논리적 데이터 센터입니다. 각 AZ는 해당 리전의 다른 AZ와의 신속한 통신을 가능하게 하는 낮은 대기시간 링크를 제외하고는 다른 AZ와 완벽히 격리됩니다. Amazon Aurora의 핵심인 분산형 저 지연 스토리지 엔진은 여러 AZ에 걸쳐서 구성됩니다.

 

스토리지 할당

Amazon Aurora는 보호 그룹(protection groups) 이라고 하는 10GB 논리 블록에 스토리지 볼륨을 구축합니다. 각 보호 그룹의 데이터는 6개의 스토리지 노드에 복제됩니다. 그런 다음 해당 스토리지 노드는 Amazon Aurora 클러스터가 운영되는 리전의 3개 AZ에 할당됩니다.

 

클러스터가 생성된 직후에는 스토리지가 거의 사용되지 않습니다. 데이터 양이 증가하여 현재 할당된 스토리지를 넘어서면 Aurora는 요건을 충족시키기 위해 볼륨을 자연스럽게 확장하고 필요에 따라 새로운 보호 그룹을 추가합니다. Amazon Aurora는 64TB라는 현재의 제한에 도달 할 때까지 이러한 방식으로 계속 확장합니다.

 

 

 

Amazon Aurora 가 쓰기를 처리하는 방법

Amazon Aurora에 데이터를 쓰면 6개의 스토리지 노드로 병렬로 전송됩니다. 이러한 스토리지 노드는 세 개의 AZ에 분산되어 있어 내구성과 가용성을 크게 향상시킵니다.

 

각 스토리지 노드에서 레코드는 먼저 인-메모리(in-memory) 큐에 들어갑니다. 이 큐의 로그 레코드는 중복 제거됩니다. 예를 들어, 마스터 노드가 스토리지 노드에 성공적으로 쓰고 난 후, 마스터 노드와 스토리지 노드 사이의 연결이 중단 된 경우 마스터 노드는 로그 레코드를 재전송 하지만 중복된 로그 레코드는 폐기됩니다. 보관할 레코드는 핫 로그(hot log)에서 디스크에 저장됩니다.

 

레코드가 영구 저장된 후, 로그 레코드는 업데이트 큐라는 인-메모리 구조에 기록됩니다. 업데이트 큐에서 로그 레코드는 먼저 병합 된 다음 데이터 페이지로 만들어 집니다. 하나 이상의 로그 시퀀스 번호(LSN)가 누락 된 것으로 판단되면 스토리지 노드는 볼륨의 다른 노드에서 누락 된 LSN을 검색하는 프로토콜을 사용합니다. 데이터 페이지가 갱신 된 후 로그 레코드가 백업되고 가비지 컬렉션으로 표시됩니다. 그리고 데이터 페이지는 비동기식으로 Amazon S3에 백업됩니다.

 

핫 로그에 기록되어 쓰기가 지속되면 스토리지 노드는 데이터 수신을 확인합니다. 6개 스토리지 노드 중 4개 이상이 수신 확인을 하면 쓰기 작업은 성공한 것으로 간주되고 답신은 클라이언트 애플리케이션에 반환됩니다.

 

Amazon Aurora가 다른 엔진보다 빠르게 쓸 수 있는 이유 중 하나는 스토리지 노드에만 로그 레코드를 보내고 이러한 쓰기 작업이 병렬로 수행된다는 것입니다. 실제로 MySQL과 비교할 때, Amazon Aurora는 데이터가 6개의 다른 노드에 쓰여지고 있지만 유사한 워크로드 대해 IOPS가 약 1/8 정도 필요합니다.

 

이 모든 작업의 단계는 비동기적으로 진행됩니다. 쓰기는 지연을 줄이고 처리량을 향상시키기 위해 그룹 커밋(Group Commit)을 사용하여 병렬로 수행됩니다.

 

쓰기 대기 시간이 짧고 입출력 풋프린트(footprint)가 줄어든 Amazon Aurora는 쓰기 집약적인 애플리케이션에 이상적입니다.

 

내결함성(Fault Tolerance)

다음 다이어그램은 3개의 AZ에 저장된 데이터를 보여줍니다. 복제 된 데이터는 99.999999999%의 내구성을 제공하도록 설계된 Amazon S3에 지속적으로 백업됩니다.

 

 

이 설계는 Amazon Aurora가 클라이언트 애플리케이션에 대한 가용성 영향 없이 전체 AZ 또는 2개의 스토리지 노드에 대한 손실을 견딜 수 있게 합니다.

 

복구 과정에서 Aurora는 데이터 손실없이 보호 그룹에 있는 AZ와 또 다른 스토리지 노드의 손실에 견딜 수 있도록 설계되었습니다. 보호 그룹에 있는 4개의 스토리지 노드가 가용할 경우에만 Aurora 에서 쓰기가 지속되기 때문입니다. 

쓰기를 수신 한 3개의 스토리지 노드가 다운 된 경우에도 Aurora는 4번째 스토리지 노드에서 쓰기를 계속 복구할 수 있습니다. 복구 중에 읽기 쿼럼(read quorum)을 유지하기 위해서, Aurora는 3개의 스토리지 노드가 동일한 LSN을 따라잡을 수 있도록 합니다. 그러나 쓰기 작업을 위해 볼륨을 액세스 하기 위해서, Aurora는 4개의 스토리지 노드가 복구 될 때까지 기다려야하므로 향후 쓰기를 위해 쓰기 쿼럼(write quorum)을 획득할 수 있습니다.

 

읽기의 경우, Aurora는 읽기를 수행하기 위해 가장 가까운 스토리지 노드를 찾습니다. 각 읽기 요청은 타임 스탬프, 즉 LSN과 관련됩니다. 스토리지 노드는 LSN까지 따라잡은 경우(즉, 해당 LSN까지 모든 업데이트를 수신 한 경우) 읽기를 수행 할 수 있습니다.

 

하나 이상의 스토리지 노드가 다운되었거나 다른 스토리지 노드와 통신 할 수 없는 경우 해당 노드는 가십 프로토콜(gossip protocol)을 사용하여 온라인 상태가 되면 다시 동기화 합니다. 스토리지 노드가 손실되고 새 노드가 자동으로 만들어지면 가십 프로토콜을 통해 동기화 됩니다

 

Amazon Aurora를 사용하면 컴퓨팅 및 스토리지가 분리됩니다. 이를 통해 읽기 복제본(read replica)은 복제본 자체의 데이터를 유지하지 않고도 스토리지 계층에 대한 컴퓨팅 인터페이스로 작동 할 수 있습니다. 이렇게 하면 모든 데이터를 동기화 할 필요없이 인스턴스가 온라인 상태가 되는 즉시 읽기 복제본에서 트래픽 처리를 시작할 수 있습니다. 마찬가지로 읽기 복제본의 손실은 기본 데이터에 영향을 미치지 않습니다. 그리고 읽기 복제본이 마스터 노드가 되더라도 데이터 손실이 없습니다. Amazon Aurora는 최대 15개의 읽기 복제본을 지원하고, 읽기 복제본에 내장된 로드 밸런싱 기능을 통해 고 가용성 및 읽기 집약적인 워크로드에 이상적입니다.

 

참고: https://aws.amazon.com/ko/blogs/korea/databaseintroducing-the-aurora-storage-engine/

https://aws.amazon.com/ko/blogs/database/introducing-the-aurora-storage-engine/