Amazon Aurora FAQ

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

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

또한 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 프리미엄 서포트에 Aurora 관련 문제를 문의할 수 있습니다.

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

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

MySQL에서 Aurora로 또는 그 반대로 마이그레이션하려는 경우 몇 가지 옵션이 있습니다.

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

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

PostgreSQL에서 Aurora로 또는 그 반대로 마이그레이션하려는 경우 몇 가지 옵션이 있습니다.

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

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

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

아니요. 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에서 워크로드의 처리량을 극대화하기 위해서는 다수의 동시 쿼리와 트랜잭션을 수행하도록 애플리케이션을 구축하는 것이 좋습니다.

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

현재 Aurora에 대한 AWS 프리 티어 혜택은 없습니다. Aurora는 리전 내 3개의 가용 영역에 데이터를 안정적으로 저장하지만 데이터 복사본 1개에 대한 요금만 부과합니다. 데이터베이스 클러스터 크기의 최대 100%에 해당하는 백업에 대해서는 요금이 부과되지 않습니다. 또한 데이터베이스 클러스터에 구성된 백업 보존 기간 동안에는 스냅샷에 대한 요금이 부과되지 않습니다.

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

I/O 작업은 Aurora 데이터베이스 엔진에서 SSD 기반 가상화 스토리지 계층에 대해 수행됩니다. 모든 데이터베이스 페이지 읽기 작업은 1건의 I/O로 계산됩니다.
Aurora 데이터베이스 엔진은 캐시의 메모리에 없는 데이터베이스 페이지를 가져오기 위해 스토리지 계층에 대한 읽기를 실행합니다.

• 쿼리 트래픽을 메모리 또는 캐시에서 모두 처리할 수 있는 경우 메모리에서 데이터 페이지를 검색하는 요금이 부과되지 않습니다.
• 쿼리 트래픽을 메모리에서 완전히 처리할 수 없는 경우 스토리지에서 검색해야 하는 데이터 페이지에 대한 요금이 부과됩니다.
  각 데이터베이스 페이지는 Amazon 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는 오손 데이터(dirty data) 페이지를 스토리지로 플러시하지 않습니다.

Aurora 인스턴스가 얼마나 많은 I/O 요청을 사용하는지는 AWS Management Console에서 확인할 수 있습니다. I/O 사용량을 확인하려면 콘솔의 Amazon RDS 섹션에서 인스턴스 목록을 찾아, Aurora 인스턴스를 선택한 후 모니터링 섹션에서 ‘VolumeReadIOPs’ 및 ‘VolumeWriteIOPs’ 지표를 보면 됩니다.

I/O 작업 요금에 대한 자세한 내용은 Aurora 요금 페이지를 참조하세요. 데이터베이스 클러스터를 Aurora Standard 구성으로 구성하면 읽기 및 쓰기 I/O 작업에 대한 요금이 부과됩니다. 데이터베이스 클러스터를 Amazon Aurora I/O-Optimized로 구성하면 읽기 및 쓰기 I/O 작업에 대한 요금이 부과되지 않습니다.

Aurora에서는 가격 대비 성능과 가격 예측 가능성 요구 사항에 따라 2가지 구성 옵션 중에서 유연하게 선택하여 데이터베이스 지출을 최적화할 수 있습니다. 2가지 구성 옵션은 Aurora Standard와 Aurora I/O-Optimized입니다. 두 옵션 모두 사전 I/O 또는 스토리지 프로비저닝이 필요하지 않으며 가장 까다로운 애플리케이션을 지원하도록 I/O 작업을 확장할 수 있습니다.

Aurora Standard는 I/O 사용량이 낮거나 중간 정도인 대부분의 애플리케이션에서 비용 효율적인 요금으로 사용할 수 있는 데이터베이스 클러스터 구성입니다. Aurora Standard를 사용할 때는 데이터베이스 인스턴스, 스토리지 및 요청 I/O당 요금에 대한 비용을 지불합니다.

Aurora I/O-Optimized는 결제 처리 시스템, 전자상거래 시스템, 금융 애플리케이션과 같이 I/O를 많이 사용하는 애플리케이션에 우수한 가격 대비 성능을 제공하는 데이터베이스 클러스터 구성입니다. 또한 I/O 지출이 총 Aurora 데이터베이스 지출의 25%를 초과하는 경우 Aurora I/O-Optimized를 이용하면 I/O 집약적 워크로드의 비용을 최대 40% 절감할 수 있습니다. Aurora I/O-Optimized는 읽기 및 쓰기 I/O 작업에 대한 요금이 없으므로 모든 애플리케이션에서 요금을 예측할 수 있습니다. 따라서 I/O 변동성이 큰 워크로드에 적합한 구성입니다.

Aurora I/O Optimized는 어떤 애플리케이션에서든 비용을 예측할 수 있어야 할 때 적합한 선택입니다. 쓰기 처리량이 높아야 하거나 대량의 데이터를 처리하는 분석 쿼리를 실행하는 I/O 집약적 애플리케이션의 경우 가격 대비 성능이 향상됩니다. I/O 지출이 Aurora 청구서의 25% 를 초과하는 고객의 경우 Aurora I/O-Optimized를 통해 I/O 집약적 워크로드의 비용을 최대 40% 절감할 수 있습니다.

AWS Management Console 내의 원클릭 경험을 사용하여 기존 데이터베이스 클러스터의 스토리지 유형을 Aurora I/O-Optimized로 변경할 수 있습니다. AWS Command Line Interface(AWS CLI) 또는 AWS SDK를 호출하여 이 변경을 수행할 수도 있습니다.

기존 데이터베이스 클러스터를 30일 간격으로 Aurora I/O Optimized 모드로 전환할 수 있습니다. Aurora Standard로 전환하는 것은 언제든지 가능합니다.

예. Aurora I/O-Optimized는 기존 Aurora 예약형 인스턴스에서 작동합니다. Aurora는 Aurora Standard와 Aurora I/O-Optimized(예약형 인스턴스 사용) 간의 가격 차이를 자동으로 고려합니다. Aurora I/O-Optimized에서 예약형 인스턴스 할인을 받으면 I/O 비용을 더 많이 절약할 수 있습니다.

Aurora I/O-Optimized를 사용하더라도 역추적, 스냅샷, 내보내기 또는 지속적 백업 요금은 변경되지 않습니다.

예. 리전 간에 데이터를 복제하는 데 필요한 I/O 작업에 대한 요금은 계속 적용됩니다. Aurora I/O-Optimized는 데이터 복제와 달리 읽기 및 쓰기 I/O 작업에 대한 요금을 부과하지 않습니다.

인텔 기반 R6id 및 Graviton 기반 R6gd 인스턴스 요금 외에 Aurora PostgreSQL용 Amazon Aurora 최적화된 읽기에 부과되는 추가 비용은 없습니다. 자세한 내용은 Aurora 요금 페이지를 참조하세요.

최소 스토리지는 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)에 데이터를 안정적으로 유지하며, 데이터가 손실되지 않은 정상 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는 자동으로 장애 조치를 처리하므로, 관리자가 개입하지 않아도 애플리케이션이 최대한 신속하게 데이터베이스 작업을 재개할 수 있습니다.

• Aurora 복제본이 동일한 AZ 또는 다른 AZ에 있는 경우 장애 조치가 진행될 때 Aurora에서 DB 인스턴스의 Canonical Name Record(CNAME)가 정상적인 복제본을 가리키도록 변경하며, 해당 복제본이 승격되어 새로운 기본 복제본이 됩니다. 일반적으로 장애 조치는 처음부터 끝까지 30초 이내에 완료됩니다. 복원력을 개선하고 장애 조치를 더 빠르게 수행하려면 애플리케이션 연결을 유지하면서 장애 조치 DB 인스턴스에 자동으로 연결하는 Amazon RDS 프록시를 사용하는 것이 좋습니다. 프록시는 애플리케이션의 장애 조치를 투명하게 만들어 장애 조치 시간을 최대 66% 단축합니다.
• Aurora Serverless v1 및 DB 인스턴스를 실행하거나 AZ를 사용할 수 없게 될 경우, Aurora는 다른 AZ에서 DB 인스턴스를 자동으로 다시 생성합니다. Aurora Serverless v2는 장애 조치 및 기타 고가용성 기능을 위해 프로비저닝된 것처럼 작동합니다. 자세한 정보는 Aurora Serverless v2 및 고가용성을 참조하세요. 
• 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 Aurora 용량 단위(ACU)로 증분하여 크기 조정할 수 있기 때문에 데이터베이스 용량이 애플리케이션의 요구에 근접하게 맞춰집니다.

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

Aurora Serverless v2는 읽기 전용 복제본, 다중 AZ 구성, Aurora 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에서 데이터베이스 용량은 ACU로 측정됩니다. 요금은 ACU 사용량에 따라 초당 정액 요금으로 부과됩니다. Aurora Serverless에서 워크로드를 실행할 때의 컴퓨팅 비용은 선택한 데이터베이스 클러스터 구성(Aurora Standard 또는 Aurora I/O-Optimized)에 따라 달라집니다. 요금 및 리전 가용성에 대한 자세한 내용은 Aurora 요금 페이지를 참조하세요.

Aurora PostgreSQL에 사용할 수 있는 Amazon Aurora 최적화된 읽기는 새로운 가격 대비 성능 옵션으로, 이 옵션이 없는 인스턴스에 비해 쿼리 지연 시간을 최대 8배 개선하고 최대 30%의 비용 절감 효과를 제공합니다. 데이터베이스 인스턴스의 메모리 용량을 초과하는 대규모 데이터 세트가 있는 애플리케이션에 적합합니다.

Amazon Aurora 최적화된 읽기 인스턴스는 로컬 NVMe 기반 SSD 블록 레벨 스토리지(Graviton 기반 r6gd 및 인텔 기반 r6id 인스턴스에서 사용 가능)를 사용하여 데이터 세트가 데이터베이스 인스턴스의 메모리 용량을 초과하는 애플리케이션의 쿼리 지연 시간을 개선합니다. 최적화된 읽기에는 계층형 캐싱 및 임시 객체와 같은 향상된 성능 기능이 포함됩니다.

계층형 캐싱은 운영 대시보드, 이상 탐지, 벡터 기반 유사성 검색과 같은 읽기 중심 I/O 집약적 애플리케이션에 대한 쿼리 지연 시간을 최대 8배 개선하고 비용을 최대 30% 절감합니다. 이러한 이점은 인 메모리 데이터베이스 버퍼 캐시에서 제거된 데이터를 로컬 스토리지에 자동으로 캐싱하여 해당 데이터에 대한 후속 액세스 속도를 높임으로써 실현됩니다. 계층형 캐싱은 Aurora I/O-Optimized 구성이 포함된 Amazon Aurora PostgreSQL 에디션에서만 사용할 수 있습니다.

임시 객체는 Aurora PostgreSQL을 통해 생성된 임시 테이블을 로컬 스토리지에 배치하여 정렬, 해시 집계, 고부하 조인 및 기타 데이터 집약적 작업과 관련된 쿼리 성능을 개선함으로써 쿼리 처리 속도를 높입니다.

Aurora PostgreSQL용 Amazon Aurora 최적화된 읽기는 지연 시간에 민감한 애플리케이션과 대규모 작업 세트를 보유한 고객에게 매력적인 가격 대비 성능으로 비즈니스 SLA를 충족하고 인스턴스로 더 많은 작업을 수행할 수 있는 대안을 제공합니다.

Amazon Aurora 최적화된 읽기는 인텔 기반 R6id 및 Graviton 기반 R6gd 인스턴스에서 사용할 수 있습니다. 여기에서 Aurora의 리전 가용성을 확인할 수 있습니다.

Amazon Aurora 최적화된 읽기는 R6id 및 R6gd 인스턴스의 PostgreSQL 호환 Aurora 에디션에서 사용할 수 있습니다. 지원되는 엔진 버전은 15.4 이상이고 Aurora PostgreSQL에서는 14.9 이상입니다.

Amazon Aurora 최적화된 읽기는 Aurora Serverless v2(ASv2)에서 사용할 수 없습니다.

예. Amazon Aurora 최적화된 읽기를 두 구성 모두에서 사용할 수 있습니다. 두 구성 모두에서 최적화된 읽기 지원 인스턴스는 임시 테이블을 NVMe 기반 로컬 스토리지에 자동으로 매핑하여 분석 쿼리 및 인덱스 재작성의 성능을 개선합니다.

읽기 중심의 I/O 집약적 워크로드에 Aurora I/O-Optimized를 사용하도록 구성된 Aurora PostgreSQL의 최적화된 읽기 지원 인스턴스를 사용하면 NVMe 기반 로컬 스토리지의 메모리에서 제거된 데이터가 자동으로 캐싱됩니다. 따라서 데이터베이스 인스턴스의 메모리 용량을 초과하는 대규모 데이터 세트가 있는 애플리케이션에 대해 이 인스턴스를 사용하지 않는 인스턴스에 비해 쿼리 지연 시간이 최대 8배 개선되고 비용이 최대 30% 절감됩니다.

AWS Management Console, CLI 및 SDK를 통해 Amazon Aurora 최적화된 읽기를 시작할 수 있습니다. 최적화된 읽기는 기본적으로 모든 R6id 및 R6gd 인스턴스에서 사용할 수 있습니다. R6id 및 R6gd 인스턴스를 포함하도록 기존 Aurora 데이터베이스 클러스터를 수정하거나 이러한 인스턴스를 사용하여 새 데이터베이스 클러스터를 생성하기만 하면 이 기능을 사용할 수 있습니다. 시작하려면 Amazon Aurora 최적화된 읽기 설명서를 참조하세요.

R6id 및 R6gd 인스턴스에서 사용 가능한 로컬 스토리지의 약 90%를 최적화된 읽기에 사용할 수 있습니다. Aurora에서 NVMe 스토리지의 10%는 SSD 쓰기 증폭의 영향을 줄이기 위해 예약됩니다. 사용 가능한 스토리지 할당은 활성화된 최적화된 읽기 기능에 따라 달라집니다.

임시 객체 및 계층형 캐싱 기능 모두와 함께 최적화된 읽기를 사용하는 경우 로컬 스토리지의 임시 객체에 사용할 수 있는 공간은 이러한 데이터베이스 인스턴스에서 사용할 수 있는 메모리 크기의 2배에 해당합니다. 이는 Aurora PostgreSQL에 있는 임시 객체 스토리지의 현재 크기와 일치합니다. 나머지 로컬 스토리지 디스크 공간은 데이터 캐싱에 사용할 수 있습니다.

임시 객체 기능과 함께 최적화된 읽기만 사용하는 경우 사용 가능한 모든 로컬 스토리지 디스크 공간을 임시 객체에 사용할 수 있습니다. 예를 들어 임시 객체와 계층형 캐싱 기능이 모두 포함된 r6gd.8xlarge 인스턴스를 사용하는 경우 534GiB(2배 메모리 용량)는 임시 객체용으로 예약되고 1,054GiB는 계층형 캐시용으로 예약됩니다.

로컬 스토리지에 장애가 발생하면 자동으로 호스트 교체가 수행됩니다. 다중 노드 데이터베이스 클러스터에서는 리전 내 장애 조치가 트리거됩니다.

데이터베이스 장애 조치 시 장애 조치 후 쿼리 지연 시간이 일시적으로 증가합니다. 이러한 지연 시간 증가는 시간 경과에 따라 줄어들어 결국 장애 조치 이전의 쿼리 지연 시간을 따라잡게 됩니다. 클러스터 캐시 관리(CCM)를 활성화하면 이 캐치업 기간을 단축할 수 있습니다. CCM을 사용하여 특정 Aurora PostgreSQL 데이터베이스 인스턴스를 장애 조치 대상으로 지정할 수 있습니다.

CCM을 활성화하면 지정된 장애 조치 대상의 로컬 스토리지 캐시가 기본 인스턴스의 로컬 스토리지 캐시와 밀접하게 미러링되므로 장애 조치 후 캐치업 시간이 단축됩니다. 하지만 지정된 장애 조치 대상이 라이터 인스턴스의 워크로드와 별개로 읽기 워크로드도 처리하는 데 사용될 경우 CCM을 활성화하면 로컬 스토리지 캐시의 장기적 효율성에 영향을 미칠 수 있습니다.

따라서 리더를 대기 장애 조치로 지정해야 하는 워크로드를 실행하는 경우에는 CCM을 통해 장애 조치 후 쿼리 지연 시간이 빠르게 복구될 가능성을 높여야 합니다. 지정된 장애 조치 대상에서 별도의 워크로드를 실행하는 경우 CCM을 활성화하기 전에 장애 조치 후 즉각적인 지연 시간 복구에 대한 요구 사항과 캐시 성능의 장기적 효율성 사이에서 균형을 맞추는 것이 좋습니다.

pgvector는 Amazon Aurora PostgreSQL 호환 버전으로 지원되는 PostgreSQL용 오픈 소스 확장 프로그램입니다.

예. Aurora 기계 학습(ML)은 ML 모델을 SQL 함수로 노출하므로 표준 SQL을 사용하여 ML 모델을 직접 호출하고 모델에 데이터를 전달하고 예측을 쿼리 결과로 반환할 수 있습니다. pgvector를 사용하려면 벡터 임베딩을 데이터베이스에 저장해야 합니다. 그러려면 소스 텍스트 또는 이미지 데이터에서 ML 모델을 실행하여 임베딩을 생성한 다음 임베딩을 일괄적으로 Aurora PostgreSQL로 이동해야 합니다.

Aurora ML을 사용하면 Amazon SageMaker를 주기적으로 직접 호출하여 모델의 최신 임베딩을 반환함으로써 임베딩을 Aurora PostgreSQL에서 최신 상태로 유지하는 실시간 프로세스를 만들 수 있습니다.

pgvector에서 Amazon Aurora PostgreSQL 최적화된 읽기는 사용 가능한 인스턴스 메모리를 초과하는 워크로드에서 벡터 검색에 대한 초당 쿼리 수를 최대 9배까지 늘려줍니다. 이는 최적화된 읽기에서 사용할 수 있는 계층형 캐싱 기능 덕분에 가능한데, 이 기능은 인 메모리 데이터베이스 버퍼 캐시에서 제거된 데이터를 로컬 스토리지에 자동으로 캐싱하여 해당 데이터에 대한 후속 액세스 속도를 높입니다.

트랜잭션 데이터에 거의 실시간으로 액세스해야 하는 경우 Amazon Redshift와 Aurora MySQL 제로 ETL 통합을 사용해야 합니다. 이 통합을 사용하면 간단한 SQL 명령으로 Amazon Redshift 기계 학습(ML)을 활용할 수 있습니다.

미국 동부(오하이오), 미국 동부(버지니아 북부), 미국 서부(오레곤), 아시아 태평양(도쿄), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 유럽(아일랜드), 유럽(프랑크푸르트) 및 유럽(스톡홀름) 리전에서 Aurora MySQL-Compatible Edition for Aurora MySQL 3.05 버전(MySQL 8.0.32 호환) 이상에 대해 Amazon Redshift와 Amazon Aurora 제로 ETL 통합을 사용할 수 있습니다.

Amazon Aurora MySQL과 Amazon Redshift의 제로 ETL 통합을 사용하면 복잡한 데이터 파이프라인을 구축하고 유지 관리하지 않고도 단일 또는 여러 Aurora 데이터베이스 클러스터의 데이터를 단일의 Redshift 데이터베이스 클러스터로 통합하고, Amazon Redshift를 사용하여 Aurora의 페타바이트급 트랜잭션 데이터에 대해 거의 실시간 분석 및 ML을 실행할 수 있습니다. Aurora MySQL과 Amazon Redshift의 제로 ETL 통합을 수행하면 여러 Aurora 데이터베이스에서 Amazon Redshift로의 100만 건 이상의 트랜잭션 또는 분당 1,750만 건의 행 삽입/업데이트/삭제 작업이 15초 이내에 처리됩니다(p50 지연 시간).

Amazon Aurora MySQL과 Amazon Redshift의 제로 ETL 통합은 Amazon Aurora Serverless v2와 호환됩니다. Aurora Serverless v2와 Amazon Redshift Serverless를 모두 사용하는 경우 데이터 파이프라인용 인프라를 관리할 필요 없이 트랜잭션 데이터에 대해 거의 실시간 분석을 생성할 수 있습니다.

Amazon RDS 콘솔에서 Aurora 소스와 Amazon Redshift 대상을 지정하여 제로 ETL 통합을 생성하고 시작할 수 있습니다. 통합이 생성되면 Aurora 데이터베이스가 Amazon Redshift에 복제되고, 초기 시드가 완료되면 데이터 쿼리를 시작할 수 있습니다. 자세한 내용은 Amazon Aurora MySQL zero-ETL integrations with Amazon Redshift(Amazon Aurora MySQL과 Amazon Redshift의 제로 ETL 통합)에 대한 시작 가이드를 읽어보세요.

제로 ETL 및 지속적인 데이터 변경 처리는 추가 비용 없이 제공됩니다. 제로 ETL 통합을 생성하고 그 일부로 생성되는 변경 데이터를 처리하는 데 사용한 기존 Amazon RDS 및 Amazon Redshift 리소스에 대한 요금이 부과됩니다. 이러한 리소스에는 향상된 binlog를 활성화하는 데 사용되는 추가 IO 및 스토리지, Amazon Redshift 데이터베이스를 시드하기 위한 초기 데이터 내보내기에 드는 스냅샷 내보내기 비용, 복제된 데이터를 저장하기 위한 추가 Amazon Redshift 스토리지, 소스에서 대상으로 데이터를 이동하는 데 사용되는 AZ 간 데이터 전송이 포함될 수 있습니다. 자세한 내용은 Aurora 요금 페이지를 참조하세요.

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 이상과 Amazon Aurora PostgreSQL 호환 에디션 버전 11.21 이상, 12.16 이상, 13.12 이상, 14.9 이상, 15.4 이상에서 사용할 수 있습니다. Aurora 설명서에서 사용 가능한 버전에 대해 자세히 알아보세요.

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

Amazon RDS 블루/그린 배포를 사용하면 더 안전하고 단순하며 빠르게 데이터베이스를 변경할 수 있습니다. 블루/그린 배포는 메이저 또는 마이너 버전 데이터베이스 엔진 업그레이드, 운영 체제 업데이트, 논리적 복제를 중단하지 않는 그린 환경의 스키마 변경(예: 테이블 끝에 새 열 추가) 또는 데이터베이스 파라미터 설정 변경과 같은 사용 사례에 적합합니다.

블루/그린 배포를 사용하면 한 번의 전환으로 여러 데이터베이스를 동시에 업데이트할 수 있습니다. 이를 통해, 예측 가능한 짧은 가동 중지 시간으로 보안 패치를 최신 상태로 유지하고, 데이터베이스 성능을 개선하고, 최신 데이터베이스 기능에 액세스할 수 있습니다. Aurora에 마이너 버전 업그레이드만 수행하려는 경우 Aurora 제로 다운타임 패치(ZDP)를 사용하는 것이 좋습니다.

블루 인스턴스에서 워크로드를 실행할 때와 동일한 비용이 그린 인스턴스에 대해 발생합니다. 블루 및 그린 인스턴스에서 실행할 때의 비용에는 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.instance는 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 블루/그린 배포는 Amazon Aurora Global Database, Amazon RDS 프록시, 크로스 리전 읽기 전용 복제본을 지원하지 않습니다.

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

Trusted Language Extensions(TLE) for PostgreSQL을 사용하면 개발자가 고성능 PostgreSQL 확장 프로그램을 구축하고 Amazon Aurora에서 안전하게 실행할 수 있습니다. 이를 통해 TLE는 출시 시간을 단축하고, 프로덕션 데이터베이스 워크로드에 사용할 사용자 지정 및 서드 파티 코드를 인증해야 하는 데이터베이스 관리자의 부담을 덜어줍니다. 확장 프로그램이 요구 사항을 충족한다고 판단되는 즉시 사용을 시작할 수 있습니다. TLE을 사용하면 독립 소프트웨어 개발 판매 회사(ISV)가 새로운 PostgreSQL 확장 프로그램을 고객에게 제공하고 이를 Aurora에서 실행할 수 있습니다.

TLE for PostgreSQL은 Amazon Aurora PostgreSQL 호환 버전 14.5 이상에서 사용할 수 있습니다. TLE는 PostgreSQL 확장 자체로서 구현되었으며 사용자는 Aurora에서 지원하는 기타 확장과 유사하게 rds_superuser 역할에서 이를 활성화할 수 있습니다.

TLE for PostgreSQL은 Amazon Aurora의 PostgreSQL 14.5 이상에서 실행할 수 있습니다.

TLE for PostgreSQL은 현재 AWS 중국 리전을 제외한 모든 AWS 리전과 AWS GovCloud 리전에서 사용할 수 있습니다.

TLE for PostgreSQL은 Aurora 고객에게 추가 비용 없이 제공됩니다.

Aurora 및 Amazon RDS는 85개 이상의 엄선된 PostgreSQL 확장 프로그램을 지원합니다. AWS는 AWS Shared Responsibility Model에 따라 이러한 각 확장 프로그램의 보안 위험을 관리합니다. TLE for PostgreSQL을 구현하는 확장 프로그램은 이 세트에 포함됩니다. 서드 파티 소스를 사용하여 작성하거나 서드 파티 소스에서 가져와서 TLE에 설치하는 확장 프로그램은 사용자 애플리케이션 코드의 일부로 간주됩니다. TLE 확장 프로그램을 사용하는 애플리케이션의 보안은 사용자의 책임입니다.

비트맵 압축 및 차등 개인 정보 보호(예: 개인의 개인 정보를 보호하는 공개 액세스 가능한 통계 쿼리)와 같은 개발자 함수를 구축할 수 있습니다.

TLE for PostgreSQL은 현재 JavaScript, PL/pgSQL, Perl, SQL을 지원합니다.

우선 rds_superuser 역할이 TLE for PostgreSQL을 활성화하면, psql과 같은 어느 PostgreSQL 클라이언트에서든 SQL CREATE EXTENSION 명령을 사용하여 TLE를 배포할 수 있습니다. 이 방법은 프로시저 언어(예: PL/pgSQL 또는 PL/Perl)로 작성된 사용자 정의 함수를 생성하는 방법과 유사합니다. 관리자는 TLE 확장 프로그램을 배포하고 특정 확장 프로그램을 사용할 권한이 있는 사용자를 제어할 수 있습니다.

TLE for PostgreSQL은 TLE API를 통해서만 PostgreSQL 데이터베이스에 액세스합니다. TLE가 지원하는 신뢰할 수 있는 언어에는 PostgreSQL 서버 프로그래밍 인터페이스(SPI)의 모든 함수가 포함되며 암호 확인 후크를 포함한 PostgreSQL 후크를 지원합니다.

TLE for PostgreSQL 프로젝트에 대해서는 공식 TLE GitHub 페이지에서 자세히 알아볼 수 있습니다.