이 글에서는 Amazone Aurora의 좀 더 자세한 구조에 대해서 설명합니다.
Amazone Aurora internal architecture 문서 소개
오로라 데이터베이스는 아마존의 클라우드 네이티브 데이터베이스입니다. 최대 64TB의 데이터를 저장할 수 있으며 MySQL 데이터베이스보다 5배 빠르다고 합니다. 많은 기업이 Aurora 데이터베이스를 채택했습니다.
이 글에서는 아마존 오로라 데이터베이스의 아키텍처를 소개합니다. 먼저 MySQL 데이터베이스와 같은 전통적인 관계형 데이터베이스 시스템의 아키텍처를 살펴보고 그 한계에 대해 논의할 것입니다. 그런 다음 오로라 데이터베이스가 기존 데이터베이스의 기능을 확장하여 가용성, 안정성 및 확장성을 개선하는 방법에 대해 설명합니다.
Architecture of a traditional database(기존 데이터베이스 아키텍처)
데이터베이스는 일반적으로 조직의 엔티티와 활동을 설명하는 데이터 모음입니다. 예를 들어 이커머스 데이터베이스에는 고객, 제품 및 판매에 대한 정보가 포함될 수 있습니다.
데이터베이스 관리 시스템(DBMS)은 이러한 데이터를 유지 관리하고 활용하도록 설계되었습니다. 구체적으로 DBMS는 일반적으로 다음과 같은 기능을 제공합니다.
- 데이터의 안정적인 저장.
- 데이터를 생성, 업데이트, 제거 및 쿼리할 수 있는 SQL 인터페이스.
- 트랜잭션 지원.
DBMS는 일반적으로 다음 그림과 같이 쿼리 평가 엔진, 트랜잭션 관리자, 파일 및 액세스 메서드, 버퍼 관리자 및 디스크 공간 관리자로 구성됩니다. 서로 다른 구성 요소가 함께 작동하는 방식을 설명하기 위해 두 가지 간단한 예를 사용하겠습니다.
예제 1: 데이터베이스에 쓰기
데이터베이스 테이블에 두 개의 행을 삽입하고자 하는 경우를 가정해 보겠습니다. 데이터베이스에 다음 명령을 실행합니다:
INSERT INTO task(title, priority) VALUES ("DBMS", 1), ("Aurora", 2);요청은 먼저 쿼리 평가 엔진으로 전달됩니다. 쿼리 평가 엔진은 SQL 명령을 구문 분석하여 해당 명령이 작업 테이블에 두 행을 삽입하는 것임을 이해합니다.
엔진 아래에 있는 3개의 레이어인 파일 및 액세스 메서드, 버퍼 관리자, 디스크 공간 관리자가 함께 작동하여 데이터를 디스크에 영구 저장합니다.
DBMS는 페이지라고 하는 고정된 크기로 디스크에서 데이터를 읽거나 디스크에 데이터를 씁니다. 페이지는 일반적으로 4KB 또는 8KB이며 DBMS의 구성 가능한 매개변수입니다.
각 페이지는 고유 ID인 페이지 ID와 연결됩니다. 각 데이터베이스 테이블 내부의 데이터는 몇 개의 페이지에 저장됩니다.
검색 속도를 높이기 위해 서로 다른 페이지에 데이터가 정렬됩니다.
예를 들어 페이지 1에는 [a, c] 범위의 키가 있는 행이 포함되어 있습니다.
2페이지는 [d, f] 범위의 키에 대한 페이지입니다.
DBMS는 페이지 뿐 아니라 디스크 내부에 데이터에 변경에 대한 변경 로그도 저장합니다. 변경 로그가 필요한 이유는 트랜잭션을 지원하고 복구하기 위해서 입니다. 또, 페이지를 하나의 트랜잭션이 변경하는 것이 아니므로 변경이 일어날 때마다 트랜잭션 단위로 페이지를 디스크에 기록할 수 없습니다. 그러므로, 여러 트랜잭션을 동시에 지원하기 위해서 변경로그를 필요로 합니다.
첫 번째 페이지가 디스크에 플러시된 후 DBMS에 장애가 발생하여 일관되지 않은 상태로 남을 수 있습니다. 따라서 먼저 디스크에 트랜잭션 단위로 플러시할 수 있는 변경 사항을 로그에 기록합니다. DBMS가 충돌하는 경우 변경 로그를 기반으로 상태를 재구성할 수 있습니다. 예시는 다음 단락을 참조하세요.
이 예제에서 DMBS는 1페이지에 행("Aurora", 1)을 삽입하고 5페이지에 행("DBMS", 2)을 삽입해야 한다는 것을 식별할 수 있습니다. 1페이지와 5페이지의 데이터를 수정하기 전에 DBMS는 먼저 변경 로그에 항목을 쓰고 이를 디스크에 플러시합니다.
Table: task
Operation: insert
데이터: ("Aurora", 1), ("DBMS", 2)데이터베이스를 부분적으로 업데이트한 후 DBMS에 장애가 발생하는 경우, 복구 관리자(Recovery Manager)는 변경 로그를 읽고 데이터베이스를 계속 업데이트(Redo)하여 두 행이 모두 삽입되었는지 확인합니다.
변경 로그가 디스크에 플러시된 후 DBMS는 1페이지에 ("Aurora",1)를 삽입하고 해당 페이지를 디스크에 플러시합니다. 그런 다음 5페이지에 행("DBMS",2)을 삽입하고 디스크에 플러시합니다.
이제 쓰기 작업이 성공적으로 완료되었으며 DBMS가 클라이언트 애플리케이션에 트랜잭션 완료를 반환 할 수 있습니다.
예제 2: 데이터베이스 쿼리
데이터베이스를 쿼리하는 단계도 비슷합니다. 다음 질의를 보겠습니다.
SELECT * FROM tasks WHERE title="Apache Flink";쿼리 실행 엔진이 먼저 명령을 구문 분석합니다. 그런 다음 DBMS는 데이터가 포함될 수 있는 페이지를 식별합니다. 이 경우, 페이지 1에 원하는 데이터가 있을 수 있습니다. 그런 다음 디스크 공간 관리자는 해당 페이지가 버퍼에 없는 경우 해당 페이지를 메모리로 읽습니다. 그런 다음 DBMS는 페이지에서 데이터를 검색하고 결과를 클라이언트 애플리케이션에 반환합니다.
기존 DBMS의 한계(Limitations of traditional DBMS)
기존 DBMS는 수십 년 동안 잘 작동해 왔으며 거의 모든 소프트웨어 애플리케이션의 핵심 구성 요소입니다. 그러나 클라우드가 등장하고 확장성, 안정성, 가용성에 대한 요구 사항이 높아지면서 기존 DBMS는 점차 기대에 부응하지 못하고 있습니다.
확장성
기존 DBMS는 단일 머신에서만 실행됩니다. 더 강력한 컴퓨터를 사용해야만 확장할 수 있습니다. 이 접근 방식은 비용이 많이 들고 확장성이 떨어집니다. 디스크가 지원하는 초당 입출력 작업 수(IOPS)가 시스템의 병목 현상이 될 수 있습니다.
신뢰성
기존 DBMS는 트랜잭션 로그와 같은 기술을 사용하여 안정성을 높이지만, 디스크가 손상되면 DBMS가 모든 데이터를 잃을 수 있습니다.
가용성
기존 Stand-alone DBMS는 가용성이 좋지 않습니다. 장비에 장애가 발생되면 장비가 고쳐지고 모든 DBMS 복구가 완료될 때까지 DBMS가 사용자 요청을 처리할 수 없습니다.
Aurora가 기존 데이터베이스를 개선하는 방법
Aurora 데이터베이스는 기존 오픈소스 DBMS(MySQL, PostgreSQL)를 기반으로 개발 및 구축 되었습니다. 쿼리 실행 엔진, 트랜잭션 관리자, 복구 관리자와 같은 기존 DBMS 내부의 구성 요소 대부분을 재사용합니다. (이것이 바로 이전 섹션에서 기존 DBMS의 아키텍처에 대해 설명한 이유입니다.)
그러나 가용성, 안정성, 확장성을 개선하기 위해 기존 DBMS를 몇 가지 개선했습니다. 이러한 변경 사항은 다음과 같습니다.
- 원격 스토리지에 데이터 복제
- 변경 로그만 원격 디스크에 저장
- primary-replica 구성 사용
Replication
Aurora가 가장 먼저 한 일은 로컬 디스크가 아닌 원격으로 데이터를 저장하는 것이었습니다. 아래 그림에서 볼 수 있듯이, Aurora 데이터베이스는 디스크 관리자를 확장하여 원격 저장소에서 처리할 수 있도록 합니다.
안정성을 높이기 위해 Aurora 데이터베이스는 데이터를 복제합니다. 일반적으로 데이터를 3개의 다른 데이터 센터에 6번 복제합니다. 이 정도의 복제 횟수로 사용자 데이터가 손실될 가능성은 거의 없습니다.
Aurora 데이터베이스는 1개의 가상 머신(Amazon EC2)을 사용하여 1개의 데이터 사본을 관리합니다. 데이터는 EC2 인스턴스의 로컬 디스크에 저장됩니다.
Aurora 데이터베이스는 3개의 다른 데이터 센터에 있는 6개의 EC2를 사용하여 복제된 데이터를 관리합니다.
그러나 이 설정에서 발생할 수 있는 한 가지 문제는 디스크 관리자가 데이터가 6개의 서로 다른 EC2로 성공적으로 전송되는지 확인해야 한다는 것입니다.
EC2 중 하나라도 느리거나 다른 요청을 처리하느라 바쁠 경우 지연 시간이 늘어날 수 있습니다. 인스턴스가 6개인 경우 인스턴스 중 하나가 느려질 가능성이 높으므로 지연 시간이 늘어날 가능성이 더 높습니다.
이 문제를 해결하기 위해 Aurora 데이터베이스는 사용자 애플리케이션으로 반환하기 전에 EC2의 하위 집합(일반적으로 4개)으로부터 응답을 받기만 하면 됩니다. 이를
EC2의 Vw 수라고 합니다. 읽기 작업에서도 마찬가지로, Aurora 데이터베이스는 EC2의 하위 집합인 Vr에서만 데이터를 가져옵니다.
Vw + Vr이 총 Replication 개수(6) 넘는 경우, 읽기 작업(Vr)이 이전에 Write한(Vw) 작업의 결과를 볼 수 있다고 보장 할 수 있습니다.
아래 그림에서 볼 수 있듯이, Write가 4노드에 되었고, 읽기는 3노드에서 한다면 Write한 데이터를 볼 수 있는 노드가 하나 이상 있다는 것이 보장됩니다. Vw = 4; Vr = 3.
이것이 Aurora 데이터베이스에서 사용되는 쿼럼 기반 복제 메커니즘이며, 관심 있는 분은 다음의 논문을 참조하여 자세한 내용을 확인할 수 있습니다. [Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases. In SIGMOD 2017]
데이터로서의 변경 로그(Transaction log)
Aurora 데이터베이스는 시스템을 더욱 효율적으로 만들기 위해 한 걸음 더 나아갑니다. 변경 로그를 원격 저장소에만 저장합니다. Write 예제에서 Aurora 데이터베이스는 변경 로그를 6개의 EC2 인스턴스에만 저장합니다.
아래 그림과 같이, Storage 영영을 담당하는 EC2 인스턴스가 변경 로그 저장 요청을 받으면 먼저 디스크의 변경 로그에 저장합니다. 그런 다음 변경 로그를 페이지에 적용합니다. 이렇게 하면 네트워크 대역폭을 크게 절약할 수 있습니다.
읽기 작업의 경우 기존 DBMS와 동일하게 작동합니다. 버퍼에 페이지를 사용할 수 없는 경우, 디스크 관리자는 EC2에 요청을 보내고 EC2는 페이지를 디스크 관리자에게 반환합니다.
기본-복제본 구성(Primary-replica configuration)
지금까지 Aurora 데이터베이스는 데이터의 안정성을 높였습니다. 그러나 데이터베이스의 성능은 여전히 단일 머신에 의해 제한됩니다.
시스템의 확장성을 높이기 위해 Aurora 데이터베이스는 아래 그림과 같이 기본 복제본 구성을 지원합니다. [아래 그림은 "Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases. In SIGMOD 2017"를 참고하였습니다.]
기본 인스턴스는 읽기 및 쓰기 요청을 모두 처리할 수 있습니다. 변경 로그는 3개의 서로 다른 데이터 센터에 있는 6개의 EC2 인스턴스 모두로 전송됩니다.
복제 인스턴스는 읽기 요청만 처리합니다. 페이지에 업데이트가 있을 때 기본 인스턴스는 복제 인스턴스에 알림을 보내 페이지가 오래되었음을 알립니다. 해당 페이지가 복제본 인스턴스의 버퍼 내에 있는 경우, 복제본 인스턴스는 해당 페이지를 버퍼에서 제거합니다. 복제 인스턴스가 읽기 요청을 받으면 해당 페이지가 버퍼에 없는 경우 EC2 인스턴스에 페이지를 가져오도록 요청을 보냅니다.
원격 스토리지를 사용하면 Aurora 데이터베이스는 인스턴스 간에 많은 조정 없이도 병렬로 실행되는 여러 인스턴스를 지원합니다. 기본 복제본 설정을 통해 Aurora 데이터베이스는 기존 DBMS보다 더 높은 처리량을 지원할 수 있습니다.
다음의 문서를 참고하여 작성하였습니다.
'DBMS' 카테고리의 다른 글
| PolarDB for PostgreSQL 오픈 소스 분석 - 아키텍처 (0) | 2023.11.25 |
|---|---|
| Alibaba PolarDB 오픈소스 파해치기 - github 분석 1 (0) | 2023.11.25 |
| alibaba cloud Polar DB - 알리바바 클라우드 폴라 디비 알아보기 (0) | 2023.11.25 |
| Amazon Aurora (Aurora) 알아보기 (0) | 2023.11.25 |
| 오라클(Oracle) 19c 클라이언트 설치 및 다운로드 - 우분투 linux | window 버전 링크 포함 (0) | 2023.11.24 |
