Amazon RDS 다중 AZ

Amazon RDS 다중 AZ는 RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle, RDS for Db2에서 사용할 수 있습니다. 읽기 가능한 대기가 2개인 Amazon RDS 다중 AZ는 RDS for PostgreSQL 및 RDS for MySQL에 사용할 수 있습니다. Amazon Aurora가 3개의 가용 영역에서 데이터 내구성을 확보하여 가용성을 향상시키는 방법을 알아보려면 Aurora 복제본을 사용한 다중 AZ 배포를 참조하세요.

단일 AZ 배포, 대기 인스턴스가 1개인 다중 AZ 배포 및 읽기 가능한 대기가 2개인 다중 AZ 배포의 경우 DB 인스턴스가 시작된 시간부터 중지되거나 삭제될 때까지 소비된 DB 인스턴스 시간당 요금이 부과됩니다. 부분적으로 사용된 DB 인스턴스 사용 시간 요금은 DB 인스턴스 클래스 생성, 시작 또는 수정 같은 청구 가능한 상태 변경에 따라 1초 단위로 청구되며 최소 10분의 요금이 부과됩니다.

Amazon RDS 다중 AZ 요금에 대한 자세한 내용은 Amazon RDS 요금 페이지를 참조하세요.

다음 사용 설명서와 자습서를 사용하여 Amazon RDS 다중 AZ를 빠르게 시작할 수 있습니다.

세션, 웨비나 및 기타 동영상을 시청하여 Amazon RDS 다중 AZ에 대해 자세히 알아보세요.

Amazon RDS 다중 AZ의 최근 개선 사항을 읽고 Amazon RDS 사용 사례에 이를 사용하는 방법을 자세히 알아보세요. 

Achieve one second or less of downtime with ProxySQL when upgrading Amazon RDS Multi-AZ deployments with two readable standbys(읽기 가능한 대기가 2개인 Amazon RDS 다중 AZ 배포를 업그레이드할 때 ProxySQL로 1초 미만의 가동 중단 시간 달성)

Fast switchovers with PgBouncer on Amazon RDS Multi-AZ deployments with two readable standbys for PostgreSQL(PostgreSQL용 읽기 가능한 대기가 2개인 Amazon RDS 다중 AZ 배포에서 PgBouncer로 빠르게 전환)

Achieve one second or less downtime with the Advanced JDBC Wrapper Driver when upgrading Amazon RDS Multi-AZ DB Clusters(Amazon RDS 다중 AZ DB 클러스터를 업그레이드할 때 고급 JDBC 래퍼 드라이버로 1초 미만의 가동 중단 시간 달성)

Perform minor version upgrades with a downtime of 1 second or less with Amazon RDS Proxy and Amazon RDS Multi-AZ deployments with two readable standbys(읽기 가능한 대기가 2개인 Amazon RDS 다중 AZ 배포 및 Amazon RDS 프록시를 사용하여 1초 미만의 가동 중단 시간으로 마이너 버전 업그레이드 수행)

Data consolidation for analytical applications using logical replication for Amazon RDS Multi-AZ clusters(Amazon RDS 다중 AZ 클러스터의 논리적 복제를 사용하여 분석 애플리케이션을 위한 데이터 통합)

Best strategies for achieving high performance and high availability on Amazon RDS for MySQL with Multi-AZ DB Clusters(다중 AZ DB 클러스터를 사용하여 Amazon RDS for MySQL에서 고성능 및 고가용성을 달성하기 위한 최상의 전략)

Improve application performance on Amazon RDS for MySQL and MariaDB instances and MySQL Multi-AZ DB clusters with Optimized Writes(최적화된 쓰기를 사용하여 Amazon RDS for MySQL 및 MariaDB 인스턴스와 MySQL 다중 AZ DB 클러스터의 애플리케이션 성능 개선)

Choose the right Amazon RDS deployment option: Single-AZ instance, Multi-AZ instance, or Multi-AZ database cluster(적합한 Amazon RDS 배포 옵션 선택: 단일 AZ 인스턴스, 다중 AZ 인스턴스 또는 다중 AZ 데이터베이스 클러스터)

Configure Multi-AZ with Amazon RDS Custom for SQL Server(Amazon RDS Custom for SQL Server로 다중 AZ 구성)

Deploy an Amazon RDS for PostgreSQL and MySQL Multi-AZ DB cluster using Terraform modules(Terraform 모듈을 사용하여 Amazon RDS for PostgreSQL 및 MySQL 다중 AZ DB 클러스터 배포)

New Amazon RDS for MySQL & PostgreSQL Multi-AZ Deployment Option: Improved Write Performance & Faster Failover(새로운 Amazon RDS for MySQL 및 PostgreSQL 다중 AZ 배포 옵션: 읽기 성능 및 장애 조치 속도 개선)

다중 AZ 배포로 실행되도록 DB 인스턴스를 생성 또는 수정하면 Amazon RDS가 다른 가용 영역에 동기식 ‘대기’ 복제본을 자동으로 프로비저닝하고 유지합니다. DB 인스턴스에 대한 업데이트는 가용 영역 전체에서 예비 복제본에 동기식으로 복제됩니다. 이는 양쪽의 동기화를 유지하고 DB 인스턴스 장애로부터 최신 데이터베이스 업데이트를 보호하기 위해서입니다.

특정 유형의 계획된 유지 관리를 수행하는 도중에, 또는 예기치 않은 DB 인스턴스 장애나 가용 영역 장애가 발생할 경우 Amazon RDS가 자동으로 예비 복제본으로 장애 조치하므로 예비 복제본이 승격되자마자 데이터베이스 쓰기 및 읽기를 재개할 수 있습니다. DB 인스턴스의 이름 레코드는 변경되지 않으므로 관리자가 직접 개입할 필요 없이 애플리케이션이 데이터베이스 작업을 재개할 수 있습니다. 다중 AZ 배포에서 복제본은 투명합니다. 사용자는 예비 복제본과 직접 상호 작용하지 않으며, 예비 복제본은 읽기 트래픽을 처리하는 데 사용될 수 없습니다. 다중 AZ 배포에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

가용 영역은 다른 가용 영역에서 발생한 장애를 격리하기 위해 만들어진 리전 내의 개별 장소입니다. 각 가용 영역은 물리적으로 분리된 자체 독립 인프라에서 실행되며 높은 안정성을 제공하도록 설계되었습니다. 발전기 및 냉각 장비와 같은 일반적인 장애 지점은 가용 영역 전체에서 공유되지 않습니다. 또한 물리적으로 분리되어 있어 화재, 태풍 또는 홍수와 같이 예기치 않은 자연 재해가 발생할 경우 단일 가용 영역만 영향을 받게 됩니다. 같은 리전에 있는 가용 영역은 지연 시간이 짧은 네트워크 연결을 제공합니다.

DB 인스턴스를 다중 AZ 배포로 실행할 경우 ‘프라이머리’가 데이터베이스 쓰기 및 읽기를 처리합니다. 또한 Amazon RDS는 백그라운드에서 기본 복제본의 최신 복제본인 "예비 복제본"을 프로비저닝하고 관리합니다. 예비 복제본은 장애 조치 시, “승격”됩니다. 장애 조치 후 예비 복제본이 기본 복제본이 되어 데이터베이스 작업을 수락합니다. 승격되기 전에는 어떠한 경우에도 대기 인스턴스를 사용할 수 없습니다(예: 읽기 작업의 경우). 단일 DB 인스턴스의 용량 한도 이상으로 읽기 트래픽을 확장하려는 경우 읽기 전용 복제본에 대한 FAQ를 참조하세요.

DB 인스턴스를 다중 AZ 배포로 실행할 경우 얻을 수 있는 주요 이점은 데이터베이스 내구성과 가용성의 향상입니다. 다중 AZ 배포가 제공하는 향상된 가용성과 내결함성 덕분에 다중 AZ 배포는 프로덕션 환경에 최적입니다.

DB 인스턴스를 다중 AZ 배포로 실행하면 DB 인스턴스 구성요소 장애 또는 한 가용 영역의 가용성 손실 등 예기치 않은 이벤트 발생 시 데이터를 보호할 수 있습니다. 예를 들어, 기본 복제본의 스토리지 볼륨에 장애가 발생할 경우 Amazon RDS가 자동으로 예비 복제본에 장애 조치를 수행하고 데이터베이스 업데이트는 예비 복제본에서 모두 완전한 상태로 유지됩니다. 이것은 단일 AZ의 표준 배포와 관련하여 추가 데이터 내구성을 제공합니다. 단일 AZ의 표준 배포에서는 사용자가 복구 작업을 시작해야 하고 복구 가능한 최근 시간(일반적으로 최근 5분 내) 후 발생한 업데이트는 사용할 수 없습니다.

DB 인스턴스를 다중 AZ 배포로 실행할 경우 향상된 데이터베이스 가용성을 활용할 수 있습니다. 가용 영역 장애 또는 DB 인스턴스 장애가 발생하면 자동 장애 조치가 완료되는 동안에만 가용성이 영향을 받습니다. 계획된 유지 관리에서도 다중 AZ의 가용성 이점을 활용할 수 있습니다.

예를 들어, 자동 백업을 사용하면 백업이 예비 복제본에서 수행되므로 기본 백업 기간 동안 기본 복제본에서 I/O 작업이 더 이상 중단되지 않습니다. 패치 적용 또는 DB 인스턴스 클래스를 확장하는 경우 이러한 작업은 자동 장애 조치 전에 예비 복제본에 먼저 적용됩니다. 결과적으로 가용성에 미치는 영향은 자동 장애 조치를 완료하는 데 필요한 시간으로 제한됩니다.

DB 인스턴스를 다중 AZ 배포로 실행할 경우 얻을 수 있는 또 다른 이점은 DB 인스턴스 장애 조치가 자동으로 수행되므로 관리가 필요하지 않다는 것입니다. Amazon RDS의 맥락에서 이는 가용 영역 장애 또는 DB 인스턴스 장애가 발생할 경우 DB 인스턴스 이벤트를 모니터링하고 수동으로 DB 인스턴스 복구를 수행(RestoreDBInstanceToPointInTime 또는 RestoreDBInstanceFromSnapshot API 사용)할 필요가 없음을 의미합니다.
 

고객을 대신해 수행하는 동기식 데이터 복제로 인해 단일 가용 영역에서 표준 DB 인스턴스 배포와 관련된 지연 시간이 증가할 수 있습니다.

다중 AZ DB 인스턴스 배포를 만들려면 AWS Management Console에서 DB 인스턴스를 시작할 때 ‘다중 AZ 배포’에서 ‘예’ 옵션을 클릭하면 됩니다.

또는 Amazon RDS API를 사용하는 경우 CreateDBInstance API를 직접적으로 호출하여 ‘Multi-AZ’ 파라미터 값을 ‘true’로 설정합니다. 기존의 표준(단일 AZ) DB 인스턴스를 다중 AZ로 전환하려면 AWS Management Console에서 DB 인스턴스를 수정하거나 ModifyDBInstance API를 사용하여 Multi-AZ 파라미터를 true로 설정합니다.
 

RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle 및 RDS for Db2 데이터베이스 엔진의 경우 Amazon RDS 인스턴스를 단일 AZ에서 다중 AZ로 변환하도록 선택하면 다음과 같은 프로세스가 수행됩니다.

• 프라이머리 인스턴스의 스냅샷이 생성됩니다.
• 다른 가용 영역에서 위의 스냅샷으로부터 새로운 대기 인스턴스가 생성됩니다.
• 기본 인스턴스와 대기 인스턴스 간에 동기식 복제가 구성됩니다.
  

이에 따라 인스턴스가 단일 AZ에서 다중 AZ로 전환될 때 가동 중단 시간이 발생하지 않습니다. 하지만 대기 인스턴스의 데이터가 프라이머리 인스턴스의 데이터와 일치하도록 업데이트되는 동안 지연 시간이 증가할 수 있습니다.

Amazon RDS는 다중 AZ 배포에 가장 일반적인 장애 시나리오를 감지하여 자동으로 복구하므로 관리자 개입 없이 데이터베이스 작업을 최대한 빨리 재개할 수 있습니다. Amazon RDS는 다음과 같은 이벤트가 발생하는 경우 장애 조치를 자동으로 수행합니다.

• 기본 가용 영역의 가용성 손실
• 기본 복제본에 대한 네트워크 연결 상실
• 기본 복제본의 컴퓨팅 장치 장애
• 기본 복제본의 스토리지 장애

참고: 다중 AZ 배포에서 DB 인스턴스 조정 또는 OS 패치와 같은 시스템 업그레이드 작업을 하는 경우 가용성을 향상하기 위해 자동 장애 조치 전에 먼저 예비 복제본에 해당 작업이 적용됩니다. 따라서 자동 장애 조치를 완료하는 데 걸리는 시간 동안에만 가용성에 영향을 주게 됩니다. Amazon RDS 다중 AZ 배포는 장시간 동작 쿼리, 교착 상태 또는 데이터베이스 손상 오류 같은 데이터베이스 동작에 대해서는 자동으로 장애 조치를 수행하지 않습니다.

예. Amazon RDS에서 자동 장애 조치가 발생했음을 알리는 DB 인스턴스 이벤트가 생성됩니다. Amazon RDS 콘솔의 "Events" 섹션을 클릭하거나 DescribeEvents API를 사용하여 DB 인스턴스와 관련된 이벤트 정보를 반환할 수 있습니다. 또한 Amazon RDS 이벤트 알림을 사용하여 특정 DB 이벤트가 발생할 때 알림을 받을 수 있습니다.

Amazon RDS를 통해 자동으로 장애 조치가 처리되므로 관리자 개입 없이 최대한 신속하게 데이터베이스 작업을 재개할 수 있습니다. 장애 조치 시, Amazon RDS는 DB 인스턴스의 정식 이름 레코드(CNAME)가 예비 복제본을 가리키도록 변경합니다. 그러면 이 예비 복제본이 승격되어 새 기본 복제본이 됩니다. 모범 사례에 따라 애플리케이션 계층에서 데이터베이스 연결을 다시 시도하는 것이 좋습니다.

기본 복제본에서 장애를 감지하고 예비 복제본에서 트랜잭션을 재개하는 데 걸리는 시간 간격으로 정의되는 장애 조치는 일반적으로 1~2분 내에 완료됩니다. 장애 조치 시간은 활발하게 사용되지 않는 대규모 트랜잭션의 복구 필요 여부에도 영향을 받습니다. 최상의 결과를 위해서는 다중 AZ와 함께 적당히 큰 인스턴스 유형을 사용하는 것이 좋습니다. 또한, 빠르고 예측 가능하며 일관된 처리량 성능을 위해 다중 AZ 인스턴스와 함께 프로비저닝된 IOPS를 사용하는 것이 좋습니다.

Amazon RDS는 다양한 장애 조건에 대해 사용자의 개입 없이 자동으로 장애 조치를 수행합니다. 또한 Amazon RDS는 인스턴스를 재시작할 때 장애 조치를 시작하는 옵션을 제공합니다. AWS Management Console을 사용하거나 RebootDBInstance API를 직접 호출하여 이 기능에 액세스할 수 있습니다.

다중 AZ 배포를 사용할 경우, ‘Multi-AZ’ 파라미터를 true로 설정하면 됩니다. 예비 복제본, 동기 복제 및 장애 조치 생성은 모두 자동으로 처리됩니다. 즉, 예비 복제본이 배포되는 가용 영역을 선택하거나 사용 가능한 예비 복제본의 수를 변경할 수 없습니다(Amazon RDS는 기본 DB 인스턴스당 하나의 전용 예비 복제본을 프로비저닝함). 또한 데이터베이스 읽기 작업을 허용하도록 대기 인스턴스를 설정할 수 없습니다. 다중 AZ 구성에 대해 자세히 알아보세요.

예. 대기 인스턴스는 프라이머리 DB 인스턴스와 동일한 리전의 다른 가용 영역에 자동으로 프로비저닝됩니다.

예. AWS Management Console 또는 DescribeDBInstances API를 사용하여 현재 프라이머리 인스턴스의 위치를 알 수 있습니다.

가용 영역은 같은 리전의 다른 가용 영역에 지연 시간이 짧은 네트워크 연결을 제공하도록 설계되었습니다. 또한 하나의 가용 영역에서 서비스 장애 발생 시, 애플리케이션이 회복력을 가질 수 있도록 여러 가용 영역 전체에 애플리케이션과 기타 AWS 리소스를 중복하여 저장할 수 있습니다. 다중 AZ 배포는 사용자의 관리 작업 없이 데이터베이스에서 이러한 요구를 해결합니다.

표준 배포를 단일 AZ 배포로 실행하든, 다중 AZ 배포로 실행하든 관계없이 동일한 방식으로 자동 백업과 DB 스냅샷 기능을 사용할 수 있습니다. 다중 AZ 배포를 실행할 경우 I/O가 기본 복제본에서 중단되지 않도록 자동 백업 및 DB 스냅샷이 예비 복제본에서 수행됩니다. 단일 또는 다중 AZ 배포의 백업 도중에 I/O 지연 시간(일반적으로 몇 분 덩인 지속)이 길어질 수 있습니다.

다중 AZ 배포를 사용할 경우 복원 작업(지정 시간 복구 또는 DB 스냅샷에서 복구) 실행도 표준 단일 AZ 배포와 동일하게 작동합니다. RestoreDBInstanceFromSnapshot 또는 RestoreDBInstanceToPointInTime API를 사용해 새로운 DB 인스턴스 배포를 만들 수 있습니다. 이 새 DB 인스턴스 배포는 표준 또는 다중 AZ가 될 수 있으며, 소스 백업이 표준 또는 다중 AZ 배포에서 시작되었는지는 여부는 관계가 없습니다.