Amazon Aurora FAQ

Amazon Aurora는 서버리스 및 기계 학습 기반 애플리케이션의 구축을 위한 규모에 따른 성능 및 고가용성, 완전한 오픈 소스 MySQL 및 PostgreSQL 호환 버전과 광범위한 개발자 도구를 제공하는 현대적 관계형 데이터베이스 서비스입니다.

Aurora는 컴퓨팅 리소스에서 분리되고 데이터베이스 인스턴스당 최대 128TiB까지 자동 스케일 업되는 내결함성을 갖춘 자가 복구 분산 스토리지 시스템을 제공합니다. 지연 시간이 짧은 읽기 전용 복제본 최대 15개, 특정 시점으로의 복구, Amazon Simple Storage Service(S3)로의 지속적 백업, 3개 가용 영역(AZ)에 걸친 복제를 통해 뛰어난 성능과 가용성을 제공합니다.

또한 Amazon Aurora는 하드웨어 프로비저닝, 데이터베이스 설정, 패치 적용 및 백업과 같은 시간 소모적인 관리 태스크를 자동화하는 동시에 1/10의 비용으로 상용 데이터베이스의 보안, 가용성 및 신뢰성을 제공하는 완전관리형 서비스입니다.

Amazon Aurora는 기존 MySQL 오픈 소스 데이터베이스와 완벽하게 호환되며 정기적으로 새 릴리스에 대한 지원을 추가합니다. 즉, 표준 가져오기/내보내기 도구 또는 스냅샷을 사용하여 MySQL 데이터베이스를 쉽게 Aurora로 마이그레이션하거나 Aurora에서 마이그레이션할 수 있습니다. 이는 또한 현재 MySQL 데이터베이스에서 이미 사용하고 있는 대부분의 코드, 애플리케이션, 드라이버 및 도구를 약간만 변경하거나 전혀 변경하지 않고 Aurora에서 사용할 수 있음을 의미합니다. 이를 통해 두 엔진 간에 애플리케이션을 쉽게 이동할 수 있습니다.

설명서에서 최신 Amazon Aurora MySQL 릴리스 호환성 정보를 확인할 수 있습니다.

Amazon Aurora는 기존 PostgreSQL 오픈 소스 데이터베이스와 완벽하게 호환되며 정기적으로 새 릴리스에 대한 지원을 추가합니다. 즉, 표준 가져오기/내보내기 도구 또는 스냅샷을 사용하여 PostgreSQL 데이터베이스를 쉽게 Aurora로 마이그레이션하거나 Aurora에서 마이그레이션할 수 있습니다. 이는 또한 현재 PostgreSQL 데이터베이스에서 이미 사용하고 있는 대부분의 코드, 애플리케이션, 드라이버 및 도구를 약간만 변경하거나 전혀 변경하지 않고 Aurora에서 사용할 수 있음을 의미합니다.

설명서에서 최신 Amazon Aurora PostgreSQL 릴리스 호환성 정보를 확인할 수 있습니다.

Amazon은 Aurora PostgreSQL과 Aurora를 통해 제공되는 모든 확장 프로그램을 완벽하게 지원합니다. Aurora PostgreSQL에 대한 지원이 필요한 경우 AWS Support에 문의하세요. 활성 AWS 프리미엄 서포트 계정이 있는 경우 AWS 프리미엄 서포트에 Amazon Aurora 관련 문제를 문의할 수 있습니다.

Amazon Aurora를 사용하려면 AWS Management Console에 로그인하고, 데이터베이스(Database) 범주 아래에서 RDS를 선택한 후, Amazon Aurora를 데이터베이스 엔진으로 선택합니다. 자세한 지침 및 리소스는 Aurora 시작하기 페이지를 확인하세요.

프로비저닝된 Aurora의 경우 온디맨드 인스턴스를 선택하고 장기 약정 또는 선불 요금 없이 시간당 데이터베이스 요금을 지불하거나 예약 인스턴스를 선택하여 추가로 요금을 절약할 수 있습니다. Aurora Serverless의 경우 애플리케이션 요구 사항에 따라 자동으로 시작 및 종료되고 확장 또는 축소되며 소비한 용량에 대한 요금만 지불합니다.

최신 요금 정보는 Aurora 요금 페이지를 참조하세요.

아니요. Amazon Aurora 복제는 요금에 포함되어 있습니다. 요금은 Amazon Aurora의 가상화 스토리지 계층에서 사용한 스토리지가 아니라 데이터베이스가 데이터베이스 계층에서 사용한 스토리지를 기준으로 부과됩니다.

여기에서 Amazon Aurora의 리전 가용성을 확인할 수 있습니다.

MySQL에서 Amazon Aurora로 마이그레이션하려는 경우(그리고 그 반대의 경우) 여러 옵션이 있습니다.

• 표준 mysqldump 유틸리티를 사용하여 MySQL에서 데이터를 내보내고 mysqlimport 유틸리티를 사용하여 Amazon Aurora로 데이터를 가져올 수 있습니다. 그 반대도 마찬가지입니다.
• 또한 AWS Management Console에서 Amazon RDS의 DB 스냅샷 마이그레이션 기능을 이용하여 Amazon RDS for MySQL DB 스냅샷을 Amazon Aurora로 마이그레이션할 수 있습니다.

대부분의 고객은 1시간 이내에 Aurora로의 마이그레이션을 완료하지만, 이 기간은 형식과 데이터 집합의 크기에 따라 달라집니다. 자세한 내용은 MySQL 데이터베이스를 Amazon Aurora로 마이그레이션하는 모범 사례를 참조하세요.

PostgreSQL에서 Amazon Aurora로 마이그레이션하려는 경우(그리고 그 반대의 경우) 여러 옵션이 있습니다.

• 표준 pg_dump 유틸리티를 사용하여 PostgreSQL에서 데이터를 내보내고 pg_restore 유틸리티를 사용하여 Amazon Aurora로 데이터를 가져올 수 있으며 그 반대도 마찬가지입니다.
• 또한 AWS Management Console에서 Amazon RDS의 DB 스냅샷 마이그레이션 기능을 이용하여 Amazon RDS for PostgreSQL DB 스냅샷을 Amazon Aurora로 마이그레이션할 수 있습니다.

대부분의 고객은 1시간 이내에 Aurora로의 마이그레이션을 완료하지만, 이 기간은 형식과 데이터 집합의 크기에 따라 달라집니다.

SQL Server 데이터베이스를 Aurora PostgreSQL 호환 버전으로 마이그레이션하려면 Babelfish for Aurora PostgreSQL을 사용하세요. 애플리케이션은 변경 없이 작동합니다. 자세한 내용은 Babelfish 설명서를 참조하세요.

현재는 지원되지 않습니다. Amazon RDS용 AWS 프리 티어는 마이크로 DB 인스턴스의 이점을 제공하지만 Amazon Aurora는 현재 마이크로 DB 인스턴스 지원을 제공하지 않습니다. 최신 요금 정보는 Aurora 요금 페이지를 참조하세요.
Amazon Aurora를 사용하려면 AWS Management Console에 로그인하고, 데이터베이스(Database) 범주 아래에서 RDS를 선택한 후, Amazon Aurora를 데이터베이스 엔진으로 선택합니다.

I/O는 Aurora 데이터베이스 엔진에서 Solid State Drive(SSD) 기반 가상화 스토리지 계층에 대해 수행하는 입/출력 작업입니다. 모든 데이터베이스 페이지 읽기 작업은 1건의 I/O로 계산됩니다.

Aurora 데이터베이스 엔진은 캐시의 메모리에 없는 데이터베이스 페이지를 가져오기 위해 스토리지 계층에 대한 읽기를 실행합니다.

• 쿼리 트래픽을 메모리 또는 캐시에서 모두 처리할 수 있는 경우 메모리에서 데이터 페이지를 검색하는 요금이 부과되지 않습니다.
• 쿼리 트래픽을 메모리에서 완전히 처리할 수 없는 경우 스토리지에서 검색해야 하는 데이터 페이지에 대한 요금이 부과됩니다.

각 데이터베이스 페이지는 Aurora MySQL 호환 버전에서 16KB이고, Aurora PostgreSQL 호환 버전에서 8KB입니다.

Aurora는 비용을 절감하고 읽기/쓰기 트래픽을 위해 사용할 수 있는 리소스를 확보하기 위해 불필요한 I/O를 제거하도록 설계되었습니다. 쓰기 I/O는 쓰기 내구력을 위해 Aurora MySQL 호환 버전의 다시 실행 로그 레코드 또는 Aurora PostgreSQL 호환 버전의 선행 기록 로그 레코드를 스토리지 계층에 유지하는 경우에만 소비됩니다.

쓰기 I/O는 4KB 단위로 계산됩니다. 예를 들어 1,024바이트 크기의 로그 기록은 1건의 쓰기 I/O 작업으로 계산됩니다. 그러나 로그 레코드가 4KB를 초과하는 경우 해당 레코드를 유지하는 데 쓰기 I/O 작업 1건 이상이 필요합니다.

로그 레코드가 4KB 미만인 동시 쓰기 작업은 동일한 스토리지 보호 그룹에 유지되는 경우 I/O 소비를 최적화하기 위해 Aurora 데이터베이스 엔진에서 배치 처리될 수 있습니다. 기존의 데이터베이스 엔진과 달리 Aurora는 더티 데이터 페이지를 스토리지로 플러시하지 않습니다.

Aurora 인스턴스가 얼마나 많은 I/O 요청을 사용하는지는 AWS Management Console에서 확인할 수 있습니다. I/O 사용량을 확인하려면 콘솔의 Amazon RDS 섹션에서 인스턴스 목록을 찾아, Aurora 인스턴스를 선택한 후 모니터링 섹션에서 ‘결제된 읽기 작업(Billed read operations)’ 및 ‘결제된 쓰기 작업(Billed write operations)’ 지표를 보면 됩니다.

아니요. Amazon Aurora는 표준 PostgreSQL 데이터베이스 드라이버에서 작동합니다.

Amazon Aurora는 데이터베이스 워크로드용으로 구축한 SSD 기반 가상 스토리지 계층과 데이터베이스 엔진을 긴밀하게 통합하여 스토리지 시스템으로의 쓰기를 줄이고 잠금 경합을 최소화하며 데이터베이스 프로세스 스레드에서 생성된 지연을 제거함으로써 MySQL의 성능을 대폭 향상했습니다.

r3.8xlarge 인스턴스에서 SysBench로 테스트한 결과 Amazon Aurora는 초당 조회 500,000 SELECT와 초당 UPDATE 100,000회를 제공하며, 이는 동일한 하드웨어에서 동일한 벤치마크를 실행하는 MySQL보다 5배 높은 수치입니다. 이 벤치마크에 대한 자세한 지침과 직접 복제하는 방법은 Amazon Aurora MySQL 호환 버전 성능 벤치마킹 가이드에 나와 있습니다.

Amazon Aurora는 데이터베이스 워크로드용으로 구축한 SSD 기반 가상 스토리지 계층과 데이터베이스 엔진을 긴밀하게 통합하여 스토리지 시스템으로의 쓰기를 줄이고 잠금 경합을 최소화하며 데이터베이스 프로세스 스레드에서 생성된 지연을 제거함으로써 PostgreSQL의 성능을 대폭 향상했습니다.

r4.16xlarge 인스턴스에서 SysBench로 테스트한 결과 Amazon Aurora는 동일한 하드웨어에서 동일한 벤치마크를 실행하는 PostgreSQL보다 3배 높은 초당 SELECT 수와 초당 UPDATE 수를 제공합니다. 이 벤치마크에 대한 자세한 지침과 직접 복제하는 방법은 Amazon Aurora PostgreSQL 호환 버전 성능 벤치마킹 가이드에 나와 있습니다.

Amazon Aurora는 MySQL과 호환되도록 설계되었으므로 기존 MySQL 애플리케이션과 도구를 수정하지 않고도 실행할 수 있습니다. 하지만 Amazon Aurora가 MySQL보다 뛰어난 점 중 하나는 동시에 처리하는 워크로드가 많다는 것입니다. Amazon Aurora에서 워크로드의 처리량(throughput)을 극대화하기 위해서는 다수의 동시 쿼리와 트랜잭션을 수행하도록 애플리케이션을 구축하는 것이 좋습니다.

Amazon Aurora는 PostgreSQL과 호환되도록 설계되었으므로 기존 PostgreSQL 애플리케이션과 도구를 수정하지 않고도 실행할 수 있습니다. 하지만 Amazon Aurora가 PostgreSQL보다 뛰어난 점 중 하나는 동시에 처리하는 워크로드가 많다는 것입니다. Amazon Aurora에서 워크로드의 처리량(throughput)을 극대화하기 위해서는 다수의 동시 쿼리와 트랜잭션을 수행하도록 애플리케이션을 구축하는 것이 좋습니다.

최소 스토리지는 10GB입니다. 데이터베이스 사용량에 따라 Amazon Aurora 스토리지는 데이터베이스 성능에 영향을 미치지 않고 최대 128TiB까지 10GB 단위로 자동으로 늘어납니다. 스토리지를 미리 프로비저닝할 필요가 없습니다.

내 Amazon Aurora DB 인스턴스에 연결된 컴퓨팅 리소스는 Aurora Serverless와 수동 조정을 사용하는 2가지 방법으로 크기를 조정할 수 있습니다.

Amazon Aurora에 대한 온디맨드 자동 크기 조정 구성 버전인 Aurora Serverless를 사용해 애플리케이션 요구에 따라 데이터베이스 컴퓨팅 리소스의 크기를 조정할 수 있습니다. Aurora Serverless를 사용하면 데이터베이스 용량 관리를 걱정하지 않고도 클라우드에서 데이터베이스를 실행할 수 있습니다. 원하는 데이터베이스 용량 범위를 지정하면 애플리케이션의 요구에 따라 데이터베이스의 크기가 조정됩니다. Aurora Serverless 사용 설명서에서 자세한 내용을 읽어보세요.

AWS Management Console에서 원하는 DB 인스턴스 유형을 선택하여 데이터베이스에 연결된 컴퓨팅 리소스의 크기를 수동으로 조정할 수도 있습니다. 요청하시는 변경 사항은 지정된 유지 관리 기간 동안 적용되지만, ‘즉시 적용(Apply Immediately)’ 플래그를 사용해 DB 인스턴스 유형을 즉시 변경할 수도 있습니다.

이 두 옵션은 사용 시 크기 조정 작업이 수행되는 몇 분 동안 가용성에 영향을 미칩니다. 처리되지 않은 다른 시스템 변경 내용도 함께 적용됩니다.

Amazon Aurora DB 인스턴스에는 자동화된 연속 백업이 항상 활성화되어 있습니다. 백업은 데이터베이스 성능에 영향을 미치지 않습니다.

예. 그리고 스냅샷을 만드는 동안 성능에 영향을 미치지 않습니다. DB 스냅샷으로 데이터를 복원하려면 새 DB 인스턴스를 만들어야 합니다.

Amazon Aurora는 자동으로 3개의 가용 영역(AZ)에 6개의 데이터 사본을 유지 관리하며, 데이터가 손실되지 않은 정상 AZ의 데이터베이스를 자동으로 복구합니다. Amazon Aurora 스토리지 내에서 데이터를 사용할 수 없는 상황이 예기치 않게 발생하면 DB 스냅샷으로 복원하거나 새 인스턴스에 특정 시점으로 복원 작업을 수행할 수 있습니다. 특정 시점 복원 작업의 최근 복원 가능 시간은 최대 5분 전입니다.

DB 인스턴스를 삭제할 때 최종 DB 스냅샷을 만들 수 있습니다. DB 스냅샷을 만들면 이를 사용하여 삭제된 DB 인스턴스를 나중에 복원할 수 있습니다. Amazon Aurora는 최종 사용자 생성 DB 스냅샷을 DB 인스턴스 삭제 후에 수동으로 생성한 모든 다른 DB 스냅샷과 함께 보관합니다. DB 인스턴스가 삭제된 후에는 DB 스냅샷만 보관됩니다. 예를 들어, 특정 시점으로 복원하기 위해 생성한 자동화된 백업은 유지되지 않습니다.

예. Aurora는 데이터베이스 스냅샷을 생성할 수 있는 기능을 제공하며, 이 스냅샷은 나중에 데이터베이스를 복원하는 데 사용할 수 있습니다. 다른 AWS 계정과 스냅샷을 공유할 수 있으며, 수신 계정의 소유자는 사용자의 스냅샷을 사용하여 사용자의 데이터가 포함된 DB를 복원할 수 있습니다. 스냅샷을 퍼블릭으로 설정할 수도 있습니다. 즉, 누구나 사용자의 (퍼블릭) 데이터가 포함된 DB를 복원할 수 있습니다.

이 기능을 사용하면 AWS 계정이 서로 다른 다양한 환경(프로덕션, 개발 및 테스트, 스테이징 등) 간에 데이터를 공유할 수 있고, 기본 AWS 계정이 손상될 경우에 대비하여 별도의 계정에 모든 데이터 백업을 안전하게 유지할 수 있습니다.

계정 간에 스냅샷을 공유하는 데는 비용이 부과되지 않습니다. 하지만 스냅샷 자체와 공유된 스냅샷에서 복원한 데이터베이스에는 비용이 부과될 수 있습니다. Aurora 요금에 대해 자세히 알아보세요.

DB 스냅샷의 자동 공유는 지원되지 않습니다. 스냅샷을 공유하려면 수동으로 스냅샷 복사본을 생성한 다음, 해당 복사본을 공유해야 합니다.

수동 스냅샷은 최대 20개의 AWS 계정 ID와 공유할 수 있습니다. 20개가 넘는 계정과 스냅샷을 공유하려는 경우, 스냅샷을 퍼블릭으로 설정하거나 Support에 한도 증가를 요청할 수 있습니다.

Aurora를 사용할 수 있는 각 AWS 리전 내에서 Aurora 스냅샷을 공유할 수 있습니다.

아니요. Aurora 스냅샷은 이를 공유하는 계정과 같은 리전에 있는 계정에서만 액세스할 수 있습니다.

예. 암호화된 Aurora 스냅샷을 공유할 수 있습니다.

Amazon Aurora는 데이터베이스 볼륨을 10GB 세그먼트로 자동으로 분리하여 여러 디스크에 분산합니다. 데이터베이스 볼륨에서 각 10GB 청크가 3개의 AZ에 6가지 방법으로 복제됩니다. Amazon Aurora는 데이터베이스 쓰기 가용성에 영향을 주지 않고 최대 2개의 데이터 사본 손실을 처리하고 읽기 가용성에 영향을 주지 않고 최대 3개의 사본 손실을 투명하게 처리하도록 설계되었습니다.

또한 Amazon Aurora 스토리지에는 자가 복구 기능이 있습니다. 데이터 블록과 디스크에 오류가 있는지 계속 스캔하고 오류가 있는 경우 자동으로 복구됩니다.

다른 데이터베이스와 달리 데이터베이스 오류가 발생한 후 Amazon Aurora는 데이터베이스를 작업에 사용하기 전에 마지막 데이터베이스 검사점의 다시 실행 로그를 리플레이하여(대개 5분) 모든 변경 사항이 적용되었는지 확인할 필요가 없습니다. 따라서 대부분의 경우 데이터베이스 재시작 시간이 60초 미만으로 줄어듭니다.

Amazon Aurora는 데이터베이스 프로세스에서 버퍼 캐시를 이동하여 재시작 즉시 사용할 수 있도록 합니다. 이렇게 하면 캐시가 다시 채워질 때까지는 액세스를 제한할 필요가 없어 중단이 방지됩니다.

Amazon Aurora MySQL 호환 버전과 Amazon Aurora PostgreSQL 호환 버전에서는 같은 AWS 리전에서 프라이머리 인스턴스와 동일한 기본 볼륨을 공유하는 Amazon Aurora 복제본을 지원합니다. 프라이머리 인스턴스에서 수행한 업데이트는 모든 Amazon Aurora 복제본에 표시됩니다.

또한 Amazon Aurora MySQL 호환 버전에서는 MySQL의 binlog 기반 복제 엔진을 토대로 교차 리전 MySQL 읽기 전용 복제본을 생성할 수 있습니다. MySQL 읽기 전용 복제본의 프라이머리 인스턴스 데이터는 복제본에서 트랜잭션으로 리플레이됩니다. 대부분의 경우 읽기 조정과 고가용성 기능이 포함된 Amazon Aurora 복제본을 사용하는 것이 좋습니다.

애플리케이션의 필요에 따라 다음과 같이 두 복제본 유형을 유연하게 혼합할 수 있습니다.

위에 열거된 복제 옵션 이외에 2개의 옵션이 더 있습니다. Amazon Global Database를 사용하여 다른 리전의 Aurora 클러스터 간에 물리적 복제를 훨씬 빠르게 수행할 수 있습니다. Aurora 및 비 Aurora MySQL 호환 버전 데이터베이스 간(AWS의 외부도 동일함) 복제에서는 자체 관리형 binlog 복제를 직접 설정할 수 있습니다.

예. 물리적 또는 논리적 복제를 사용하여 교차 리전 Aurora 복제본을 설정할 수 있습니다. Amazon Aurora Global Database라는 물리적 복제에서는 데이터베이스를 애플리케이션 지원에 전적으로 사용할 수 있는 전용 인프라를 사용하며, 일반적으로 1초 미만의 대기 시간으로 최대 5개의 보조 리전에 복제할 수 있습니다. Aurora MySQL 호환 버전과 Aurora PostgreSQL 호환 버전 모두에서 사용할 수 있습니다.

짧은 대기 시간의 글로벌 읽기 및 재해 복구를 위해서는 Amazon Aurora Global Database를 사용하는 것이 좋습니다.
Aurora는 각 데이터베이스 엔진에서 네이티브 논리적 복제본을 지원하므로(MySQL의 경우 binlog, PostgreSQL의 경우 PostgreSQL 복제 슬롯) 리전 사이에서도 Aurora와 Aurora가 아닌 데이터베이스에 복제할 수 있습니다.

또한, Aurora MySQL 호환 버전은 최대 5개의 보조 AWS 리전을 지원하는 간편한 논리적 교차 리전 읽기 전용 복제본 기능을 제공합니다. 이는 단일 스레드 MySQL binlog 복제를 기반으로 하므로, 복제 지연 시간은 변경/적용률과 선택한 특정 리전 간의 네트워크 통신 지연에 따라 달라집니다.

예. 각 교차 리전 클러스터에 최대 15개의 Aurora 복제본을 추가할 수 있으며, 이러한 복제본은 교차 리전 복제본과 동일한 기본 스토리지를 공유합니다. 교차 리전 복제본은 클러스터에서 프라이머리 복제본의 역할을 하며, 클러스터의 Aurora 읽기 전용 복제본은 프라이머리 복제본보다 일반적으로 수십 밀리초 지연됩니다.

예. Amazon RDS 콘솔에서 교차 리전 복제본을 새로운 프라이머리 복제본으로 승격할 수 있습니다. 논리적(binlog) 복제의 경우, 승격 프로세스는 워크로드에 따라 다르지만 보통 몇 분 정도 걸립니다. 승격 프로세스를 시작하면 교차 리전 복제가 중단됩니다.

Amazon Aurora Global Database의 경우 모든 읽기/쓰기 워크로드를 처리하도록 보조 리전을 승격하는 데 1분이 채 걸리지 않습니다.

예. 클러스터의 각 인스턴스에 승격 우선순위 티어를 지정할 수 있습니다. 기본 인스턴스에 장애가 발생하면, Amazon RDS는 가장 우선순위가 높은 복제본을 기본 인스턴스로 승격시킵니다. 우선 순위가 같은 Aurora 복제본이 2개 이상 있는 경우 Amazon RDS는 크기가 가장 큰 복제본을 승격시킵니다. 우선 순위와 크기가 같은 Aurora 복제본이 2개 이상 있는 경우 Amazon RDS는 동일한 프로모션 티어에 있는 임의의 복제본을 승격시킵니다.

장애 조치 로직에 관한 자세한 정보는 Amazon Aurora 사용 설명서를 참조하세요.

예. 언제든 인스턴스에 대한 우선순위 티어를 변경할 수 있습니다. 우선순위 티어를 수정하는 것만으로 장애 조치가 트리거되지 않습니다.

프라이머리 인스턴스로 승격되기를 원하지 않는 복제본에 낮은 우선순위 티어를 지정할 수 있습니다. 하지만 클러스터에서 우선순위가 더 높은 복제본이 비정상이거나 어떤 이유로 사용할 수 없는 경우, Amazon RDS가 우선순위가 낮은 복제본을 승격시키게 됩니다.

Amazon Aurora 복제본을 추가할 수 있습니다. 동일한 AWS 리전의 Aurora 복제본은 기본 인스턴스와 동일한 기본 스토리지를 공유합니다. 모든 Aurora 복제본은 데이터 손실 없이 기본 복제본으로 승격될 수 있으므로 프라이머리 DB 인스턴스에 장애가 발생하는 경우 내결함성 향상에 사용될 수 있습니다.

데이터베이스 가용성을 높이려면 3개의 가용 영역에 1~15개의 복제본을 만들면 됩니다. 그러면 데이터베이스가 중단되는 경우 Amazon RDS가 자동으로 이러한 복제본을 장애 조치 기본 선택에 포함합니다. 데이터베이스를 여러 AWS 리전에 걸쳐 확장하려는 경우 Amazon Aurora Global Database를 사용하면 됩니다. 그러면 데이터베이스 성능에 전혀 영향을 주지 않고 데이터를 복제하고 리전 규모의 가동 중단 발생 시 재해 복구를 제공할 수 있습니다.

Amazon Aurora는 자동으로 장애 조치를 처리하므로, 관리자가 개입하지 않아도 애플리케이션이 최대한 신속하게 데이터베이스 작업을 재개할 수 있습니다.

• Amazon Aurora 복제본이 동일한 가용 영역 또는 다른 가용 영역에 있는 경우 장애 조치가 진행될 때 Aurora는 DB 인스턴스의 Canonical Name Record(CNAME)이 정상적인 복제본을 가리키도록 이를 변경하며, 해당 복제본은 승격되어 새로운 프라이머리 복제본이 됩니다. 일반적으로 장애 조치는 처음부터 끝까지 30초 이내에 완료됩니다. 
• Aurora Serverless v1 및 DB 인스턴스를 실행하거나 AZ를 사용할 수 없게 될 경우, Aurora는 다른 AZ에서 DB 인스턴스를 자동으로 다시 생성합니다. Aurora Serverless v2는 장애 조치 및 기타 고가용성 기능을 위해 프로비저닝된 것처럼 작동합니다. 자세한 정보는 Aurora Serverless v2 및 고가용성을 참조하세요. 
• Amazon Aurora 복제본(즉, 단일 인스턴스)이 없고 Aurora Serverless를 실행하지 않는 경우, Aurora는 원래 인스턴스와 동일한 가용 영역에 새 DB 인스턴스를 생성하려고 시도합니다. 이와 같은 원래 인스턴스 대체가 최선의 방법이며, 가용 영역에 크게 영향을 주는 문제가 발생하는 경우 등에는 성공하지 못할 수도 있습니다.
  

데이터베이스 연결이 끊어진 경우 애플리케이션 연결을 다시 시도해야 합니다. 여러 리전에 걸친 재해 복구는 수동 프로세스이므로 읽기/쓰기 워크로드를 처리하도록 보조 리전을 승격해야 합니다.

Amazon Aurora는 프라이머리 인스턴스와 관련된 문제를 자동으로 감지하고 장애 조치를 트리거합니다. 클러스터 엔드포인트를 사용하는 경우 읽기/쓰기 연결은 기본으로 승격된 Amazon Aurora 복제본에 자동으로 재지정됩니다.

또한, Aurora 복제본에서 처리하던 읽기 트래픽이 잠시 중단됩니다. 클러스터 리더 엔드포인트를 사용하여 읽기 트래픽을 Aurora 복제본으로 지정하는 경우 이전 프라이머리 노드가 복제본으로 복구되기 전까지 읽기 전용 연결만 새로 승격된 Aurora 복제본으로 지정됩니다.

Amazon Aurora 복제본은 같은 AWS 리전의 프라이머리 인스턴스와 동일한 데이터 볼륨을 공유하므로 사실상 복제 지연이 발생하지 않습니다. 일반적인 지연 시간은 수십 밀리초 이내입니다.

교차 리전 복제의 경우 변경/적용 비율과 네트워크 통신의 지연에 따라 binlog 기반 논리적 복제의 지연 시간이 무제한 증가할 수 있습니다. 하지만 일반적인 조건에서는 대개 1분 이내의 복제 지연이 발생합니다. Amazon Aurora Global Database의 물리적 복제를 사용한 교차 리전 복제본은 일반적으로 지연 시간이 1초 미만입니다.

예. Aurora MySQL 호환 버전 인스턴스와 외부 MySQL 데이터베이스 간에 binlog 복제를 설정할 수 있습니다. 다른 데이터베이스를 Amazon RDS에서 실행하거나, AWS에서 자체 관리형 데이터베이스로 실행하거나, 완전히 AWS의 외부에서 실행할 수 있습니다.

Aurora MySQL 호환 버전 5.7을 실행하는 경우에는 GTID 기반 binlog 복제의 설정을 검토하세요. 그러면 완벽한 일관성을 통해 장애 조치 또는 가동 중단이 발생한 경우에도 복제 시 트랜잭션이 손실되거나 충돌이 발생하지 않습니다.

Amazon Aurora Global Database는 단일 Amazon Aurora 데이터베이스를 여러 AWS 리전으로 확장할 수 있는 기능입니다. 데이터베이스 성능에 전혀 영향을 주지 않고 데이터를 복제하고, 각 리전에서 보통 1초 미만의 짧은 대기 시간으로 빠른 로컬 읽기를 지원하며, 리전 규모의 가동 중단 발생 시 재해 복구를 제공합니다. 리전의 성능 저하 또는 가동 중단이 드문 일이긴 하지만 이러한 상황이 발생하는 경우, 보조 리전 중 하나가 1분 이내에 전체 읽기/쓰기를 처리하도록 승격될 수 있습니다. 이 기능은 Aurora MySQL 호환 버전과 Aurora PostgreSQL 호환 버전 모두에서 사용할 수 있습니다.

Amazon RDS 콘솔에서 단 몇 번의 클릭으로 Aurora Global Database를 생성할 수 있으며, 또는 AWS 소프트웨어 개발 키트(SDK) 또는 AWS Command Line Interface(CLI)를 사용할 수 있습니다. Amazon Aurora Global Database에서 리전당 하나 이상의 인스턴스를 프로비저닝해야 합니다.

Amazon Aurora Global Database 하나에 보조 리전을 최대 5개까지 생성할 수 있습니다.

예. 데이터베이스 활동을 분석하는 것이 목적이라면, 데이터베이스 성능에 영향을 주지 않도록 Aurora 고급 감사, 일반 로그 및 느린 쿼리 로그를 사용하는 것을 고려하시기 바랍니다.

아니요. 프라이머리 리전을 사용할 수 없게 되는 경우, 수동으로 Amazon Aurora Global Database에서 보조 리전을 제거하고 모든 읽기 및 쓰기를 처리하도록 승격해야 합니다. 또한 애플리케이션이 새로 승격된 리전을 가리키도록 해야 합니다.

예. 모든 Amazon Aurora DB 인스턴스는 VPC에 생성되어야 합니다. Amazon VPC를 사용하면 사용자의 데이터 센터에서 운영하는 기존 네트워크와 매우 유사한 가상 네트워크 토폴로지를 정의할 수 있습니다. 이를 통해 Amazon Aurora 데이터베이스에 액세스할 수 있는 사용자를 완전히 제어할 수 있습니다.

예. Amazon Aurora는 SSL(AES-256)을 사용하여 데이터베이스 인스턴스와 애플리케이션 간 연결을 보호합니다. Amazon Aurora를 사용하면 사용자가 AWS Key Management Service(AWS KMS)를 통해 관리하는 키를 사용해 데이터베이스를 암호화할 수 있습니다.

Amazon Aurora 암호화를 실행 중인 데이터베이스 인스턴스에서는 같은 클러스터에 있는 자동 백업, 스냅샷 및 복제본과 마찬가지로 기본 스토리지에 저장된 데이터가 암호화됩니다. 암호화와 복호화는 원활하게 처리됩니다. Amazon Aurora와 AWS KMS 사용에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

현재 암호화되지 않은 기존 Aurora 인스턴스를 암호화하는 기능은 지원되지 않습니다. 암호화되지 않은 기존 데이터베이스에 Amazon Aurora 암호화를 사용하려면 암호화를 활성화한 상태에서 새로운 DB 인스턴스를 생성하고, 데이터를 이 인스턴스로 마이그레이션합니다.

데이터베이스를 생성할 때 입력한 데이터베이스 포트를 통해 Aurora 데이터베이스에 액세스해야 합니다. 이를 통해 데이터에 대한 추가적인 보안 계층이 제공됩니다. Amazon Aurora 데이터베이스에 연결하는 방법에 대한 단계별 지침은 Amazon Aurora 연결 가이드에 나와 있습니다.

예. Aurora의 MySQL 및 PostgreSQL 호환 버전 모두 HIPAA 적격 서비스입니다. 이 둘을 사용하여 AWS에서 HIPAA 규정 준수 애플리케이션을 구축하고 시행된 비즈니스 제휴 계약(BAA)에서 보호하는 개인 건강 정보(PHI)를 비롯한 의료 관련 정보를 저장할 수 있습니다. 이미 AWS와 BAA를 체결한 경우, 추가 작업 없이 BAA에 포함된 계정에서 이러한 서비스 사용을 시작할 수 있습니다. AWS에서 규정을 준수하는 애플리케이션을 구축하는 방법에 대한 자세한 정보는 의료 서비스 제공자를 참조하세요.

현재 Amazon Aurora 보안 업데이트에서 CVE의 목록을 확인할 수 있습니다.

Aurora는 Aurora 데이터베이스에 저장된 데이터에 대한 잠재적 위협을 식별하는 데 도움이 되도록 Amazon GuardDuty에 통합됩니다. GuardDuty RDS Protection 기능은 계정에서 로그인 활동과 신규 데이터베이스를 프로파일링하고 모니터링하고, 맞춤형 기계 학습 모델을 사용하여 Aurora 데이터베이스에 대한 의심스러운 로그인을 탐지합니다. 자세한 정보는 Monitoring threats with GuardDuty RDS Protection(GuardDuty RDS Protection을 사용하여 위협 모니터링) 및 GuardDuty RDS Protection 사용 설명서를 참조하세요.

Aurora Serverless는 Amazon Aurora의 온디맨드 자동 크기 조정 구성 버전입니다. Aurora Serverless를 사용하면 데이터베이스 용량을 관리하지 않고도 클라우드에서 데이터베이스를 실행할 수 있습니다. 데이터베이스 용량을 수동으로 관리하면 시간이 오래 걸리고 데이터베이스 리소스의 비효율적 사용을 초래할 수 있습니다. Aurora Serverless를 사용하면 데이터베이스 생성, 원하는 데이터베이스 용량 범위 지정, 애플리케이션 연결 등을 간단하게 수행할 수 있습니다. Aurora는 애플리케이션의 요구에 따라 사용자가 지정한 범위 내에서 자동으로 용량을 조정합니다.

요금은 데이터베이스가 활성 상태인 동안 사용한 데이터베이스 용량에 대해 초당 기준으로 지불하면 됩니다. Aurora Serverless에 대해 자세히 알아보고 Amazon RDS Management Console에서 클릭 몇 번으로 시작하세요.

Aurora Serverless v2는 개발 및 테스트 환경, 웹사이트, 워크로드의 사용 빈도가 낮거나 간헐적이거나 예측할 수 없는 애플리케이션부터 뛰어난 확장성과 고가용성이 필요한 가장 까다로운 비즈니스 크리티컬 애플리케이션까지 모든 유형의 데이터베이스 워크로드를 지원합니다. 데이터베이스를 더 크거나 작은 데이터베이스 인스턴스로 장애 조치할 필요 없이 현 상태에서 CPU 및 메모리를 추가하여 크기를 조정합니다. 이에 따라 장기 실행 트랜잭션, 테이블 잠금 등이 있어도 크기를 조정할 수 있습니다.

또한 데이터베이스 용량을 0.5 ACU(Aurora Capacity Unit) 단위로 증분하여 크기 조정할 수 있기 때문에 데이터베이스 용량이 애플리케이션의 요구에 근접하게 맞춰집니다.

Aurora Serverless v1은 사용 빈도가 낮거나 간헐적이거나 예측할 수 없는 워크로드에 대한 간단하고 비용 효율적인 옵션입니다. 자동으로 시작되어 애플리케이션의 사용량에 맞춰 컴퓨팅 용량 크기를 조정하고, 사용되지 않을 때에는 종료됩니다. 자세한 내용은 Aurora 사용 설명서를 참조하세요.

Aurora Serverless v2는 읽기 전용 복제본, 다중 AZ 구성, Global Database, RDS 프록시 및 성능 개선 도우미를 포함하여 프로비저닝된 모든 Aurora 기능을 지원합니다.

예, 기존 Aurora DB 클러스터에서 Aurora Serverless v2 사용을 시작해 데이터베이스 컴퓨팅 용량을 관리할 수 있습니다. 프로비저닝된 인스턴스와 Aurora Serverless v2를 모두 포함하는 클러스터는 혼합 구성 클러스터라고 합니다. 클러스터에서 프로비저닝된 인스턴스와 Aurora Serverless v2를 원하는 대로 조합할 수 있습니다.

Aurora Serverless v2를 테스트하려면 Aurora DB 클러스터에 리더를 추가하고 Serverless v2를 인스턴스 유형으로 선택합니다. 리더가 생성되어 사용할 수 있게 되면 리더를 읽기 전용 워크로드 용도로 사용을 시작할 수 있습니다. 리더가 예상대로 작동한다고 확인되면 장애 조치를 시작하여 읽기 및 쓰기 용도로 Aurora Serverless v2 사용을 시작할 수 있습니다. 이 옵션을 사용하면 Aurora Serverless v2를 시작하기 위한 가동 중단 시간이 최소화됩니다.

예, Aurora Serverless v1에서 Aurora Serverless v2로 마이그레이션할 수 있습니다. 자세한 내용은 Aurora 사용 설명서를 참조하세요.

Aurora Serverless v1 호환성 정보는 여기에서 확인할 수 있습니다. Aurora Serverless v2 호환성 정보는 여기에서 확인할 수 있습니다.

예. 기존 Aurora 프로비저닝 클러스터에서 생성된 스냅샷을 Aurora Serverless DB 클러스터로 복원할 수 있습니다(반대의 경우도 마찬가지).

동일한 VPC에서 실행되는 클라이언트 애플리케이션에서 Aurora Serverless DB 클러스터에 액세스할 수 있습니다. Aurora Serverless DB에 퍼블릭 IP 주소를 할당할 수는 없습니다.

Aurora Serverless는 활성 데이터베이스 워크로드에 따라 자동으로 확장되지만, 경우에 따라 갑작스러운 워크로드 변경(다수의 새로운 트랜잭션 등)을 충족할만큼 빠르게 용량이 확장되지 않을 수도 있습니다. 이러한 경우에는 AWS Management Console, AWS CLI 또는 Amazon RDS API를 사용해 명시적으로 용량에 특정 값을 설정할 수 있습니다.

크기 조정 작업이 시작되면 Aurora Serverless가 규모 조정 시점을 찾으려고 시도합니다. 이는 데이터베이스가 안전하게 규모 조정을 완료할 수 있는 특정 시점을 말합니다. 장기 실행 쿼리 또는 트랜잭션이 진행 중이거나 임시 테이블 또는 테이블 잠금을 사용 중이라면 Aurora Serverless가 규모 조정 시점을 찾지 못할 수 있습니다.

Aurora Serverless에서 데이터베이스 용량은 Aurora Capacity Unit(ACU)으로 측정됩니다. ACU 사용량에 따라 초당 정액 요금으로 지불합니다. 프로비저닝 구성과 서버리스 구성의 스토리지 및 I/O 요금은 동일합니다. 요금 및 AWS 리전 가용성에 관한 최신 정보는 Aurora 요금 페이지를 참조하세요.

Amazon Aurora 병렬 쿼리는 단일 쿼리의 컴퓨팅 로드를 Aurora의 스토리지 계층에 있는 수천 개의 CPU 전체로 푸시 다운하여 분산할 수 있는 기능을 말합니다. 병렬 쿼리가 없다면 Amazon Aurora 데이터베이스에 대해 실행된 쿼리가 데이터베이스 클러스터 인스턴스 1개에서 모두 실행됩니다. 이는 대부분 데이터베이스가 작동하는 방식과 비슷합니다.

병렬 쿼리는 새로운 데이터가 필요하고 대형 테이블에서도 우수한 쿼리 성능이 필요한 분석 워크로드에 적합합니다. 이러한 유형의 워크로드는 운영적인 성격을 띠는 경우가 많습니다.

병렬 쿼리를 사용하면 성능이 향상되어 분석 쿼리 속도가 최대 100배까지 빨라집니다. 또한 Aurora 클러스터의 현재 트랜잭션 데이터에 대해 직접 쿼리를 실행할 수 있으므로 운영 간편성과 데이터 신선도를 제공합니다. 또한 병렬 쿼리는 Aurora가 동시 분석 쿼리와 함께 높은 트랜잭션 처리량(throughput)을 유지할 수 있도록 하여 동일한 데이터베이스에서 트랜잭션 및 분석 워크로드를 지원합니다.

아직 버퍼 풀에 없는 대형 데이터 세트에 대한 쿼리 대부분이 이점을 기대할 수 있습니다. 병렬 쿼리의 초기 버전은 200개가 넘는 SQL 함수, 동등 조인 및 프로젝션 처리를 푸시 다운 및 스케일 아웃할 수 있습니다.

특정 쿼리의 성능 개선은 얼마나 많은 쿼리 계획이 Aurora 스토리지 계층으로 푸시 다운될 수 있는지에 따라 달라집니다. 고객은 쿼리 지연 시간이 대폭 개선되었다고 보고했습니다.

예. 하지만 그러한 사례는 매우 드물 것으로 예상합니다.

쿼리 구문을 변경할 필요는 없습니다. 쿼리 최적화 프로그램이 특정 쿼리에 병렬 쿼리를 사용할지 자동으로 결정합니다. 쿼리가 병렬 쿼리를 사용하고 있는지 확인하려면 EXPLAIN 명령을 실행하여 쿼리 실행 계획을 보면 됩니다. 테스트를 위해 휴리스틱을 건너뛰고 병렬 쿼리를 적용하려는 경우 aurora_pq_force 세션 변수를 사용하세요.

병렬 쿼리는 aurora_pq 파라미터를 사용하여 전역 및 세션 수준에서 동적으로 활성화/비활성화할 수 있습니다.

아니요. 인스턴스, I/O 및 스토리지에 대해 이미 지불하고 있는 비용 외에 추가 요금은 없습니다.

아니요. 쿼리에 대한 병렬 쿼리 IO 비용은 스토리지 계층에서 측정되며 병렬 쿼리가 활성화된 경우 그 비용은 동일하거나 더 커집니다. 쿼리 성능이 향상되는 것이 이점입니다.

병렬 쿼리로 I/O 비용이 증가할 가능성이 있는 이유는 두 가지입니다. 먼저, 테이블의 데이터 일부가 버퍼 풀에 있더라도, 병렬 쿼리는 스토리지 계층의 모든 데이터를 스캔해야 하므로 I/O가 발생합니다. 둘째, 버퍼 풀에서 경합을 피하는 부작용은 병렬 쿼리를 실행해도 버퍼 풀이 워밍업되지 않는다는 것입니다. 결과적으로 동일한 병렬 쿼리를 연속적으로 실행하면 전체 I/O 비용이 발생합니다.

설명서에서 병렬 쿼리에 대해 자세히 알아보세요.

아니요. 현재 R* 인스턴스 패밀리의 인스턴스에서만 병렬 쿼리를 사용할 수 있습니다.

초기 버전에서는 지원되지 않습니다. 현재는 Serverless 또는 Backtrack 기능을 실행하고 있지 않은 데이터베이스 클러스터에 대해서만 활성화할 수 있습니다. 또한 Aurora with MySQL 5.7 호환성에서 한정된 기능은 지원하지 않습니다.

아니요. 대부분의 경우 병렬 쿼리로 쿼리 지연 시간이 개선되겠지만, I/O 비용이 증가할 수 있습니다. 기능을 사용 설정/사용 중지한 상태에서 워크로드를 철저히 테스트하는 것이 좋습니다. 병렬 쿼리가 올바른 선택이라는 확신이 들면 쿼리 최적화 프로그램을 사용하여 어떤 쿼리에서 병렬 쿼리를 사용할지 자동으로 결정할 수 있습니다. 드물지만 최적화 프로그램이 최적의 의사 결정을 내리지 못하는 경우 설정을 재정의할 수 있습니다.

Aurora 병렬 쿼리는 데이터 웨어하우스가 아니며, 이러한 제품에서 일반적으로 발견되는 기능을 제공하지 않습니다. 관계형 데이터베이스의 쿼리 성능을 개선하도록 설계되었으며, 데이터베이스의 새로운 데이터에 대해 빠른 분석 쿼리를 수행해야 하는 운영 분석과 같은 사용 사례에 적합합니다.

엑사바이트 규모의 클라우드 데이터 웨어하우스의 경우 Amazon Redshift를 고려하세요.

Amazon DevOps Guru for RDS는 데이터베이스 성능 및 운영 문제를 자동으로 감지하고 진단하도록 설계된 Amazon RDS(Amazon Aurora 포함)를 위한 새로운 기계 학습 기반 기능으로, 며칠이 아닌 몇 분 만에 문제를 해결할 수 있습니다.

Amazon DevOps Guru for RDS는 Amazon DevOps Guru의 기능으로 모든 Amazon RDS 엔진 및 수십 가지 기타 리소스 유형에 대한 운영 및 성능 문제를 감지하도록 설계되었습니다. DevOps Guru for RDS는 DevOps Guru의 기능을 확장하여 Amazon RDS의 다양한 데이터베이스 관련 문제(예: 리소스 과잉 사용 및 특정 SQL 쿼리의 오작동)를 감지, 진단 및 수정합니다.

문제가 발생하면 Amazon DevOps Guru for RDS는 개발자와 DevOps 엔지니어에게 즉시 알리고 진단 정보, 문제 범위에 대한 세부 정보, 지능형 수정 권장 사항을 제공하여 고객이 데이터베이스 관련 성능 병목 현상 및 운영 문제를 신속하게 해결할 수 있도록 합니다.

Amazon DevOps Guru for RDS는 관계형 데이터베이스 워크로드에서 찾기 힘든 성능 병목 현상을 감지하고 해결하는 데 필요한 수작업을 제거하고 시간을 몇 시간, 며칠에서 몇 분으로 단축하도록 설계되었습니다.

모든 Amazon Aurora 데이터베이스에 대해 DevOps Guru for RDS를 사용하면 워크로드에 대한 성능 문제를 자동으로 감지하고, 각 문제에 대해 알림을 보내고, 결과를 설명하고, 해결할 조치를 권장합니다.
DevOps Guru for RDS는 비전문가가 데이터베이스 관리에 더 쉽게 액세스할 수 있도록 도와주며 데이터베이스 전문가가 더 많은 데이터베이스를 관리할 수 있도록 지원합니다.

Amazon DevOps Guru for RDS는 기계 학습을 사용하여 Amazon RDS 성능 개선 도우미(PI)에서 수집한 원격 측정 데이터를 분석합니다. DevOps Guru for RDS는 데이터베이스에 저장된 데이터를 분석에 사용하지 않습니다. PI는 애플리케이션이 데이터베이스에서 시간을 보내는 방식을 특성화하는 지표인 데이터베이스 로드를 측정하고 MySQL의 서버 상태 변수 및 PostgreSQL의 pg_stat 테이블과 같이 데이터베이스에서 생성된 선택된 지표를 측정합니다.

DevOps Guru for RDS를 시작하려면 RDS 콘솔을 통해 성능 개선 도우미가 사용되는지 확인한 다음 Amazon Aurora 데이터베이스에 대해 DevOps Guru를 사용 설정하기만 하면 됩니다. DevOps Guru를 사용하면 분석 범위 한계를 전체 AWS 계정으로 선택하거나, DevOps Guru가 분석할 특정 AWS CloudFormation 스택을 지정하거나, AWS 태그를 사용해 DevOps Guru가 분석할 리소스 그룹을 생성할 수 있습니다.

Amazon DevOps Guru for RDS는 잠금 누적, 연결 폭풍, SQL 회귀, CPU 및 I/O 경합, 메모리 문제와 같이 애플리케이션 서비스 품질에 영향을 줄 수 있는 광범위한 성능 문제를 식별하는 데 도움이 됩니다.

Amazon RDS 성능 개선 도우미는 Amazon RDS 데이터베이스 성능 지표를 수집하고 시각화하는 데이터베이스 성능 조정 및 모니터링 기능으로, 데이터베이스의 로드를 빠르게 평가하고 언제 어디에서 조치해야 하는지 파악하는 데 도움이 됩니다. Amazon DevOps Guru for RDS는 이러한 지표를 모니터링하고, 데이터베이스에 성능 문제가 발생하는 시기를 감지하고, 지표를 분석한 다음, 무엇이 잘못되었고 이에 대해 무엇을 할 수 있는지 알려주도록 설계되었습니다.

Amazon RDS 블루/그린 배포는 Amazon Aurora MySQL 호환 버전 5.6에서 사용 가능합니다. Aurora 문서에서 사용 가능한 버전에 대해 자세히 알아보세요.

Amazon RDS 블루/그린 배포는 AWS 중국 리전을 제외한 모든 AWS 리전과 AWS GovCloud 리전에서 사용할 수 있습니다.

블루 인스턴스에서 워크로드를 실행할 때와 동일한 비용이 그린 인스턴스에 대해 발생합니다. 블루 및 그린 인스턴스에서 실행할 때의 비용에는 db.instances에 대한 현재 표준 요금, 스토리지 비용, 읽기/쓰기 I/O 비용 및 사용된 기능에 대한 비용(예: 백업 비용 및 Amazon RDS 성능 개선 도우미 비용)이 포함됩니다. 실질적으로 블루/그린 배포가 진행되는 동안 db.instance에서 워크로드를 실행할 때의 약 2배에 해당하는 비용이 발생합니다.

예제: us-east-1 AWS 리전의 r5.2xlarge db.instances 2개(프라이머리 라이터 인스턴스와 리더 인스턴스)에서 Aurora MySQL 호환 버전 5.7 클러스터를 실행하고 있습니다. 각 r5.2xlarge db.instances는 40GiB 스토리지에 대해 구성되어 있고 월 2,500만 I/O를 제공합니다. Amazon RDS 블루/그린 배포를 사용하여 블루 인스턴스 토폴로지의 클론을 생성하고 15일(360시간) 동안 실행합니다. 해당 시기에 각 그린 인스턴스의 읽기 I/O는 300만입니다. 성공적인 전환 후에 블루 인스턴스를 삭제합니다. 블루 인스턴스(라이터 및 리더)의 비용은 시간당 1.179 USD의 온디맨드 요금으로 15일간 849.2 USD입니다(인스턴스 + 스토리지 + I/O). 그린 인스턴스(라이터 및 리더)의 비용은 시간당 1.167 USD의 온디맨드 요금으로 15일간 840.40 USD입니다(인스턴스 + 스토리지 + I/O). 이 15일간 블루/그린 배포를 사용한 데 대한 총 비용은 1,689.60 USD입니다. 이는 해당 기간에 블루 인스턴스를 실행하는 비용의 약 2배입니다.

Amazon RDS 블루/그린 배포에서는 메이저 또는 마이너 버전 업그레이드, 스키마 변경, 인스턴스 크기 조정, 엔진 파라미터 변경 및 유지 관리 업데이트와 같은 데이터베이스 변경을 더 안전하고 더 간단하며 더 빠르게 수행할 수 있습니다.

Amazon RDS 블루/그린 배포에서 블루 환경은 현재 프로덕션 환경입니다. 그린 환경은 전환 후에 새로운 프로덕션 환경이 될 스테이징 환경입니다.

Amazon RDS 블루/그린 배포에서 전환이 시작되면 전환이 완료될 때까지 블루 환경과 그린 환경 모두에 대한 쓰기가 차단됩니다. 전환 중에 스테이징 환경 또는 그린 환경은 프로덕션 시스템과 동기화하여 스테이징 환경과 프로덕션 환경의 데이터가 일치할 수 있도록 합니다. 프로덕션과 스테이징 환경이 완벽하게 동기화되면 블루/그린 배포는 새롭게 승격된 프로덕션 환경으로 트래픽을 리디렉션하여 스테이징 환경을 새 프로덕션 환경으로 승격합니다. Amazon RDS 블루/그린 배포는 전환이 완료된 후 그린 환경에 대한 쓰기를 지원하여 전환 프로세스 중에 데이터 손실이 발생하지 않도록 합니다.

Amazon RDS 블루/그린 배포는 이전 프로덕션 환경을 삭제하지 않습니다. 필요한 경우 추가 검증 및 성능/회귀 테스트를 위해 이전 환경에 액세스할 수 있습니다. 이전 프로덕션 환경이 더 이상 필요하지 않다면 삭제해도 됩니다. 이전 프로덕션 인스턴스에는 인스턴스를 삭제하기 전까지 표준 결제 요금이 적용됩니다.

Amazon RDS 블루/그린 배포의 전환 가드레일은 전환 전에 그린 환경이 동기화될 때까지 블루 및 그린 환경에 대한 쓰기를 차단합니다. 블루/그린 배포는 블루 및 그린 환경에 있는 기본 인스턴스 및 복제본의 상태 확인도 수행합니다. 또한 복제 상태 확인도 수행하는데, 예를 들어 복제가 중지되었는지, 오류가 있는지 여부를 확인합니다. 블루 환경과 그린 환경 사이에 오래 실행되는 트랜잭션이 있는 경우 이를 감지합니다. 사용자는 허용 가능한 최대 가동 중단 시간을 최소 30초로 지정할 수 있으며, 진행 중인 트랜잭션이 이 값을 초과할 경우 전환이 시간 초과 처리됩니다.

아니요. Amazon RDS 블루/그린 배포는 Amazon Aurora Global Database를 지원하지 않습니다.

아니요. 지금은 Amazon RDS 블루/그린 배포를 사용하여 변경 사항을 롤백할 수 없습니다.