일반

Q: Amazon Aurora란 무엇입니까?

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

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

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

Q: ‘MySQL 호환’이란 어떤 의미인가요?

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

Q: "PostgreSQL 호환"이란 어떤 의미인가요?

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

Q: Amazon Aurora와 Amazon Relational Database Service(Amazon RDS)에 대해 어떻게 생각하시나요?

A: Amazon RDS는 7가지 관계형 데이터베이스 엔진(PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Amazon Aurora MySQL 호환 버전, Amazon Aurora PostgreSQL 호환 버전) 중에서 원하는 엔진을 간단하게 설정, 운영 및 실행할 수 있는 완전관리형 고가용성 보안 데이터베이스 서비스입니다. 

Amazon Aurora MySQL 호환 버전 및 Amazon Aurora PostgreSQL 호환 버전은 시간 소모적인 데이터베이스 관리 태스크 자동화와 같은 Amazon RDS의 이점을 활용하고 커뮤니티 오픈 소스 MySQL 및 PostgreSQL보다 향상된 성능, 확장성 및 가용성을 제공합니다.

Q: Amazon Aurora를 사용하려면 어떻게 해야 하나요?

Amazon Aurora를 사용하려면 AWS 관리 콘솔에 로그인하고, 데이터베이스(Database) 범주 아래에서 RDS를 선택한 후, Amazon Aurora를 데이터베이스 엔진으로 선택합니다.

Q: Amazon Aurora의 사용료는 얼마인가요?

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

Q: Amazon Aurora는 내 데이터베이스 볼륨의 각 청크를 6가지 방법으로 3개의 가용 영역에 복제합니다. 그렇다면 실질적인 스토리지 요금이 요금 페이지에 표시된 요금의 3배 또는 6배가 된다는 말입니까?

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

Q: 어떤 AWS 리전에서 Amazon Aurora를 사용할 수 있나요?

리전과 요금에 대한 최신 정보는 Aurora 요금 페이지를 참조하세요.

Q: MySQL에서 Amazon Aurora로 또는 그 반대로 마이그레이션하려면 어떻게 해야 하나요?

여러 가지 옵션이 있습니다. 표준 mysqldump 유틸리티를 사용하여 MySQL에서 데이터를 내보내고 mysqlimport 유틸리티를 사용하여 Amazon Aurora로 데이터를 가져올 수 있습니다. 그 반대도 마찬가지입니다. 또한, AWS 관리 콘솔에서 Amazon RDS의 DB 스냅샷 마이그레이션 기능을 이용하여 Amazon RDS for MySQL DB 스냅샷을 Amazon Aurora로 마이그레이션할 수 있습니다. 대부분 고객은 1시간 이내에 마이그레이션을 완료하지만, 이 기간은 형식과 데이터 집합의 크기에 따라 달라집니다. 자세한 내용은 MySQL 데이터베이스를 Amazon Aurora로 마이그레이션하는 모범 사례를 참조하세요.

Q: PostgreSQL에서 Amazon Aurora로 또는 그 반대로 마이그레이션하려면 어떻게 해야 합니까?

여러 가지 옵션이 있습니다. 표준 pg_dump 유틸리티를 사용하여 PostgreSQL에서 데이터를 내보내고 pg_restore 유틸리티를 사용하여 Amazon Aurora로 데이터를 가져올 수 있으며 그 반대도 마찬가지입니다. 또한 AWS 관리 콘솔에서 Amazon RDS의 DB 스냅샷 마이그레이션 기능을 이용하여 Amazon RDS for PostgreSQL DB 스냅샷을 Amazon Aurora로 마이그레이션할 수 있습니다. 대부분 고객은 1시간 이내에 마이그레이션을 완료하지만, 이 기간은 형식과 데이터 집합의 크기에 따라 달라집니다. SQL Server 애플리케이션을 Aurora PostgreSQL 호환 버전으로 마이그레이션하려면 Babelfish for Aurora PostgreSQL을 사용합니다. 자세한 내용은 Babelfish 기능 페이지를 참조하세요.

Q: Amazon Aurora는 AWS 프리 티어에 포함되나요?

현재는 지원되지 않습니다. Amazon RDS용 AWS 프리 티어는 마이크로 DB 인스턴스의 이점을 제공하지만 Amazon Aurora는 현재 마이크로 DB 인스턴스 지원을 제공하지 않습니다. 최신 요금 정보는 Aurora 요금 페이지를 참조하세요.

Q: Amazon Aurora의 I/O란 무엇이며 어떻게 계산되나요?

I/O는 Aurora 데이터베이스 엔진에서 SSD(Solid State Drive) 기반 가상화 스토리지 계층에 대해 수행하는 입/출력 작업입니다. 모든 데이터베이스 페이지 읽기 작업은 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 관리 콘솔에서 확인할 수 있습니다. Aurora 인스턴스가 얼마나 많은 I/O 요청을 사용하는지는 AWS 관리 콘솔에서 확인할 수 있습니다. I/O 사용량을 확인하려면 콘솔의 Amazon RDS 섹션에서 인스턴스 목록을 찾아, Aurora 인스턴스를 선택한 후 모니터링 섹션에서 “결제된 읽기 작업(Billed read operations)” 및 “결제된 쓰기 작업(Billed write operations)” 지표를 보면 됩니다.

Q: Amazon Aurora PostgreSQL 호환 버전을 사용하려면 클라이언트 드라이버를 교체해야 하나요?

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

성능

Q: "MySQL 성능의 5배"란 어떤 의미입니까?

Amazon Aurora는 데이터베이스 워크로드용으로 구축한 SSD 기반 가상 스토리지 계층과 데이터베이스 엔진을 긴밀하게 통합하여 스토리지 시스템으로의 쓰기를 줄이고 잠금 경합을 최소화하며 데이터베이스 프로세스 스레드에서 생성된 지연을 제거함으로써 MySQL의 성능을 대폭 향상했습니다. r3.8xlarge 인스턴스에서 SysBench로 테스트한 결과 Amazon Aurora는 초당 조회 500,000 SELECT와 초당 UPDATE 100,000회를 제공하며, 이는 동일한 하드웨어에서 동일한 벤치마크를 실행하는 MySQL보다 5배 높은 수치입니다. 이 벤치마크에 대한 자세한 지침과 직접 복제하는 방법은 Amazon Aurora MySQL 호환 버전 성능 벤치마킹 가이드에 나와 있습니다.

Q: 'PostgreSQL 성능의 3배'란 어떤 의미인가요?

Amazon Aurora는 데이터베이스 워크로드용으로 구축한 SSD 기반 가상 스토리지 계층과 데이터베이스 엔진을 긴밀하게 통합하여 스토리지 시스템으로의 쓰기를 줄이고 잠금 경합을 최소화하며 데이터베이스 프로세스 스레드에서 생성된 지연을 제거함으로써 PostgreSQL의 성능을 대폭 향상했습니다. r4.16xlarge 인스턴스에서 SysBench로 테스트한 결과 Amazon Aurora는 동일한 하드웨어에서 동일한 벤치마크를 실행하는 PostgreSQL보다 3배 높은 초당 SELECT 수와 초당 UPDATE 수를 제공합니다. 이 벤치마크에 대한 자세한 지침과 직접 복제하는 방법은 Amazon Aurora PostgreSQL 호환 버전 성능 벤치마킹 가이드에 나와 있습니다.

Q: Amazon Aurora MySQL 호환 버전에 맞춰 내 데이터베이스 워크로드를 최적화하려면 어떻게 해야 하나요?

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

Q: Amazon Aurora PostgreSQL 호환 버전에 맞춰 내 데이터베이스 워크로드를 최적화하려면 어떻게 해야 하나요?

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

하드웨어 및 규모 조정

Q: Amazon Aurora 데이터베이스의 최소 및 최대 스토리지 한도는 어떻게 되나요?

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

Q: Amazon Aurora DB 인스턴스와 관련된 컴퓨팅 리소스를 확장하려면 어떻게 해야 합니까?

AWS Management Console에서 원하는 DB 인스턴스를 선택하고 [Modify] 버튼을 클릭하면 DB 인스턴스에 할당된 컴퓨팅 리소스를 확장할 수 있습니다. 메모리와 CPU 리소스를 수정하려면 DB 인스턴스 클래스를 변경합니다.

DB 인스턴스 클래스를 수정하면 지정한 유지 관리 기간에 요청한 변경 사항이 적용됩니다. 또는 'Apply Immediately' 플래그를 사용하면 조정 요청을 즉시 적용할 수 있습니다. 이 두 옵션을 사용하면 조정 작업이 수행되는 몇 분 동안 가용성에 영향을 미칩니다. 처리되지 않은 다른 시스템 변경 내용도 함께 적용됩니다.

백업 및 복원

Q: 내 DB 인스턴스에 대해 백업을 활성화하려면 어떻게 해야 합니까?

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

Q: DB 스냅샷을 만들고 원하는 동안 보관할 수 있습니까?

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

Q: 데이터베이스에 오류가 발생하면 어떻게 복구되나요?

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

Q: DB 인스턴스를 삭제하면 자동화된 백업과 DB 스냅샷은 어떻게 되나요?

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

Q: 내 스냅샷을 다른 AWS 계정과 공유할 수 있습니까?

예. Aurora는 데이터베이스 스냅샷을 생성할 수 있는 기능을 제공하며, 이 스냅샷은 나중에 데이터베이스를 복원하는 데 사용할 수 있습니다. 다른 AWS 계정과 스냅샷을 공유할 수 있으며, 수신 계정의 소유자는 사용자의 스냅샷을 사용하여 사용자의 데이터가 포함된 DB를 복원할 수 있습니다. 스냅샷을 퍼블릭으로 설정할 수도 있습니다. 즉, 누구나 사용자의 (퍼블릭) 데이터가 포함된 DB를 복원할 수 있습니다. 이 기능을 사용하면 AWS 계정이 서로 다른 다양한 환경(프로덕션, 개발/테스트, 스테이징 등) 간에 데이터를 공유할 수 있고, 기본 AWS 계정이 손상될 경우에 대비하여 별도의 계정에 모든 데이터 백업을 안전하게 유지할 수 있습니다.

Q: 공유된 스냅샷에도 요금이 부과됩니까?

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

Q: 스냅샷을 자동으로 공유할 수 있습니까?

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

Q: 스냅샷은 몇 개의 계정과 공유할 수 있습니까?

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

Q: 어느 리전에서 Aurora 스냅샷을 공유할 수 있습니까?

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

Q: Aurora 스냅샷을 다른 리전과 공유할 수 있습니까?

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

Q: 암호화된 Aurora 스냅샷을 공유할 수 있습니까?

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

고가용성 및 복제

Q: Amazon Aurora는 디스크 장애에 대한 데이터베이스 내결함성을 어떻게 개선하나요?

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

Q: Aurora는 데이터베이스 오류 발생 후의 복구 시간을 어떻게 향상하나요?

다른 데이터베이스와 달리 데이터베이스 오류가 발생한 후 Amazon Aurora는 데이터베이스를 작업에 사용하기 전에 마지막 데이터베이스 검사점의 다시 실행 로그를 리플레이하여(대개 5분) 모든 변경 사항이 적용되었는지 확인할 필요가 없습니다. 따라서 대부분의 경우 데이터베이스 재시작 시간이 60초 미만으로 줄어듭니다. Amazon Aurora는 데이터베이스 프로세스에서 버퍼 캐시를 이동하여 재시작 즉시 사용할 수 있도록 합니다. 이렇게 하면 캐시가 다시 채워질 때까지는 액세스를 제한할 필요가 없어 중단이 방지됩니다.

Q: Aurora는 어떤 종류의 복제본을 지원하나요?

Amazon Aurora MySQL 호환 버전과 Amazon Aurora PostgreSQL 호환 버전에서는 같은 AWS 리전에서 기본 인스턴스와 동일한 기본 볼륨을 공유하는 Amazon Aurora 복제본을 지원합니다. 기본 인스턴스에서 수행한 업데이트는 모든 Amazon Aurora 복제본에 표시됩니다. 또한 Amazon Aurora MySQL 호환 버전에서는 MySQL의 binlog 기반 복제 엔진을 토대로 교차 리전 MySQL 읽기 전용 복제본을 생성할 수 있습니다. MySQL 읽기 전용 복제본의 기본 인스턴스 데이터는 복제본에서 트랜잭션으로 리플레이됩니다. 읽기 조정 및 고가용성을 포함한 대부분의 사용 사례에서 Amazon Aurora 복제본을 사용하는 것이 좋습니다.

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

기능 Amazon Aurora 복제본
MySQL 복제본
복제본 개수 최대 15개 최대 5개
복제본 유형 비동기식(밀리초) 비동기식(초)
기본에 대한 성능 영향 낮음 높음
복제본 위치 리전 내
교차 리전
장애 조치 대상 역할 예(데이터 손실 없음) 예(몇 분의 데이터 손실 가능)
자동화된 장애 조치 아니요
사용자 정의 복제 지연 지원 아니요
다른 데이터 또는 스키마 및 기본 지원 아니요

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

Q: Amazon Aurora는 교차 리전 복제를 지원하나요?

예. 물리적 또는 논리적 복제를 사용하여 교차 리전 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 복제를 기반으로 하므로, 복제 지연 시간은 변경/적용률과 선택한 특정 리전 간의 네트워크 통신 지연에 따라 달라집니다.

Q: 교차 리전 복제본 클러스터에 Aurora 복제본을 생성할 수 있습니까?

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

Q: 내 애플리케이션을 현재 기본 복제본에서 교차 리전 복제본으로 장애 조치할 수 있나요?

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

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

Q: 장애 조치 대상인 특정 복제본에 다른 복제본보다 높은 우선순위를 지정할 수 있나요?

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

Q: 인스턴스에 대한 우선순위 티어를 생성한 후에 이를 변경할 수 있습니까?

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

Q: 특정 복제본이 기본 인스턴스로 승격되는 것을 방지할 수 있습니까?

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

Q: 단일 Amazon Aurora 데이터베이스의 가용성을 향상하려면 어떻게 해야 합니까?

Amazon Aurora 복제본을 추가할 수 있습니다. 동일한 AWS 리전의 Aurora 복제본은 기본 인스턴스와 동일한 기본 스토리지를 공유합니다. 모든 Aurora 복제본은 데이터 손실 없이 기본 복제본으로 승격될 수 있으므로 프라이머리 DB 인스턴스에 장애가 발생하는 경우 내결함성 향상에 사용될 수 있습니다. 데이터베이스 가용성을 높이려면 3개의 가용 영역에 15~15개의 복제본을 만들면 됩니다. 그러면 데이터베이스가 중단되는 경우 Amazon RDS가 자동으로 이러한 복제본을 장애 조치 기본 선택에 포함합니다.

데이터베이스를 여러 AWS 리전에 걸쳐 확장하려는 경우 Amazon Aurora Global Database를 사용하면 됩니다. 그러면 데이터베이스 성능에 전혀 영향을 주지 않고 데이터를 복제하고 리전 규모의 가동 중단 발생 시 재해 복구를 제공할 수 있습니다.

Q: 장애 조치 진행 시 어떤 일이 발생하며 얼마나 오래 걸리나요?

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

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

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

Q: 프라이머리 데이터베이스가 있고 Amazon Aurora 복제본이 읽기 트래픽을 활발하게 처리하는 동안 장애 조치가 수행되면 어떤 일이 발생하나요?

Amazon Aurora는 기본 인스턴스와 관련된 문제를 자동으로 감지하고 장애 조치를 트리거합니다. 클러스터 엔드포인트를 사용하는 경우 읽기/쓰기 연결은 기본으로 승격된 Amazon Aurora 복제본에 자동으로 재지정됩니다. 또한, Aurora 복제본에서 처리하던 읽기 트래픽이 잠시 중단됩니다. 클러스터 리더 엔드포인트를 사용하여 읽기 트래픽을 Aurora 복제본으로 지정하는 경우 이전 기본 노드가 복제본으로 복구되기 전까지 읽기 전용 연결만 새로 승격된 Aurora 복제본으로 지정됩니다.

Q: 기본 인스턴스에 비해 내 복제본의 지연 시간이 얼마나 됩니까?

Amazon Aurora 복제본은 같은 AWS 리전의 기본 인스턴스와 동일한 데이터 볼륨을 공유하므로 사실상 복제 지연이 발생하지 않습니다. 일반적인 지연 시간은 수십 밀리초 이내입니다. MySQL 읽기 전용 복제본의 경우 변경/적용 비율과 네트워크 통신의 지연에 따라 복제 지연 시간이 무제한 증가할 수 있습니다. 하지만 일반적인 조건에서는 대개 1분 이내의 복제 지연이 발생합니다.

논리적 복제를 사용한 교차 리전 복제본은 변경률/적용률과 선택한 특정 리전 간의 네트워크 통신 지연의 영향을 받습니다. Amazon Aurora Global Database를 사용한 교차 리전 복제본은 일반적으로 지연 시간이 1초 미만입니다.

Q: 내 Aurora MySQL 호환 버전 데이터베이스와 외부 MySQL 데이터베이스 간에 복제를 설정할 수 있나요?

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

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

Q: Amazon Aurora Global Database란 무엇입니까?

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

이 기능은 Aurora MySQL 호환 버전과 Aurora PostgreSQL 호환 버전 모두에서 사용할 수 있습니다.

Q: Amazon Aurora Global Database를 생성하려면 어떻게 해야 하나요?

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

Q: Amazon Aurora Global Database에는 몇 개의 보조 리전을 포함할 수 있나요?

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

Q: Amazon Aurora Global Database를 사용하는 경우에도 프라이머리 데이터베이스에서 논리적 복제(binlog)를 사용할 수 있나요?

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

Q: Aurora는 Amazon Aurora Global Database의 보조 리전으로 자동으로 장애 조치를 수행하나요?

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

Q: Amazon Aurora 멀티 마스터란 무엇인가요?

새로운 Aurora MySQL 호환 버전 기능인 Amazon Aurora 멀티 마스터에는 여러 가용 영역으로 쓰기 성능을 확장할 수 있는 기능이 추가되어, 애플리케이션이 읽기/쓰기 워크로드를 데이터베이스 클러스터의 여러 인스턴스로 보내고 더 높은 가용성으로 작동할 수 있게 해줍니다.

Q: Amazon Aurora 멀티 마스터를 시작하려면 어떻게 해야 하나요?

Amazon Aurora 멀티 마스터가 정식 출시되었습니다. 자세한 내용은 Amazon Aurora 설명서를 참조하세요. Amazon RDS 콘솔에서 클릭 몇 번으로 Aurora 멀티 마스터 클러스터를 생성하거나 최신 AWS SDK 또는 CLI를 다운로드할 수 있습니다.

보안

Q: Amazon Virtual Private Cloud(VPC)에서 Amazon Aurora를 사용할 수 있습니까?

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

Q: Amazon Aurora는 전송 데이터와 저장 데이터를 암호화합니까?

예. Amazon Aurora는 SSL(AES-256)을 사용하여 데이터베이스 인스턴스와 애플리케이션 간 연결을 보호합니다. Amazon Aurora를 사용하면 사용자가 AWS Key Management Service(AWS KMS)를 통해 관리하는 키를 사용해 데이터베이스를 암호화할 수 있습니다. Amazon Aurora 암호화를 실행 중인 데이터베이스 인스턴스에서는 같은 클러스터에 있는 자동 백업, 스냅샷 및 복제본과 마찬가지로 기본 스토리지에 저장된 데이터가 암호화됩니다. 암호화와 복호화는 원활하게 처리됩니다. Amazon Aurora와 AWS KMS 사용에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

Q: 암호화되지 않은 기존 데이터베이스를 암호화할 수 있나요?

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

Q: 내 Amazon Aurora 데이터베이스에는 어떻게 액세스하나요?

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

Q: HIPAA 규정을 준수해야 하는 애플리케이션에 Amazon Aurora를 사용할 수 있나요?

예. Aurora의 MySQL 호환 및 PostgreSQL 호환 버전은 미국 건강 보험 양도 및 책임에 관한 법(HIPAA) 적격 서비스입니다. 따라서 AWS와 체결한 비즈니스 제휴 계약(BAA)에 따라 HIPAA 규정 준수 애플리케이션을 구축하고 개인 건강 정보(PHI)를 비롯한 의료 서비스 관련 정보를 저장하는 데 이를 사용할 수 있습니다. 이미 BAA를 체결한 경우, 다른 작업 없이 BAA에 포함된 계정에서 이러한 서비스 사용을 시작할 수 있습니다. AWS에 호환 애플리케이션을 구축하는 방법에 대한 자세한 정보는 클라우드에서 의료 서비스 제공자 및 보험사를 참조하십시오.

Q: 공개적으로 알려진 Amazon Aurora 릴리스의 사이버 보안 취약성에 대한 CVE(Common Vulnerabilities and Exposures) 항목의 목록은 어디에서 확인할 수 있습니까?

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

서버리스

Q: Amazon Aurora Serverless란 무엇인가요?

Amazon Aurora Serverless는 애플리케이션 요구를 기반으로 하여 데이터베이스 용량을 자동으로 조정하는 온디맨드 자동 크기 조정 구성입니다. Aurora Serverless를 사용하면 활성 상태일 때 데이터베이스가 소비하는 데이터베이스 용량, 스토리지 및 I/O에 대해서만 요금을 지불합니다. 데이터베이스 용량은 애플리케이션 워크로드 요구 사항에 맞춰 자동으로 확장되거나 축소되며 비활성 상태일 때는 종료되므로 비용 및 관리 시간을 줄일 수 있습니다. Aurora Serverless는 초 단위로 청구되는 ACU(Aurora Capacity Unit)로 데이터베이스 용량을 측정합니다. 하나의 ACU에는 해당 CPU 및 네트워킹과 함께 약 2GB의 메모리가 포함됩니다. 이는 Aurora 프로비저닝 인스턴스에서 사용되는 양과 유사합니다.

현재 평가판으로 제공되는 Aurora Serverless v2는 초당 수십만 건의 트랜잭션을 지원하는 규모로 데이터베이스를 즉시 확장하고 다중 AZ 배포, 읽기 전용 복제본 및 글로벌 데이터베이스와 같은 Aurora의 모든 기능을 지원합니다. 가장 까다로운 비즈니스 크리티컬 애플리케이션을 포함하여 모든 방식의 관계형 데이터베이스 워크로드에 적합합니다.

Amazon Aurora Serverless v1은 사용 빈도가 낮거나 간헐적이거나 예측할 수 없는 워크로드에 대한 간단하고 비용 효율적인 옵션입니다.

Q: Aurora Serverless를 지원하는 Amazon Aurora 버전은 무엇인가요?

Aurora Serverless v1은 현재 MySQL 5.6과 호환되는 Aurora 및 PostgreSQL 10.7 이상과 호환되는 Aurora에서 사용할 수 있습니다. Aurora Serverless v2는 현재 Aurora MySQL 호환 버전용 평가판으로만 사용할 수 있습니다.

Q: 기존 Aurora DB 클러스터를 Aurora Serverless로 마이그레이션할 수 있나요?

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

Q: Aurora Serverless DB 클러스터에 연결하려면 어떻게 해야 하나요?

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

Q: Aurora Serverless 클러스터의 용량을 명시적으로 설정할 수 있습니까?

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

Q: 내 Aurora Serverless DB 클러스터 크기가 자동으로 조정되지 않는 이유는 무엇인가요?

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

Q: Aurora Serverless에 대한 요금은 어떻게 청구됩니까?

Aurora Serverless에서 데이터베이스 용량은 ACU(Aurora Capacity Unit)로 측정됩니다. 데이터베이스가 활성화될 때마다 최소 5분 사용량으로 ACU를 사용하는 초당 정액 요금을 지불합니다. 스토리지 및 I/O 요금은 프로비저닝 구성과 Serverless 구성이 동일합니다. Aurora Serverless 요금 예제를 참조하십시오.

병렬 쿼리

Q: Amazon Aurora 병렬 쿼리란 무엇입니까?

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

Q: 대상 사용 사례는 어떻게 됩니까?

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

Q: 병렬 쿼리가 제공하는 이점은 무엇인가요?

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

Q: 병렬 쿼리에서는 어떤 쿼리가 개선되나요?

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

Q: 어느 정도의 성능 개선을 예상할 수 있습니까?

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

Q: 성능이 저하될 가능성이 있습니까?

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

Q: 병렬 쿼리를 활용하려면 내 쿼리를 어떻게 변경해야 합니까?

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

Q: 이 기능을 활성화 또는 비활성화하려면 어떻게 해야 합니까?

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

Q: 병렬 쿼리 사용과 관련된 추가 요금이 있나요?

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

Q: 병렬 쿼리가 I/O를 줄여주므로 이 기능을 활성화하면 Aurora I/O 요금이 절감되나요?

아니요. 병렬 쿼리를 사용하면 쿼리에 대한 I/O 비용이 줄어들기 때문에 I/O는 스토리지 계층에서 측정되며 병렬 쿼리가 활성화된 경우 그 비용은 동일하거나 더 커집니다. 쿼리 성능이 향상되는 것이 이점입니다. 병렬 쿼리로 I/O 비용이 증가할 가능성이 있는 이유는 두 가지입니다. 먼저, 테이블의 데이터 일부가 버퍼 풀에 있더라도, 병렬 쿼리는 스토리지 계층의 모든 데이터를 스캔해야 하므로 I/O가 발생합니다. 둘째, 버퍼 풀에서 경합을 피하는 부작용은 병렬 쿼리를 실행해도 버퍼 풀이 워밍업되지 않는다는 것입니다. 결과적으로 동일한 병렬 쿼리를 연속적으로 실행하면 전체 I/O 비용이 발생합니다.

Q: 병렬 쿼리를 지원하는 Amazon Aurora 버전은 무엇인가요?

병렬 쿼리는 v1.18.0부터 시작하는 Amazon Aurora의 MySQL 5.6 호환 버전에서 사용할 수 있습니다. 병렬 쿼리를 MySQL 5.7과 호환되는 Aurora 및 Aurora PostgreSQL 호환 버전으로 확장할 계획입니다.

Q: 모든 인스턴스 유형에서 병렬 쿼리를 사용할 수 있나요?

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

Q: 병렬 쿼리는 다른 모든 Aurora 기능과 호환됩니까?

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

Q: 병렬 쿼리가 쿼리 속도를 높이며 성능 손실은 아주 드물게 발생한다면 모든 데이터베이스에 대해 항상 활성화해야 하나요?

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

Q: Aurora 병렬 쿼리가 내 데이터 웨어하우스를 대체할 수 있나요?

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

Amazon DevOps Guru for RDS

Q: Amazon DevOps Guru for RDS란 무엇인가요?

Amazon DevOps Guru for RDS는 데이터베이스 성능 및 운영 문제를 자동으로 감지하고 진단하도록 설계된 Amazon RDS를 위한 새로운 기계 학습 기반 기능으로, 며칠이 아닌 몇 분 만에 문제를 해결할 수 있습니다. 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 엔지니어에게 즉시 알리고 진단 정보, 문제 범위에 대한 세부 정보, 지능형 수정 권장 사항을 제공하여 고객이 데이터베이스 관련 성능 병목 현상 및 운영 문제를 신속하게 해결할 수 있도록 합니다.

Q: DevOps Guru for RDS를 사용해야 하는 이유는 무엇인가요?

Amazon DevOps Guru for RDS는 관계형 데이터베이스 워크로드에서 찾기 힘든 성능 병목 현상을 감지하고 해결하는 데 필요한 수작업을 제거하고 시간을 몇 시간, 며칠에서 몇 분으로 단축하도록 설계되었습니다. 모든 Amazon Aurora 데이터베이스에 대해 DevOps Guru for RDS를 사용하면 워크로드에 대한 성능 문제를 자동으로 감지하고, 각 문제에 대해 알림을 보내고, 결과를 설명하고, 해결할 조치를 권장합니다. DevOps Guru for RDS는 비전문가가 데이터베이스 관리에 더 쉽게 액세스할 수 있도록 도와주며 데이터베이스 전문가가 더 많은 데이터베이스를 관리할 수 있도록 지원합니다.

Q: Amazon DevOps Guru for RDS는 어떻게 작동하나요?

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

Q: Amazon DevOps Guru for RDS를 시작하려면 어떻게 해야 하나요?

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

Q: Amazon DevOps Guru for RDS는 어떤 유형의 문제를 탐지할 수 있나요?

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

Q: DevOps Guru for RDS는 Amazon RDS 성능 개선 도우미와 어떻게 다른가요?

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

Amazon Aurora 요금에 대해 자세히 알아보기

요금 페이지로 이동하기
구축할 준비가 되셨습니까?
Amazon Aurora 시작하기
추가 질문이 있으십니까?
AWS에 문의