Amazon Aurora편집자 확인

Amazon Aurora의 가장 두드러진 설계 특징은 컴퓨팅 계층과 스토리지 계층을 물리적으로 분리한 아키텍처입니다. 기존의 전통적인 RDBMS는 데이터 파일, 로그 파일, 인덱스 등을 관리하는 스토리지 엔진이 데이터베이스 인스턴스와 긴밀하게 결합되어 동일한 서버에서 실행되는 것이 일반적이었습니다. 반면 Aurora는 이 개념을 재정의하여 데이터베이스 인스턴스(컴퓨팅 노드)가 쿼리 처리와 트랜잭션 관리를 담당하고, 데이터 자체는 전용의 분산형 스토리지 서비스에 저장됩니다.

이 분리된 스토리지 계층은 자동으로 확장되는 클라우드 스토리지 볼륨으로 구현됩니다. 데이터는 가용 영역에 걸쳐 최소 3개, 최대 6개의 복제본으로 자동 복제되어 저장됩니다. 컴퓨팅 인스턴스는 이 스토리지 계층과 네트워크를 통해 통신하며, 로그 구조화 방식을 채택하여 데이터 페이지 수준이 아닌 로그 레코드만 스토리지 계층으로 전송합니다. 스토리지 서비스는 이 로그 스트림을 수신하여 백그라운드에서 비동기적으로 데이터 페이지를 재구성하고 유지 관리합니다.

이러한 설계는 몇 가지 중요한 이점을 제공합니다. 첫째, 스토리지 용량은 애플리케이션의 필요에 따라 10GB 단위에서 최대 128TB까지 자동으로 확장되므로 용량 계획과 프로비저닝 오버헤드가 크게 줄어듭니다. 둘째, 컴퓨팅 인스턴스와 스토리지의 분리로 인해 읽기 및 쓰기 성능이 향상됩니다. 컴퓨팅 인스턴스는 버퍼 풀 캐시에 집중할 수 있고, 스토리지 계층은 복제본 간의 일관된 일관성과 내구성을 보장하는 복잡한 작업을 담당합니다. 마지막으로, 이 구조는 고가용성 설계의 기초가 됩니다. 컴퓨팅 인스턴스에 장애가 발생하더라도 데이터는 분산 스토리지에 안전하게 보관되며, 새로운 인스턴스가 몇 분 내에 동일한 스토리지 볼륨에 연결되어 빠르게 복구할 수 있습니다.

Amazon Aurora는 스토리지 계층 분리 아키텍처를 기반으로 한 고유한 복제 방식을 통해 높은 가용성을 제공한다. 전통적인 관계형 데이터베이스의 복제 방식과 달리, Aurora는 데이터를 스토리지 계층에 6개의 복제본으로 3개의 가용 영역에 분산 저장한다. 이는 내구성을 극대화하기 위한 설계이다. 데이터 쓰기 요청은 쿼럼 기반 시스템을 통해 처리되며, 6개 복제본 중 4개에 대한 쓰기 성공을 기준으로 한다. 이는 단일 또는 심지어 두 개의 가용 영역 장애가 발생하더라도 데이터 손실 없이 쓰기 가용성을 유지할 수 있음을 의미한다.

컴퓨팅 계층의 고가용성은 프라이머리 DB 인스턴스와 하나 이상의 Aurora 리플리카를 통해 구현된다. 프라이머리 DB 인스턴스에 장애가 발생하면, Aurora는 자동으로 장애 조치를 수행하여 Aurora 리플리카 중 하나를 새로운 프라이머리로 승격시킨다. 이 과정은 일반적으로 30초 이내에 완료되며, 애플리케이션의 다운타임을 최소화한다. Aurora 리플리카는 읽기 트래픽 분산을 위한 읽기 전용 복제본 역할도 동시에 수행한다.

이러한 복제 구조는 다양한 장애 시나리오로부터 시스템을 보호한다.

결과적으로, Aurora의 복제 및 고가용성 모델은 데이터 내구성과 서비스 연속성을 위한 다중 방어층을 구성한다. 스토리지 계층의 다중 AZ 복제는 데이터 손실 위험을 거의 제거하고, 컴퓨팅 계층의 자동 장애 조치는 애플리케이션 가용성을 유지한다. 사용자는 복잡한 복제 설정이나 페일오버 스크립트를 관리할 필요 없이 이러한 이점을 기본적으로 얻을 수 있다.

컴퓨팅 계층은 Amazon Aurora 클러스터에서 데이터베이스 인스턴스를 실행하는 계층이다. 이 계층은 애플리케이션의 연결을 처리하고 쿼리를 실행하며, 트랜잭션을 관리하는 역할을 담당한다. 컴퓨팅 리소스는 Amazon RDS와 유사한 DB 인스턴스 형태로 제공되며, 필요에 따라 인스턴스 유형을 선택하거나 스케일 업할 수 있다.

주요 구성 요소는 다음과 같다.

컴퓨팅 계층은 스토리지 계층과 완전히 분리되어 운영된다. 이는 데이터베이스 인스턴스를 재시작하거나 장애가 발생하더라도 데이터에 영향을 미치지 않으며, 인스턴스 교체나 업그레이드가 빠르게 이루어질 수 있음을 의미한다. 또한, 읽기 워크로드가 많은 경우 리더 인스턴스를 추가하여 쿼리 부하를 분산시키고 애플리케이션의 성능을 향상시킬 수 있다.

Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 관계형 데이터베이스 서비스로, 전통적인 클라우드 데이터베이스보다 최대 5배 높은 처리량을 제공하는 것을 목표로 설계되었다. 이 성능 향상은 로그 구조적 스토리지를 기반으로 한 혁신적인 아키텍처에서 비롯된다. 기존 데이터베이스는 디스크에 데이터 페이지를 쓰는 데 많은 입출력 작업이 필요하지만, Aurora는 스토리지 계층에 로그 레코드만 전달한다. 스토리지 노드가 로그를 받아 페이지를 재구성하고, 백그라운드에서 가비지 컬렉션을 수행함으로써 데이터베이스 엔진의 부담을 크게 줄인다.

확장성 측면에서 Aurora는 컴퓨팅과 스토리지를 독립적으로 확장할 수 있다. 컴퓨팅 리소스는 데이터베이스 인스턴스의 크기를 변경하여 수직적으로 확장한다. 스토리지는 최대 128TB까지 자동으로 확장되며, 사용량에 따라 용량이 증가한다. 읽기 성능을 확장하기 위해 최대 15개의 읽기 전용 복제본을 생성할 수 있다. 이 복제본들은 공유 스토리지를 사용하므로, 마스터 인스턴스에 부하를 주지 않고도 읽기 쿼리를 분산시킬 수 있다.

성능 최적화를 위한 몇 가지 주요 기능이 포함되어 있다. Aurora 병렬 쿼리 기능은 분석 쿼리를 여러 스토리지 노드에 분산하여 실행하여 스캔 및 집계 작업의 속도를 크게 향상시킨다. Aurora 글로벌 데이터베이스는 최대 1초 미만의 지연 시간으로 전 세계 여러 리전에 읽기 전용 복제본을 배포하여 글로벌 애플리케이션의 성능을 개선한다. 또한, 인 메모리 쿼리 가속을 지원하는 Aurora Accelerator를 통해 자주 접근하는 데이터에 대한 응답 시간을 더욱 단축할 수 있다.

Amazon Aurora는 클라우드 컴퓨팅 환경에서 데이터의 안전한 보관과 지속적인 접근을 보장하기 위해 설계된 내구성 및 가용성 메커니즘을 갖추고 있다. 핵심은 데이터를 가용 영역에 걸쳐 6개의 복제본으로 자동 복제하는 스토리지 시스템에 있다. 이 복제본들은 3개의 가용 영역에 각각 2개씩 분산 배치되어, 단일 가용 영역 전체 또는 스토리지 노드 다수의 장애에도 데이터 손실 없이 서비스를 유지할 수 있다. 쓰기 작업은 쿼럼 기반으로 4개 이상의 복제본에 성공적으로 기록되어야 커밋되므로, 높은 내구성이 보장된다.

가용성 측면에서는 기본 인스턴스에 장애가 발생할 경우, 자동 장애 조치 메커니즘을 통해 대기 중이던 Aurora 복제본 중 하나가 새로운 기본 인스턴스로 승격된다. 이 과정은 일반적으로 30초 이내에 완료되어 애플리케이션의 다운타임을 최소화한다. 또한 다중 AZ 배포를 기본으로 지원하여, 전체 데이터센터 수준의 장애로부터도 보호를 제공한다. 이러한 설계는 서비스 수준 계약으로 공식화되어 있으며, Aurora는 일반적으로 99.99%의 가용성을 보장한다.

데이터 보호를 위한 추가 기능으로 지속적 백업과 시점 복구가 포함된다. 자동 백업은 기본적으로 활성화되어 있으며, 지정된 보관 기간(기본 1일, 최대 35일) 내의 특정 시점으로 데이터베이스를 복원할 수 있다. 장기적인 데이터 보관 및 규정 준수를 위해 Aurora 스냅샷 기능을 사용할 수 있다. 스냅샷은 수동 또는 자동으로 생성 가능하며, Amazon S3에 저장되어 거의 무제한의 보관이 가능하다.

Amazon Aurora는 클라우드 컴퓨팅 환경에서 데이터베이스의 보안과 운영 관리를 단순화하는 여러 기능을 제공합니다. 기본적으로 AWS Identity and Access Management와 통합되어 데이터베이스 리소스에 대한 세밀한 접근 제어가 가능합니다. 네트워크 격리를 위해 Amazon Virtual Private Cloud 내에서 실행될 수 있으며, 전송 중 및 저장 중 데이터는 TLS 및 AES-256 암호화를 통해 보호됩니다. 자동으로 생성되고 관리되는 데이터베이스 백업은 기본적으로 암호화되며, AWS Key Management Service를 사용한 키 관리도 지원합니다.

관리 측면에서는 많은 운영 작업이 자동화되어 관리 부담을 줄입니다. 하드웨어 프로비저닝, 소프트웨어 패치 적용, 백업, 복구 작업은 대부분 AWS에서 처리합니다. 특히 자동 페일오버와 스토리지 자동 확장 기능은 고가용성과 성능 유지를 위해 중요한 역할을 합니다. 데이터베이스 성능에 대한 가시성을 제공하는 Amazon CloudWatch 및 Enhanced Monitoring과 같은 모니터링 도구와도 통합되어 있습니다.

이러한 통합된 접근 방식은 데이터 보호에 대한 규정 준수 요구사항을 충족시키는 동시에, 데이터베이스 관리자가 복잡한 인프라 관리보다 애플리케이션 개발과 비즈니스 로직에 더 집중할 수 있도록 합니다.

Amazon Aurora MySQL은 MySQL과 호환되는 관계형 데이터베이스 관리 시스템으로, Amazon Aurora의 두 가지 주요 데이터베이스 엔진 중 하나입니다. 이 엔진은 기존 MySQL 애플리케이션, 도구, 드라이버와의 높은 수준의 호환성을 제공하며, Aurora의 분산 아키텍처를 통해 향상된 성능과 내구성을 제공합니다. 사용자는 표준 MySQL 프로토콜과 API를 사용하여 데이터베이스에 연결하고 작업할 수 있습니다.

이 엔진은 MySQL 5.7 및 MySQL 8.0의 주요 버전과 호환됩니다. 호환성은 SQL 문법, 데이터 타입, 저장 프로시저, 트리거 등 광범위한 영역에 걸쳐 있습니다. 이를 통해 기존 MySQL 기반 애플리케이션을 최소한의 코드 변경으로 Aurora로 마이그레이션할 수 있습니다. 또한 MySQL Workbench, mysqldump, Percona XtraBackup과 같은 친숙한 관리 도구와 JDBC, ODBC와 같은 표준 커넥터를 계속 사용할 수 있습니다.

성능 측면에서 Aurora MySQL은 표준 MySQL을 실행하는 Amazon RDS 인스턴스보다 최대 5배 향상된 처리량을 제공할 수 있습니다[1]. 이는 로그 기반의 분산 스토리지 계층과 쿼리 실행을 위한 최적화된 컴퓨팅 계층 덕분입니다. 특히 쓰기 성능이 크게 개선되었으며, 읽기 전용 복제본을 추가함으로써 읽기 워크로드를 수평적으로 확장할 수 있습니다.

Amazon Aurora PostgreSQL은 PostgreSQL 오픈 소스 관계형 데이터베이스와 호환되는 Amazon Aurora의 두 가지 주요 엔진 유형 중 하나이다. 이 엔진은 PostgreSQL의 기능, 구문 및 도구와의 높은 수준의 호환성을 제공하면서 Aurora 아키텍처의 이점을 활용하도록 설계되었다. 사용자는 표준 PostgreSQL 연결 드라이버, 클라이언트 및 애플리케이션을 사용하여 Aurora PostgreSQL 데이터베이스에 연결할 수 있다.

이 엔진은 PostgreSQL의 핵심 기능을 지원하며, 동시에 Aurora의 분리된 스토리지 계층과 자동화된 복제를 통해 향상된 성능과 가용성을 제공한다. 예를 들어, Aurora 스토리지는 PostgreSQL 엔진에 최적화되어 있으며, 읽기 전용 복제본을 빠르게 추가하고 자동 장애 조치를 통해 고가용성을 보장한다. 또한, Aurora 글로벌 데이터베이스를 구성하여 여러 AWS 리전에 걸쳐 낮은 지연 시간의 읽기 및 재해 복구를 구현할 수 있다.

Aurora PostgreSQL은 특정 PostgreSQL 버전을 기반으로 하며, AWS는 정기적으로 새로운 주요 버전과 마이너 업데이트를 지원한다. 지원되는 기능에는 다음과 같은 것들이 포함된다.

이 엔진은 PostgreSQL 생태계에 익숙한 개발자와 조직이 클라우드 네이티브 애플리케이션을 구축하거나 기존 온프레미스 PostgreSQL 워크로드를 AWS로 마이그레이션할 때 널리 선택된다.

단일 마스터 배포 모델은 Amazon Aurora 클러스터에 하나의 쓰기 가능한 데이터베이스 인스턴스(마스터 인스턴스)와 최대 15개의 읽기 전용 복제본 인스턴스(리더 인스턴스)로 구성된다. 이 모델은 쓰기 작업이 단일 엔드포인트로 집중되고, 읽기 작업은 여러 복제본으로 분산되는 전통적인 마스터-슬레이브 아키텍처를 따른다. 쓰기 인스턴스는 모든 데이터 수정 작업(INSERT, UPDATE, DELETE)을 처리하며, 변경 사항은 스토리지 계층에 기록되고 비동기적으로 읽기 복제본들로 전파된다.

이 모델의 주요 장점은 구조의 단순성과 명확한 역할 분리이다. 애플리케이션은 쓰기용 연결 문자열과 읽기용 연결 문자열을 명시적으로 분리하여 사용할 수 있다. 읽기 복제본들은 읽기 전용 쿼리 부하를 분산시켜 마스터 인스턴스의 부담을 줄이고, 전체적인 처리량을 향상시킨다. 또한, 고가용성을 위해 마스터 인스턴스에 장애가 발생하면 아마존 RDS는 자동으로 읽기 복제본 중 하나를 새로운 마스터로 승격시키는 장애 조치를 수행한다.

단일 마스터 모델은 대부분의 애플리케이션에 적합하지만, 쓰기 작업의 확장성에는 한계가 있다. 모든 쓰기 트래픽이 하나의 인스턴스를 통해 이루어지기 때문에, 극도로 높은 쓰기 병목이 예상되거나 글로벌하게 분산된 애플리케이션에서 여러 지역에 걸쳐 낮은 지연 시간으로 쓰기를 수행해야 하는 경우에는 다중 마스터 배포 모델을 고려해야 한다.

Amazon Aurora의 다중 마스터 배포 모델은 단일 마스터 모델의 제약을 극복하기 위해 설계되었다. 이 모델에서는 모든 Aurora 인스턴스가 읽기와 쓰기 작업을 모두 처리할 수 있는 마스터 노드 역할을 한다. 각 인스턴스는 동일한 스토리지 볼륨에 직접 쓰기를 수행할 수 있으며, 이를 통해 애플리케이션의 여러 지점에서 거의 무제한에 가까운 쓰기 확장성을 제공한다. 이 아키텍처는 특히 쓰기 병목 현상이 발생하거나 단일 쓰기 노드 장애 시에도 쓰기 가용성을 유지해야 하는 워크로드에 적합하다.

다중 마스터 클러스터의 핵심은 분산 락 관리자이다. 이 구성 요소는 여러 마스터 노드 간의 데이터 일관성을 보장하며, 행 수준의 락을 관리하여 동시 쓰기 작업이 충돌 없이 안전하게 처리되도록 한다. 쓰기 요청은 어떤 마스터 노드로도 전송될 수 있으며, 해당 노드는 DLM을 통해 필요한 락을 획득한 후 Aurora 스토리지 계층에 직접 데이터를 기록한다. 이 과정은 네트워크 지연 시간을 최소화하고 처리량을 극대화한다.

주요 사용 사례와 장점은 다음과 같다.

이 모델은 모든 Aurora MySQL 호환 에디션에서 지원되지만, Aurora PostgreSQL 호환 에디션에서는 지원되지 않는다는 점에 유의해야 한다. 또한, 모든 애플리케이션이 다중 마스터의 이점을 필요로 하는 것은 아니므로, 쓰기 트래픽 패턴과 가용성 요구사항을仔細히 평가한 후 선택하는 것이 중요하다.

Amazon Aurora는 고가용성과 내구성, 그리고 예측 가능한 고성능을 요구하는 대규모 엔터프라이즈 애플리케이션의 핵심 데이터 계층으로 적합하다. 이러한 애플리케이션은 전자상거래 플랫폼, 금융 거래 시스템, ERP 시스템 등으로, 수천 건의 동시 트랜잭션을 처리하면서도 데이터 무결성과 지속적인 서비스 가용성을 보장해야 한다. Aurora의 분리된 스토리지 계층과 6방향으로 데이터를 복제하는 설계는 하드웨어 장애 시에도 데이터 손실 없이 자동 장애 조치를 가능하게 하여, 중요한 비즈니스 애플리케이션의 연속성을 보장한다.

성능 측면에서 Aurora는 OLTP 워크로드에 최적화되어 있다. 읽기 전용 복제본을 손쉽게 추가하여 보고서 생성이나 분석 쿼리와 같은 읽기 작업을 분리할 수 있어, 주요 트랜잭션 처리 성능에 영향을 주지 않는다. 또한, 자동 장애 조치 시간이 일반적으로 30초 미만으로 짧아 서비스 중단 시간을 최소화한다. 이는 고객-facing 애플리케이션에서 사용자 경험을 유지하는 데 결정적으로 중요하다.

관리 부담 감소 또한 엔터프라이즈 환경에서 주요 장점이다. Aurora는 백업, 패치 적용, 복제와 같은 일상적인 데이터베이스 관리 작업을 대부분 자동화한다. 또한 Amazon RDS와 호환되는 관리 도구를 사용할 수 있어, 기존 운영 방식을 크게 변경하지 않고도 마이그레이션과 관리를 수행할 수 있다. 이는 복잡한 인프라 관리에 리소스를 소모하기보다 핵심 비즈니스 로직 개발에 집중할 수 있게 한다.

Amazon Aurora는 다중 테넌트 아키텍처를 가진 SaaS 애플리케이션을 구축하는 데 적합한 데이터베이스 플랫폼을 제공합니다. SaaS 제공업체는 물리적 데이터베이스 인스턴스를 효율적으로 공유하면서도 각 테넌트의 데이터를 논리적으로 격리하고 성능을 보장해야 하는 과제에 직면합니다. Aurora의 아키텍처는 이러한 요구 사항을 해결하는 데 도움을 줍니다.

Aurora는 테넌트별 데이터베이스 클러스터를 쉽게 프로비저닝하고 관리할 수 있는 기능을 지원합니다. Aurora MySQL 및 Aurora PostgreSQL 엔진 모두에서 데이터베이스 수준의 격리를 기본적으로 제공하며, 각 테넌트를 별도의 데이터베이스로 할당할 수 있습니다. 성능 측면에서는 Aurora DB 클러스터의 자동 스케일링과 읽기 전용 복제본을 활용하여 특정 테넌트의 부하 증가에 대응할 수 있습니다. 또한, 다중 마스터 배포 모델을 사용하면 여러 테넌트가 동시에 쓰기 작업을 분산된 Aurora 인스턴스에 수행할 수 있어 쓰기 병목 현상을 줄일 수 있습니다.

관리 효율성을 위해 Aurora는 Amazon RDS API 및 AWS Management Console과 통합되어 테넌트 데이터베이스의 생명주기를 자동화하는 데 사용됩니다. AWS Lambda 및 AWS CloudFormation과 같은 서비스와 결합하면, 신규 테넌트 가입 시 데이터베이스 리소스를 자동으로 생성하고 구성하는 프로비저닝 파이프라인을 구현할 수 있습니다. 비용 최적화 측면에서는 Aurora Serverless v2를 고려할 수 있으며, 이는 사용량에 따라 컴퓨트 용량이 자동으로 조정되어 유휴 상태의 테넌트에 대한 비용을 절감하는 데 유용합니다.

이러한 특성으로 인해 Aurora는 테넌트 간 리소스 공유와 격리 사이의 균형을 유지해야 하는 SaaS 공급자에게 널리 채택되고 있습니다.

Amazon Aurora는 온라인 트랜잭션 처리(OLTP) 워크로드의 높은 성능 요구사항을 충족하도록 설계되었다. 전통적인 관계형 데이터베이스가 직면하는 디스크 I/O 병목 현상을 해결하기 위해, 로그 구조의 분산 스토리지 계층을 채택하여 데이터베이스 엔진과 스토리지를 분리한다. 이 아키텍처는 쓰기 작업을 지연 없이 저널에 기록하고, 읽기 작업은 SSD 기반의 스토리지 노드에서 병렬로 처리하여 높은 처리량과 낮은 지연 시간을 제공한다.

성능 최적화를 위해 쿼리 실행 계획 캐싱, 커넥션 풀링, 비동기 I/O와 같은 기법을 활용한다. 특히 Aurora MySQL과 Aurora PostgreSQL은 각각 호환되는 오픈 소스 엔진보다 향상된 성능을 제공하도록 튜닝되었다. 예를 들어, Aurora MySQL은 네트워크 통신 오버헤드를 줄이고 버퍼 풀 관리와 로그 버퍼 처리를 개선하여, 표준 Amazon RDS for MySQL에 비해 최대 5배 높은 처리량을 제공할 수 있다[4].

고성능 OLTP 환경에서의 주요 사용 패턴은 다음과 같다.

이러한 특성으로 인해 Amazon Aurora는 전자 상거래 플랫폼의 주문 처리, 금융 서비스의 실시간 거래, 모바일 게임의 사용자 상태 업데이트, 그리고 대화형 웹 애플리케이션의 백엔드 데이터베이스와 같이 지연 시간에 민감하고 초당 수천 건의 트랜잭션을 처리해야 하는 환경에서 널리 채택된다.