Amazon Aurora FAQ

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

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

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

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

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

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

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

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

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

여기에서 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 설명서를 참조하세요.

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

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

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

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

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

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

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

예. Amazon Aurora 사용에 대한 데이터베이스 절감형 플랜을 구매하고 1년 동안 일정한 사용량을 약정하면 비용을 최대 35% 절감할 수 있습니다. 적격 사용량에 대한 추가 정보는 데이터베이스 절감형 플랜 요금 페이지에서 확인할 수 있습니다.

아니요. 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 인스턴스 요금 외에 Amazon Aurora for Aurora PostgreSQL 최적화된 읽기에 부과되는 추가 비용은 없습니다. 자세한 내용은 Aurora 요금 페이지를 참조하세요.

최소 스토리지는 10GiB입니다. 데이터베이스 사용량에 따라 Aurora 스토리지는 데이터베이스 성능에 영향을 미치지 않고 최대 256TiB까지 10GiB 단위로 자동으로 늘어납니다. 스토리지를 미리 프로비저닝할 필요가 없습니다. Aurora는 스토리지를 256TiB 이상으로 확장하는 Amazon Aurora PostgreSQL Limitless Database를 통해 자동화된 수평적 스케일링을 제공합니다. 자세한 내용은 Aurora PostgreSQL Limitless Database 사용을 참조하세요.

Amazon Aurora DB와 관련된 컴퓨팅 리소스를 확장하는 방법에는 Amazon Aurora Serverless, Aurora PostgreSQL Limitless Database 또는 수동 스케일링을 사용하는 세 가지 방법이 있습니다. 어떤 옵션을 선택하든 요금은 사용한 만큼만 지불하면 됩니다.

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

Aurora PostgreSQL Limitless Database를 사용하면 워크로드 요구 사항에 따라 컴퓨팅 리소스를 수평적으로 자동 스케일링하여 대규모 애플리케이션을 지원할 수 있습니다. 이렇게 하면 단일 데이터베이스 내에서 작동하는 단순성을 유지하면서 단일 데이터베이스 인스턴스의 쓰기 처리량 및 스토리지 한도 이상으로 애플리케이션을 확장하는 데 도움이 됩니다. 

AWS Management Console에서 원하는 DB 인스턴스 유형을 선택하여 데이터베이스에 연결된 컴퓨팅 리소스의 크기를 수동으로 조정할 수도 있습니다. 요청하시는 변경 사항은 지정된 유지 관리 기간에 적용되지만, '즉시 적용' 플래그를 사용해 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 인스턴스의 캐노니컬 네임 레코드(CNAME)가 정상적인 복제본을 가리키도록 변경하며, 해당 복제본이 승격되어 새로운 기본 복제본이 됩니다. 일반적으로 장애 조치는 처음부터 끝까지 30초 이내에 완료됩니다. 복원력을 개선하고 장애 조치를 더 빠르게 수행하려면 애플리케이션 연결을 유지하면서 장애 조치 DB 인스턴스에 자동으로 연결하는 Amazon RDS Proxy를 사용하는 것이 좋습니다. 프록시는 애플리케이션의 장애 조치를 투명하게 만들어 장애 조치 시간을 최대 66% 단축합니다. 
• Aurora Serverless v2는 장애 조치 및 기타 고가용성 기능을 위해 프로비저닝된 것처럼 작동합니다. 자세한 내용은 Aurora Serverless v2 및 고가용성을 참조하세요.
  
• Aurora 복제본(즉, 단일 인스턴스)이 없고 Aurora Serverless를 실행하지 않는 경우, Aurora는 원래 인스턴스와 동일한 가용 영역에 새 DB 인스턴스를 생성하려고 시도합니다. 이와 같은 원래 인스턴스 대체가 최선의 방법이며, 가용 영역에 크게 영향을 주는 문제가 발생하는 경우 등에는 성공하지 못할 수도 있습니다.

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

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

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

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

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

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

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

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

Amazon RDS 콘솔에서 단 몇 번의 클릭으로 Aurora Global Database를 생성할 수 있습니다. 또는 AWS 소프트웨어 개발 키트(SDK)나 AWS Command Line Interface(AWS CLI)를 사용할 수 있습니다. 기본 리전과 보조 리전 간에 프로비저닝된 인스턴스 또는 서버리스 인스턴스 클래스 유형의 혼합 구성을 사용할 수 있습니다. 또한 기본 리전을 Aurora I/O-Optimized 클러스터 구성으로 구성하고 보조 리전을 Aurora Standard로 구성하거나 그 반대로 구성할 수도 있습니다. 자세히 알아보려면 Amazon Aurora Global Database 생성을 참조하세요.

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

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

아니요. 기본 리전을 사용할 수 없게 되는 경우, 관리형 교차 리전 Aurora Global Database 장애 조치 작업을 사용하여 보조 리전을 전체 읽기 및 쓰기 기능을 사용하도록 승격할 수 있습니다. 또한 Aurora Global Database 작성기 엔드포인트를 사용하면 새로 승격된 리전에 연결하기 위해 애플리케이션 코드를 변경할 필요가 없습니다. 자세히 알아보려면 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 데이터베이스에 대한 의심스러운 로그인을 감지합니다. 자세한 내용은 Amazon GuardDuty RDS Protection을 이용한 위협 모니터링 및 GuardDuty RDS Protection 사용 설명서를 참조하세요.

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

요금은 데이터베이스가 활성 상태인 동안 사용한 데이터베이스 용량에 대해 초 단위로 부과됩니다. Aurora Serverless에 대해 자세히 알아보고 Amazon RDS Management Console에서 몇 단계로 시작하세요.

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 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 v2는 읽기 전용 복제본, 다중 AZ 구성, Aurora Global Database, RDS Proxy 및 Performance Insights를 포함하여 프로비저닝된 모든 Aurora 기능을 지원합니다.

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

Aurora PostgreSQL Limitless Database는 단일 데이터베이스 내에서 운영의 단순성을 유지하면서 초당 수백만 개의 쓰기 트랜잭션을 처리하고 페타바이트 규모의 데이터를 관리하는 자동화된 수평적 스케일링을 제공합니다. 대규모 애플리케이션을 구축하는 데 집중할 수 있으며, 워크로드를 지원하기 위해 다중 데이터베이스 인스턴스에서 데이터를 확장하기 위한 복잡한 솔루션을 구축 및 유지 관리할 필요가 없습니다. Aurora PostgreSQL Limitless Database는 애플리케이션 워크로드를 기반으로 확장되며, 요금은 애플리케이션에서 사용한 만큼만 지불하면 됩니다. 자세한 내용은 Aurora PostgreSQL Limitless Database 사용 설명서를 참조하세요.

수평적으로 스케일링해야 하고 단일 Aurora 데이터베이스 인스턴스가 지원하는 것보다 더 많은 쓰기 처리량 또는 데이터 스토리지 용량이 필요한 애플리케이션에는 Aurora PostgreSQL Limitless Database를 사용해야 합니다. 예를 들어 각 사용자의 회계 데이터는 서로 독립적이므로, 회계 애플리케이션을 사용자가 수평적으로 분할할 수 있습니다. Aurora PostgreSQL Limitless Database는 가장 빠르게 성장하는 대규모 애플리케이션을 지원할 수 있도록 자동으로 확장됩니다. 

확장을 위한 기존 기능으로는 Aurora 복제본을 사용하는 Amazon Aurora Auto Scaling 및 Aurora Serverless v2라는 두 가지 기능이 있습니다.

Aurora 복제본을 사용하면 Aurora 클러스터의 읽기 용량을 단일 데이터베이스 인스턴스가 제공할 수 있는 한도 이상으로 늘릴 수 있습니다. 읽기 워크로드를 쓰기 워크로드에서 분리할 수 있는 애플리케이션은 읽기 전용 복제본을 최대 15개까지 활용하여 전체 읽기 처리량을 높일 수 있습니다. Aurora 복제본은 애플리케이션이 데이터를 수평으로 분할할 필요가 없습니다. 모든 데이터를 모든 복제본에서 사용할 수 있습니다. Aurora 복제본은 Aurora 클러스터의 스토리지 용량이나 쓰기 처리량을 증가시키지 않습니다.

Aurora Serverless v2는 Aurora를 위한 온디맨드형 수직적 스케일링 구성으로, 단일 컴퓨팅 인스턴스의 용량 제약 내에서 애플리케이션 요구 사항에 따라 데이터베이스 컴퓨팅 및 메모리의 오토 스케일링을 제공합니다. Aurora Serverless v2는 작성기와 판독기 인스턴스 양쪽 모두에서 지원됩니다. 하지만 Aurora 클러스터의 스토리지 용량을 늘리지는 않습니다. 애플리케이션이 수평적으로 스케이링되도록 설계된 경우, Aurora PostgreSQL Limitless Database를 사용하면 데이터베이스의 쓰기 처리량과 스토리지 용량을 단일 Aurora 작성기 인스턴스의 한도 이상으로 확장할 수 있습니다.

Aurora PostgreSQL Limitless Database는 샤드 키라고도 하는 테이블 열의 고객이 지정한 값을 사용하여 데이터베이스 인스턴스 간에 데이터를 분할합니다. 예를 들어 사용자 정보를 저장하는 테이블은 User-ID 열을 샤드 키로 사용하여 분할할 수 있습니다. 내부적으로 살펴보면, Aurora PostgreSQL Limitless Database는 서버리스 노드의 분산 배포입니다. 노드는 라우터 또는 샤드입니다. 라우터는 데이터베이스의 분산 특성을 관리합니다. 각 샤드는 데이터의 하위 세트를 저장하므로, 병렬 처리를 통해 높은 쓰기 처리량을 달성할 수 있습니다.

컴퓨팅 또는 스토리지 요구 사항이 증가하면 Aurora는 우선 각 인스턴스 및 관련 스토리지를 자동으로 스케일 아웃한 다음, 다양한 샤드 키 값에 대한 데이터베이스 워크로드를 처리할 수 있도록 스케일 업합니다. 언제든지 단일 서버리스 인스턴스에서 샤드 키 값을 소유하고 제공합니다. 애플리케이션이 Aurora PostgreSQL Limitless Database에 연결하고 요청을 발행하면, 우선 해당 요청이 분석됩니다. 그런 다음, 요청에서 지정된 샤드 키 값을 소유한 컴퓨팅 인스턴스로 전송되거나 다중 인스턴스의 쿼리가 오케스트레이션됩니다.

각각 고유한 샤드 키 값을 제공하는 다중 컴퓨팅 인스턴스가 동일한 Aurora PostgreSQL Limitless Database에 대한 애플리케이션 요청을 동시에 처리할 수 있습니다. Aurora PostgreSQL Limitless Database는 단일 작성기 Aurora PostgreSQL 시스템과 동일한 트랜잭션 시맨틱을 제공하므로, 애플리케이션에서 다양한 트랜잭션 도메인을 관리하는 데 수반되는 복잡성이 사라집니다.

Aurora PostgreSQL Limitless Database는 데이터를 포함하는 세 가지 유형의 테이블(샤딩된 테이블, 참조 테이블, 표준 테이블)을 지원합니다.

샤딩된 테이블: 이 테이블은 여러 분할된 데이터베이스에 분산됩니다. 데이터는 테이블에 지정된 열의 값(샤드 키라고 함)에 따라 분할됩니다. 애플리케이션에서 가장 규모가 크고 가장 I/O 집약적인 테이블을 확장할 때 유용합니다.

참조 테이블: 이 테이블은 모든 샤드의 전체 데이터를 복사하므로, 불필요한 데이터 이동을 제거하여 조인 쿼리가 더 빠르게 작동할 수 있도록 합니다. 일반적으로 제품 카탈로그 및 우편 번호처럼 자주 수정되지 않는 참조 데이터에 사용됩니다.

표준 테이블: 이 테이블은 일반 Aurora PostgreSQL 테이블과 같습니다. 표준 테이블은 모두 단일 샤드에 함께 배치되므로, 불필요한 데이터 이동을 제거하여 조인 쿼리가 더 빠르게 작동할 수 있도록 합니다. 표준 테이블에서 샤딩된 테이블과 참조 테이블을 생성할 수 있습니다.

PostgreSQL 호환성 고려 사항에 대해 자세히 알아보려면 Aurora PostgreSQL Limitless Database requirements and considerations 섹션을 참조하세요.

Amazon RDS 콘솔 또는 Amazon API에서 Aurora PostgreSQL Limitless Database를 시작하여 지원되는 엔진 버전으로 새 Aurora PostgreSQL 클러스터를 생성할 수 있습니다. 시작하는 방법에 대해 자세히 알아보려면 Aurora PostgreSQL Limitless Database 사용 설명서를 참조하세요.

애플리케이션은 표준 Aurora PostgreSQL 클러스터에 연결하는 것과 동일한 방식으로 Aurora PostgreSQL Limitless Database에 연결됩니다. 클러스터 엔드포인트에 연결하기만 하면 됩니다. 자세한 내용은 Aurora PostgreSQL Limitless Database 사용 섹션을 참조하세요.

예, Aurora PostgreSQL Limitless Database를 사용하려면 데이터베이스 스키마를 조정해야 할 수 있습니다. 모든 샤딩된 테이블은 샤드 키를 포함해야 하므로, 이 데이터를 다시 채워야 할 수 있습니다. 예를 들어 회계 애플리케이션은 각 사용자가 서로 독립적이므로, User-ID 열을 사용하여 데이터를 사용자별로 분할할 수 있습니다. 사용자 테이블 자체에는 당연히 이 열이 포함되어 있지만,
다른 테이블(예: 인보이스 품목이 들어 있는 테이블)은 그렇지 않을 수 있습니다. 또한 쿼리 성능을 최적화하려면 이러한 테이블을 사용자가 분할하여 테이블을 콜로케이션해야 하므로, User-ID 열을 테이블에 추가해야 합니다.

데이터를 분할하는 데 사용되는 열은 이름 지정 제약이 없지만, 열 정의는 일치해야 합니다. 애플리케이션 쿼리에 샤드 키를 추가해야 하며, 최적의 성능을 위해 쿼리와 트랜잭션을 조정해야 할 수도 있습니다. 예를 들어 테이블이 User-ID로만 분할된 경우 Invoice-ID를 사용하여 인보이스를 조회하면 모든 데이터베이스 인스턴스에서 쿼리를 실행해야 하므로 속도가 느려집니다. 하지만 쿼리가 User-ID도 지정하면 해당 User-ID에 대한 모든 주문이 포함된 단일 데이터베이스 인스턴스로 쿼리가 라우팅되므로, 쿼리 지연 시간이 줄어듭니다.

예. 99.99%의 가용성을 제공하는 Aurora PostgreSQL Limitless Database의 컴퓨팅 이중화를 0보다 크게 설정하면 고가용성 옵션을 선택할 수 있습니다. Aurora PostgreSQL Limitless Database의 데이터를 저장하고 액세스하는 각 컴퓨팅 인스턴스에는 프라이머리를 사용할 수 없는 경우, 요청을 인계할 수 있는 하나 또는 두 개의 스탠바이가 존재할 수 있습니다. 라우터는 애플리케이션에 미치는 영향을 최소화하기 위해 트래픽을 자동으로 리디렉션합니다.

Aurora PostgreSQL Limitless Database는 PostgreSQL 16.4와 호환되는 Aurora I/O-Optimized 클러스터 구성에 사용할 수 있습니다. Aurora PostgreSQL Limitless Database의 AWS 리전별 가용성에 관한 추가 정보는 Aurora 요금 페이지에서 확인할 수 있습니다.

Aurora PostgreSQL Limitless Database에서 데이터베이스 용량은 ACU로 측정됩니다. 요금은 ACU 사용량에 따라 초당 정액 요금으로 부과됩니다. Aurora I/O-Optimized 구성 스토리지 요금이 적용됩니다. 자세한 내용은 Aurora 요금 페이지를 참조하세요.

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

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

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

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

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

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

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

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

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

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

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

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

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

병렬 쿼리는 Amazon Aurora의 MySQL 5.7 및 MySQL 8.0 호환 버전에서 사용할 수 있습니다.

병렬 쿼리는 Aurora Serverless v2 및 역추적과 호환됩니다.

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

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

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

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용 오픈 소스 확장 프로그램입니다.

pgvector를 사용하면 Amazon Bedrock 또는 Amazon SageMaker 등의 기계 학습(ML) 및 인공 지능(AI) 모델로부터 생성되는 수십억 개의 임베딩을 데이터베이스에 저장, 검색, 인덱싱 및 쿼리할 수 있습니다. 벡터 임베딩은 텍스트, 이미지, 비디오와 같은 콘텐츠의 의미 체계 의미를 나타내는 숫자 표현입니다.

pgvector를 사용하면 Aurora PostgreSQL 데이터베이스의 임베딩을 쿼리하여 Aurora의 다른 테이블 형식 데이터와 결합되어 벡터로 표시되는 이러한 데이터 유형에 대한 의미론적 유사성 검색을 효율적으로 수행할 수 있습니다. 이렇게 하면 유사한 텍스트 설명 또는 이미지를 기반으로 한 맞춤형 추천, 인터뷰 노트, 챗봇을 기반으로 한 후보자 매칭, 성공적인 녹취록이나 채팅 세션 대화를 기반으로 한 고객 서비스 차선책 추천 등과 같은 새로운 유형의 애플리케이션에 생성형 AI 및 기타 AI/ML 시스템을 사용할 수 있습니다. 

벡터 데이터베이스 기능에 대한 블로그를 읽고, pgvector 확장 프로그램을 사용하여 Aurora PostgreSQL 데이터베이스에 임베딩을 저장하며, 대화형 질문 응답 챗봇을 만들고, pgvector와 Aurora 기계 학습 간의 기본 통합을 감정 분석에 사용하는 방법을 알아보세요.

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

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

예. Amazon Aurora 데이터베이스를 Amazon Bedrock과 통합하여 생성형 AI 애플리케이션을 지원하는 두 가지 방법이 있습니다. 첫째, Amazon Aurora ML은 Aurora MySQL과 Aurora PostgreSQL 모두에 대해 SQL을 통해 직접 Amazon Bedrock에서 사용 가능한 파운데이션 모델에 대한 액세스를 제공합니다. 둘째, 클릭 한 번으로 Aurora를 Amazon Bedrock의 지식 기반으로 벡터 저장소로 구성하고 Bedrock에서 생성된 임베딩을 Aurora에 저장할 수 있습니다. Amazon Bedrock 지식 기반은 Aurora PostgreSQL을 검색 증강 생성(RAG)과 같은 사용 사례를 위한 벡터 저장소로 지원합니다. Aurora PostgreSQL을 Amazon Bedrock의 지식 기반으로 사용하는 것에 대한 설명서와 블로그를 읽어 보세요.

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

Aurora 최적화된 읽기를 사용하여 Aurora PostgreSQL의 쿼리 성능을 개선하는 방법에 대한 설명서와 블로그를 읽어보세요.

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

Amazon SageMaker와의 Amazon Aurora 제로 ETL 통합을 통해 운영 데이터베이스 및 애플리케이션의 데이터를 레이크하우스에 거의 실시간으로 가져올 수 있습니다. SageMaker의 레이크하우스 아키텍처를 사용하면 데이터 아키텍처를 변경하지 않고도 기존 데이터 투자를 기반으로 개방형 레이크하우스를 빌드하고 SQL, Apache Spark, BI 및 AI/ML 도구와 같은 선호하는 분석 도구와 쿼리 엔진을 사용할 수 있습니다.

Amazon Redshift와의 Aurora 제로 ETL 통합은 Aurora MySQL 3.05.2 버전(MySQL 8.0.32와 호환 가능) 이상을 위한 Aurora MySQL 호환 에디션에서 사용할 수 있습니다. Amazon Redshift와의 Aurora 제로 ETL 통합은 Aurora PostgreSQL 16.4 버전 이상을 위한 Aurora PostgreSQL 호환 에디션에서 사용할 수 있습니다.

Amazon SageMaker와의 Aurora 제로 ETL 통합은 Aurora MySQL 3.05.0 버전(MySQL 8.0.32와 호환 가능) 이상을 위한 Aurora MySQL 호환 에디션에서 사용할 수 있습니다. Amazon SageMaker와 Aurora의 제로 ETL 통합은 Aurora PostgreSQL for Aurora PostgreSQL 호환 에디션 16.4 버전 이상 Aurora PostgreSQL 17.4 버전 이상에서 사용할 수 있습니다.

Aurora 제로 ETL 통합에 대한 AWS 리전 가용성을 자세히 알아보려면 AWS 리전 및 Aurora DB 엔진별 Aurora의 지원 기능을 참조하세요.

Amazon Redshift 및 Amazon SageMaker와의 Aurora 제로 ETL 통합은 복잡한 데이터 파이프라인을 구축하고 유지 관리해야 하는 필요성을 없애줍니다. 다양한 Aurora 데이터베이스 클러스터의 여러 테이블의 데이터를 단일 Amazon Redshift 데이터베이스 클러스터 또는 SageMaker의 레이크하우스 아키텍처 고와 통합하고, Aurora의 운영 데이터에서 거의 실시간 분석 및 ML을 실행할 수 있습니다.

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

Amazon SageMaker와의 Aurora 제로 ETL 통합은 Aurora Serverless v2와 호환됩니다.

Amazon RDS 콘솔에서 Aurora 소스와 목표 대상을 지정하여 제로 ETL 통합을 생성하고 시작할 수 있습니다. 통합이 생성되면 Aurora 데이터베이스가 대상에 복제되고, 초기 시드가 완료되면 데이터 쿼리를 시작할 수 있습니다. 자세한 내용은 Amazon Redshift와의 Aurora 제로 ETL 통합 및 Amazon SageMaker와의 Aurora 제로 ETL 통합에 대한 시작하기 가이드를 참조하세요.

제로 ETL 통합을 통한 지속적인 데이터 변경 처리는 추가 비용 없이 제공됩니다. 제로 ETL 통합을 생성하고 제로 ETL 통합의 일부로 생성되는 변경 데이터를 처리하는 데 사용한 기존 리소스에 대한 요금이 부과됩니다. 이러한 리소스에는 다음이 포함될 수 있습니다.

• 향상된 binlog를 활성화하여 사용된 추가 I/O 및 스토리지
• 데이터베이스를 시드하기 위한 초기 데이터 내보내기에 드는 스냅샷 내보내기 비용
• 복제된 데이터를 저장하기 위한 추가 스토리지
• 데이터 복제를 처리하기 위한 추가 컴퓨팅
• 소스에서 대상으로 데이터를 이동하는 데 드는 AZ 사이의 데이터 전송 비용

자세한 내용은 Aurora 요금 페이지를 참조하세요.

예. AWS CloudFormation을 사용하여 Aurora 제로 ETL 통합에 대해 필요한 리소스의 구성 및 배포를 쉽게 관리하고 자동화할 수 있습니다. 자세한 내용은 제로 ETL 통합을 사용하는 CloudFormation 템플릿을 참조하세요.

CloudWatch Database Insights는 데이터베이스 문제 해결을 간소화하고 개선하는 모니터링 및 지표 솔루션입니다. 지표, 로그, 트레이스를 포함한 텔레메트리 수집을 자동화하므로 수동 설정 및 구성이 필요 없습니다. CloudWatch Database Insights는 이러한 텔레메트리를 Amazon Cloudwatch에 통합함으로써 데이터베이스 성능 및 상태에 대한 통합 보기를 제공합니다.

CloudWatch Database Insights의 주요 이점은 다음과 같습니다.

1. 간편한 텔레메트리 수집: 데이터베이스 지표, 로그 및 트레이스를 자동으로 수집하여 설정 시간을 최소화합니다.
2. 큐레이팅 인사이트: 시작하는 데 필요한 최소한의 구성으로 데이터베이스 성능을 모니터링하고 최적화하기 위한 사전 구축된 대시보드, 경보 및 인사이트를 제공합니다.
3. 통합 CloudWatch 보기: 여러 데이터베이스의 텔레메트리를 하나의 보기로 결합하여 모니터링을 간소화합니다.
4. AI/ML 기능: AI/ML을 사용하여 이상을 감지하고 수동 문제 해결 작업을 줄입니다.
5. 애플리케이션 컨텍스트 모니터링: 사용자가 데이터베이스 성능과 애플리케이션 성능의 상관관계를 파악할 수 있습니다.
6. 플릿 및 인스턴스 수준 보기: 개괄적인 플릿 모니터링과 근본 원인 분석을 위한 세부 인스턴스 보기를 모두 제공합니다.
7. 원활한 AWS 통합: Amazon CloudWatch Application Signals 및 AWS X-Ray와 통합되어 포괄적인 관찰성 환경을 제공합니다.

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

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 Performance Insights(PI)에서 수집한 원격 측정 데이터를 분석합니다. DevOps Guru for RDS는 데이터베이스에 저장된 데이터를 분석에 사용하지 않습니다. PI는 애플리케이션이 데이터베이스에서 시간을 보내는 방식을 특성화하는 지표인 데이터베이스 로드를 측정하고 MySQL의 서버 상태 변수 및 PostgreSQL의 pg_stat 테이블과 같이 데이터베이스에서 생성된 선택된 지표를 측정합니다.

DevOps Guru for RDS를 시작하려면 RDS 콘솔을 통해 Performance Insights가 사용되는지 확인한 다음 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 Performance Insights는 Amazon RDS 데이터베이스 성능 지표를 수집하고 시각화하는 데이터베이스 성능 조정 및 모니터링 기능으로, 데이터베이스의 로드를 빠르게 평가하고 언제 어디에서 조치해야 하는지 파악하는 데 도움이 됩니다. Amazon DevOps Guru for RDS는 이러한 지표를 모니터링하고, 데이터베이스에 성능 문제가 발생하는 시기를 감지하며, 지표를 분석한 다음, 무엇이 잘못되었고 이에 대해 무엇을 할 수 있는지 알려주도록 설계되었습니다.

CloudWatch Database Insights는 Aurora 리소스 및 애플리케이션을 실시간으로 모니터링하고 사용자 지정 가능한 대시보드를 통해 데이터를 제공합니다. 이와 반대로 Amazon DevOps Guru는 CloudWatch 지표를 분석하여 시간 경과에 따른 애플리케이션 동작을 파악하고, 이상을 감지하며, 문제 해결을 위한 인사이트와 권장 사항을 제공하는 기계 학습(ML) 서비스입니다. 또한 DevOps Guru는 AWS Config, AWS CloudFormation, AWS X-Ray를 비롯한 여러 소스의 데이터를 분석합니다. CloudWatch 대시보드를 사용하여 AWS/DevOps-Guru 네임스페이스에 게시된 지표를 통해 DevOps Guru 인사이트를 모니터링할 수 있습니다. 이를 통해 CloudWatch 콘솔의 단일 창에서 모든 인사이트와 이상을 확인할 수 있습니다.

RDS Performance Insights는 고객이 데이터베이스의 로드를 평가하고 언제 어디에서 조치를 취해야 하는지 결정할 수 있게 하는 데이터베이스 성능 튜닝 및 모니터링 기능입니다. CloudWatch Database Insights는 플릿 수준 모니터링, 애플리케이션 성능 모니터링과의 통합, 데이터베이스 지표와 로그 및 이벤트의 상관관계와 함께 Performance Insights의 모든 기능을 상속하는 새로운 데이터베이스 관찰성 기능입니다.

새로운 현대적 애플리케이션, 특히 AWS Lambda로 구축되어 요청/응답 모델에서 Aurora에 액세스해야 하는 애플리케이션에는 데이터 API를 사용해야 합니다. 기존 애플리케이션이 데이터베이스 드라이버와 고도로 연결되어 있거나, 쿼리가 오래 실행되거나, 개발자가 임시 테이블과 같은 데이터베이스 기능을 활용하거나 세션 변수를 사용하려는 경우에는 데이터 API 대신 데이터베이스 드라이버를 사용하고 영구 데이터베이스 연결을 관리해야 합니다.

Aurora Serverless v2 및 Aurora 프로비저닝 인스턴스에 대한 데이터 API AWS 리전과 데이터베이스 버전 가용성은 설명서에서 확인할 수 있습니다.

데이터 API를 사용하면 빠르고 간편하게 현대적 애플리케이션을 개발할 수 있습니다. 데이터 API는 데이터베이스 드라이버를 배포하거나, 클라이언트 측 연결 풀을 관리하거나, 애플리케이션과 데이터베이스 간에 복잡한 VPC 네트워킹을 설정할 필요 없이 쉽고 안전하게 사용할 수 있는 HTTP 기반 API입니다. 또한 데이터 API는 데이터베이스 연결을 자동으로 풀링 및 공유하여 확장성을 개선합니다. 이렇게 하면 연결을 자주 열고 닫는 애플리케이션의 계산 오버헤드가 줄어듭니다. 

Aurora Serverless v2 및 Aurora 프로비저닝 인스턴스용 데이터 API는 Aurora Global Database 라이터 인스턴스를 지원합니다.

사용자는 권한이 있는 경우에만 데이터 API 작업을 간접 호출할 수 있습니다. 관리자는 사용자 권한을 정의하는 AWS Identity and Access Management(IAM) 정책을 연결하여 사용자에게 데이터 API 사용 권한을 부여할 수 있습니다. IAM 역할을 사용하는 경우 역할에 정책을 연결해도 됩니다. 데이터 API를 직접 호출할 때 AWS Secrets Manager의 보안 암호를 사용하여 Aurora DB 클러스터에 대한 자격 증명을 전달할 수 있습니다. 

Aurora Serverless v2 및 Aurora 프로비저닝 인스턴스용 데이터 API는 Aurora 요금 페이지의 설명과 같이 API 요청 볼륨 기준으로 요금이 부과됩니다. Aurora Serveless v2 및 Aurora 프로비저닝 인스턴스용 데이터 API는 관리 이벤트와 달리 AWS CloudTrail 데이터 플레인 이벤트를 사용하여 활동을 로깅합니다.

이 활동을 추적하려는 경우 CloudTrail 콘솔, CLI 또는 SDK를 통해 데이터 이벤트 로깅을 활성화할 수 있습니다. 이 경우 CloudTrail 요금 페이지에 명시된 대로 요금이 부과됩니다. 또한 AWS Secrets Manager를 사용할 경우 AWS Secrets Manager 요금 페이지에 명시된 대로 요금이 부과됩니다. 

AWS CloudTrail은 AWS API 활동을 관리 이벤트 또는 데이터 이벤트로 캡처합니다. CloudTrail 관리 이벤트(‘컨트롤 플레인 작업’이라고도 함)는 리소스 생성, 업데이트, 삭제 등 AWS 계정 내에서 리소스에 수행된 관리 작업을 보여줍니다. CloudTrail 데이터 이벤트(‘데이터 영역 작업’이라고도 함)는 AWS 계정의 리소스에서 또는 리소스 내에서 수행된 리소스 작업을 보여줍니다.

데이터 API는 Aurora 데이터베이스 안의 데이터에 대해 쿼리를 수행하므로 데이터 영역 작업을 수행합니다. 따라서 데이터 API 활동은 올바른 이벤트 분류에 따라 데이터 이벤트로 로깅됩니다. 데이터 이벤트 로깅을 활성화한 경우 CloudTrail 데이터 이벤트에 대한 요금만 부과됩니다.

예. 데이터 API 프리 티어에는 첫 해 사용에 대해 전체 AWS 리전을 합산한 월 100만 건의 요청이 포함됩니다. 1년 후에는 Aurora 요금 페이지에 설명된 대로 데이터 API 요금이 부과되기 시작합니다.

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 Performance Insights 비용)이 포함됩니다. 실질적으로 블루 및 그린 배포가 진행되는 동안 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 블루/그린 배포의 전환 가드레일은 전환 전에 그린 환경이 캐치업될 때까지 블루 및 그린 환경에 대한 쓰기를 차단합니다. 블루 및 그린 배포는 블루 및 그린 환경에 있는 프라이머리 및 복제본의 상태 확인도 수행합니다. 또한 복제 상태 확인도 수행하는데, 예를 들어 복제가 중지되었는지, 오류가 있는지 여부를 확인합니다. 블루 환경과 그린 환경 사이에 오래 실행되는 트랜잭션이 있는 경우 이를 감지합니다. 사용자는 허용 가능한 최대 가동 중지 시간을 최소 30초로 지정할 수 있으며, 진행 중인 트랜잭션이 이 값을 초과할 경우 전환 제한 시간이 초과됩니다.

블루 환경이 자체 관리형 논리적 복제본 또는 구독자인 경우 전환이 차단됩니다. 먼저 블루 환경으로의 복제를 중단하고, 전환을 진행한 다음 복제를 재개하는 것이 좋습니다. 반대로 블루 환경이 자체 관리형 논리적 복제본이나 게시자의 소스인 경우에는 계속 전환할 수 있습니다. 하지만 전환 후 친환경 환경에서 복제하려면 자체 관리형 복제본을 업데이트해야 합니다.

예. Amazon RDS 블루/그린 배포는 Amazon Aurora Global Database를 지원합니다. 자세한 내용은 Blue/Green Deployments for Amazon Aurora Global Database User 가이드를 참조하세요.

아니요. Amazon RDS 블루/그린 배포는 Amazon Amazon RDS Proxy 또는 교차 리전 읽기 전용 복제본을 지원하지 않습니다. 

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

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

PostgreSQL 확장 프로그램은 고성능을 제공하기 위해 동일한 프로세스 공간에서 실행됩니다. 그러나 확장 프로그램에 소프트웨어 결함이 있는 경우 데이터베이스가 충돌할 수 있습니다.

TLE for PostgreSQL은 여러 계층의 보호를 통해 이 위험을 완화합니다. TLE는 시스템 리소스에 대한 액세스를 제한하도록 설계되었습니다. rds_superuser 역할은 특정 확장 프로그램을 설치할 수 있는 사용자를 결정할 수 있습니다. 그러나 이러한 변경 사항은 TLE API를 통해서만 수행될 수 있습니다. TLE는 확장 프로그램의 결함이 미치는 영향을 단일 데이터베이스 연결로 제한합니다. 이러한 보호 장치에 더해 TLE는 rds_superuser 역할의 DBA에게 세분화된 온라인 제어를 제공하도록 설계되었습니다. 이 DBA는 확장 프로그램을 설치할 수 있는 사용자를 제어할 수 있고 확장 프로그램의 실행을 위한 권한 모델을 생성할 수 있습니다. 충분한 권한이 있는 사용자만 TLE 확장 프로그램에서 ‘CREATE EXTENSION’ 명령을 사용하여 확장 프로그램을 실행하고 생성할 수 있습니다. 또한 DBA는 데이터베이스의 내부 동작을 수정하고 일반적으로 권한 상승이 요구되는 보다 정교한 확장 프로그램에 필요한 ‘PostgreSQL 후크’를 허용 목록에 추가할 수 있습니다.

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 공동 책임 모델에 따라 이러한 각 확장 프로그램의 보안 위험을 관리합니다. 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 페이지에서 자세히 알아볼 수 있습니다.