Q: Amazon Aurora란 무엇입니까?

Amazon Aurora는 고성능 상용 데이터베이스의 속도와 안정성에 오픈 소스 데이터베이스의 간편성과 비용 효율성이 결합된 관계형 데이터베이스 엔진입니다. Amazon Aurora MySQL은 MySQL보다 최대 5배 뛰어난 성능을 제공하며 이때 대부분의 MySQL 애플리케이션은 전혀 변경할 필요가 없습니다. 이와 마찬가지로 Amazon Aurora PostgreSQL은 PostgreSQL보다 3배 뛰어난 성능을 제공합니다. Amazon RDS에서 Amazon Aurora 데이터베이스를 관리하며 프로비저닝, 패치, 백업, 복원, 장애 감지, 복구 등 시간이 많이 소요되는 작업을 처리합니다. 사용하는 각 Amazon Aurora 데이터베이스 인스턴스에 대해 소정의 월별 요금을 지불하면 됩니다. 선수금이나 장기 약정이 필요하지 않습니다.

Q: 'MySQL 호환'이란 어떤 의미입니까?

MySQL 데이터베이스에서 현재 사용하는 대부분의 코드와 애플리케이션, 드라이버, 도구를 거의 또는 전혀 변경하지 않고도 Aurora에서 사용할 수 있음을 의미합니다. Amazon Aurora 데이터베이스 엔진은 InnoDB 스토리지 엔진을 사용하여 MySQL 5.6과 호환되도록 설계되었습니다. MyISAM 스토리지 엔진과 같은 일부 MySQL 기능은 Amazon Aurora에서 제공되지 않습니다.

Q: 'PostgreSQL 호환'이란 어떤 의미입니까?

PostgreSQL 데이터베이스에서 현재 사용하는 대부분의 코드와 애플리케이션, 드라이버, 도구를 거의 또는 전혀 변경하지 않고도 Aurora에서 사용할 수 있음을 의미합니다. Amazon Aurora 데이터베이스 엔진은 PostgreSQL 9.6과 호환되도록 설계되었으며, PostgreSQL 9.6용 RDS에서 지원하는 것과 같은 PostgreSQL 확장 세트를 지원하므로 두 엔진 간에 애플리케이션을 손쉽게 이동할 수 있습니다.  

Q: Amazon Aurora를 사용하려면 어떻게 해야 합니까?

Amazon Aurora를 사용하려면 AWS 콘솔에 로그인하고, Database 카테고리 아래에서 RDS를 선택한 후, Amazon Aurora를 데이터베이스 엔진으로 선택하십시오.

Q: Amazon Aurora 의 사용료는 얼마입니까?

최신 가격 정보는 Amazon 요금 페이지를 참조하십시오.

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

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

Q: 어떤 AWS 리전에서 Amazon Aurora를 사용할 수 있습니까?

리전과 요금에 대한 최신 정보는 AWS 요금 페이지를 참조하십시오.

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

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

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

여러 가지 옵션이 있습니다. 표준 pg_dump 유틸리티를 사용하여 PostgreSQL에서 데이터를 내보내고 pg_restore 유틸리티를 사용하여 Amazon Aurora로 데이터를 가져올 수 있으며 그 반대도 마찬가지입니다. 또한, AWS Management Console에서 Amazon RDS의 DB 스냅샷 마이그레이션 기능을 이용하여 RDS PostgreSQL 9.6 DB 스냅샷을 Amazon Aurora로 마이그레이션할 수 있습니다. 대부분 고객은 1시간 이내에 마이그레이션을 완료하지만, 이 기간은 형식과 데이터 세트의 크기에 따라 달라집니다.

Q: Amazon Aurora는 AWS 프리 티어에 포함됩니까?

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

Q: Amazon Aurora의 IO란 무엇이며 어떻게 계산됩니까?

IO는 Aurora 데이터베이스 엔진에서 SSD 기반 가상화 스토리지 계층에 대해 수행하는 입력/출력 작업입니다. 모든 데이터베이스 페이지 읽기 작업은 1건의 IO로 계산됩니다. Aurora 데이터베이스 엔진은 버퍼 캐시에 없는 데이터베이스 페이지를 가져오기 위해 스토리지 계층에 대한 읽기를 실행합니다. 각 데이터베이스 페이지의 크기는 Aurora MySQL은 16KB이고 Aurora PostgreSQL은 8KB입니다.

Aurora는 비용을 절감하고 읽기/쓰기 트래픽을 위해 사용할 수 있는 리소스를 확보하기 위해 불필요한 IO를 제거하도록 설계되었습니다. 쓰기 IO는 안정적인 쓰기를 위해 트랜잭션 로그 기록을 스토리지 계층으로 푸시할 때만 사용됩니다. 쓰기 IO는 4KB 유닛별로 계산됩니다. 예를 들어, 1,024바이트 크기의 트랜잭션 로그 기록은 1건의 IO 작업으로 계산됩니다. 하지만 트랜잭션 로그 크기가 4KB 미만인 동시 쓰기 작업은 I/O 사용을 최적화하도록 Aurora 데이터베이스 엔진에서 일괄 처리할 수 있습니다. 기존 데이터베이스 엔진과는 달리 Amazon Aurora는 변경된 데이터베이스 페이지를 스토리지 계층으로 푸시하지 않으므로 IO 사용을 좀 더 줄일 수 있습니다.

Aurora 인스턴스가 얼마나 많은 인스턴스를 사용하는지는 AWS 콘솔에서 확인할 수 있습니다. IO 사용량을 확인하려면 콘솔의 RDS 섹션에서 인스턴스 목록을 찾아, Aurora 인스턴스를 선택한 후, 모니터링 섹션에서 “Billed read operations” 및 “Billed write operations” 측정치를 참조하시면 됩니다.

Q: Amazon Aurora PostgreSQL을 사용하려면 클라이언트 드라이버를 교체해야 합니까?

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

Q: Amazon Aurora Serverless란 무엇입니까?

re:Invent 2017에서는 MySQL 호환 버전의 새로운 구성인 Amazon Aurora Serverless에 대한 미리 보기를 발표했습니다. 이 버전은 애플리케이션 요구 사항에 맞게 데이터베이스 용량을 자동으로 조정하여 시간, 작업 및 비용을 절약할 수 있게 해 줍니다.

Q: Amazon Aurora Serverless를 시작하려면 어떻게 해야 합니까?

Amazon Aurora Serverless는 Amazon Aurora의 MySQL 호환 버전에 대한 미리 보기로 제공됩니다. 가입해서 참여를 요청할 수 있습니다. 향후 정식 출시에 대해 발표할 예정입니다.

Q: 'MySQL 성능의 다섯 배'란 어떤 의미입니까?

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

Q: 'MySQL 성능의 3배'란 어떤 의미입니까?

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

Q: Amazon Aurora MySQL에 맞춰 내 데이터베이스 워크로드를 최적화하려면 어떻게 해야 합니까?

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

Q: Amazon Aurora PostgreSQL에 맞춰 내 데이터베이스 워크로드를 최적화하려면 어떻게 해야 합니까?

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

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

최소 스토리지는 10GB입니다. 데이터베이스 사용에 따라 Amazon Aurora 스토리지는 데이터베이스 성능에 영향을 미치지 않고 최대 64TB까지 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개의 가용 영역에 6개의 데이터 사본을 유지 관리하고 데이터가 손실되지 않은 정상 가용 영역의 데이터베이스를 자동 복구합니다. 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 청크가 세 개의 가용 영역에 6가지 방법으로 복제됩니다. Amazon Aurora는 데이터베이스 쓰기 가용성에 영향을 주지 않고 최대 2개의 데이터 사본 손실을 처리하고 읽기 가용성에 영향을 주지 않고 최대 3개의 사본 손실을 투명하게 처리하도록 설계되었습니다. 또한, Amazon Aurora 스토리지에는 자가 치유 기능이 있습니다. 데이터 블록과 디스크에 오류가 있는지 계속 스캔하고 오류가 있는 경우 자동으로 복구됩니다.

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

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

Q: Aurora는 어떤 종류의 복제본을 지원합니까?

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

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

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

Q: Amazon Aurora는 교차 리전 복제를 지원합니까?

예. Aurora MySQL의 경우 RDS 콘솔에서 교차 리전 Aurora 복제본을 설정할 수 있습니다. 교차 리전 복제본은 단일 스레드 MySQL binlog 복제를 기반으로 하며, 복제 지연 시간은 변경/적용률과 선택한 특정 리전 간의 네트워크 통신 지연에 따라 달라집니다. 현재 Aurora PostgreSQL에서는 교차 리전 복제본을 지원하지 않습니다.

Q: 교차 리전 복제본 클러스터에 Aurora 읽기 전용 복제본을 생성할 수 있습니까?
예. 교차 리전 복제본과 동일한 기본 스토리지를 공유하는 클러스터에 Aurora 읽기 전용 복제본을 추가할 수 있습니다. 교차 리전 복제본은 클러스터에서 기본 복제본의 역할을 하며, 클러스터의 Aurora 읽기 전용 복제본은 기본 복제본보다 일반적으로 수십 밀리초 지연됩니다.

Q: 내 애플리케이션을 현재 기본 복제본에서 교차 리전 복제본으로 장애 조치할 수 있습니까?
예. RDS 콘솔에서 교차 리전 복제본을 새로운 기본 복제본으로 승격할 수 있습니다. 승격 프로세스는 워크로드에 따라 다르지만 보통 몇 분 정도 걸립니다. 승격 프로세스를 시작하면 교차 리전 복제가 중단됩니다.

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

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

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

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

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

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

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

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

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

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

  • Amazon Aurora Replica가 동일한 가용 영역 또는 다른 가용 영역에 있는 경우 장애 조치가 진행될 때 Amazon Aurora에서 DB 인스턴스의 CNAME(정식 이름 레코드)이 정상적인 복제본을 가리키도록 변경하며, 해당 복제본이 승격되어 새로운 기본 복제본이 됩니다. 일반적으로 장애 조치는 처음부터 끝까지 30초 이내에 완료됩니다.
  • Amazon Aurora Replica(예: 단일 인스턴스)가 없는 경우 Aurora는 먼저 원래 인스턴스와 동일한 가용 영역에 새 DB 인스턴스를 만들려고 시도합니다. 새 DB 인스턴스를 생성할 수 없는 경우, Aurora는 다른 가용 영역에 새로운 DB 인스턴스를 만들려고 시도합니다. 장애 조치 전 과정은 일반적으로 15분 이내에 완료됩니다.

데이터베이스 연결이 끊어지는 경우 애플리케이션에서 연결을 다시 시도해야 합니다.

Q: 기본 데이터베이스가 있고 Amazon Aurora Replica에서 읽기 트래픽을 활발하게 처리하는 동안 장애 조치가 발생하면 어떻게 됩니까?

Amazon RDS는 기본 인스턴스의 문제를 자동 감지하고 Amazon Aurora Replica로 읽기/쓰기 트래픽을 라우팅하기 시작합니다. 평균적으로 이러한 장애 조치는 30초 이내에 완료됩니다. 또한, Amazon Aurora Replicas에서 제공하던 읽기 트래픽이 잠깐 중단됩니다.

Q: 기본 인스턴스에서 내 복제본까지 지연이 얼마나 발생합니까?

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

Q: Amazon Aurora Multi-Master란 무엇입니까?

re:Invent 2017에서 Aurora MySQL 호환 버전의 새로운 기능인 Amazon Aurora Multi-Master에 대한 미리 보기를 발표했습니다. 여기에는 여러 가용 영역에서 쓰기 성능을 확장할 수 있는 기능이 추가되어 애플리케이션이 읽기/쓰기 워크로드를 데이터베이스 클러스터의 여러 인스턴스로 보내고 더 높은 가용성으로 작동할 수 있게 해 줍니다.

Q: Amazon Aurora Multi-Master를 시작하려면 어떻게 해야 합니까?

Amazon Aurora Multi-Master는 현재 Amazon Aurora의 MySQL 호환 버전에 대한 미리 보기로 제공됩니다. 가입해서 참여를 요청할 수 있습니다. 향후 정식 출시에 대해 발표할 예정입니다.

Q: Amazon Virtual Private Cloud(Amazon 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(KMS)를 통해 관리하는 키를 사용해 데이터베이스를 암호화할 수 있습니다. Amazon Aurora 암호화를 실행 중인 데이터베이스 인스턴스에서는 같은 클러스터에 있는 자동 백업, 스냅샷 및 복제본과 마찬가지로 기본 스토리지에 저장된 데이터가 암호화됩니다. 암호화와 복호화는 원활하게 처리됩니다. Amazon Aurora와 KMS 사용에 관한 자세한 내용은 Amazon RDS 사용 설명서를 참조하십시오.

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

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

Q: 내 Amazon Aurora 데이터베이스에는 어떻게 액세스합니까?

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

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

A: 예. Aurora의 MySQL 호환 및 PostgreSQL 호환 버전은 HIPAA 적격 서비스입니다. 따라서 AWS와 체결한 Business Associate Agreement(BAA)에 따라 HIPAA 규정 준수 애플리케이션을 구축하고 개인 건강 정보(PHI)를 비롯한 의료 서비스 관련 정보를 저장하는 데 이를 사용할 수 있습니다. 이미 BAA를 체결한 경우, 다른 작업 없이 BAA에 포함된 계정에서 이러한 서비스 사용을 시작할 수 있습니다. AWS와 BAA를 아직 체결하지 않았거나, AWS의 HIPPA 규정 준수 애플리케이션에 대한 질문이 있는 경우 AWS로 문의해 주십시오.

Q: Performance Insights는 어떤 인스턴스 크기에서 사용할 수 있습니까?

마이크로 이외의 모든 인스턴스 크기에서 사용할 수 있습니다. RDS에서 새로운 인스턴스 크기를 출시함에 따라 Performance Insights도 충분한 성능을 갖춘 해당 크기에서도 사용할 수 있게 될 것입니다.

Q: PostgreSQL용 RDS, Aurora MySQL, MySQL용 RDS, RDS for Oracle, RDS for SQL Server 및 MariaDB용 RDS에서는 언제부터 Performance Insights를 사용할 수 있습니까?

먼저 Aurora PostgreSQL에서 Performance Insights를 사용할 수 있도록 지원하고 곧 이어 Aurora MySQL에서도 지원할 예정입니다. 시간이 지나면서 사용 가능한 엔진이 계속해서 추가될 예정입니다.

Q: Performance Insights에서는 성능 문제의 원인을 어떻게 보여줍니까?

성능 문제는 RDS 콘솔의 Performance Insights 섹션에 있는 데이터베이스 로드 그래프에서 스파이크로 나타납니다. 이 그래프를 한 번 보면 데이터베이스에서 애플리케이션이 시간 및 리소스를 사용하고 있는 리소스 유형을 빠르게 파악할 수 있습니다. 콘솔에서는 보관 기간 내 원하는 기간을 확대해서 볼 수 있습니다. 로드가 많은 기간을 선택하면 로드에 대한 전체 기여도에 따라 정렬된 SQL 문 목록을 표시할 수 있습니다.

Q: Performance Insights는 내 RDS DB 인스턴스의 로드를 어떻게 파악합니까?

Performance Insights는 DB 인스턴스에서 연결된 모든 세션의 상태를 1초 간격으로 샘플링합니다. 세션이 데이터베이스 관련 작업을 처리하고 있는 경우, Performance Insights에서는 샘플 시간, 작업 유형(I/O, CPU, 잠금 등), 현재 SQL 문 및 기타 여러 가지 세션 속성을 기록합니다. 이렇게 일정 기간 동안 샘플링한 데이터를 사용하여 해당 세션이 데이터베이스 인스턴스의 로드에 미치는 영향을 파악합니다.

Q: RDS 인스턴스 내에서 성능 데이터를 쿼리할 수 있습니까?

아니요. Performance Insights 샘플링 프로세스는 데이터베이스 내의 어떠한 테이블도 채우지 않고 SQL을 통해 데이터베이스 내에서 검색되도록 데이터를 제공하지도 않습니다.

Q: 인스턴스에서 무슨 일이 일어나고 있는지 실시간으로 파악할 수 있습니까?

예. 기본적으로 Performance Insights에서는 1시간의 슬라이딩 윈도우로 성능 데이터를 표시합니다. 이 기능은 최신 성능 정보를 거의 실시간(몇 초 차이)으로 제공하기 위해 개발되었습니다.

Q: Performance Insights의 비용은 어떻게 됩니까?

Performance Insights에는 24시간 데이터 보존과 콘솔 액세스가 포함됩니다. 평가판 기간에는 Performance Insights에서 24시간의 성능 데이터 보관 옵션이 포함된 프리 티어를 제공합니다. 더 긴 데이터 보관 기간에 대한 요금은 곧 공지될 예정입니다.

Q: Performance Insights에 저장된 성능 데이터는 얼마 전 데이터까지 볼 수 있습니까?

24시간의 성능 기록을 볼 수 있습니다. 더 긴 보존 기간에 대한 옵션은 나중에 공지될 예정입니다.

Q: Performance Insights가 기본적으로 활성화되어 있더라도 새로운 인스턴스에서 이를 끌 수 있습니까?

예. 인스턴스 생성 마법사를 사용하는 경우 AWS 콘솔에는 Performance Insights 옵션이 기본적으로 선택되어 있습니다. Performance Insights가 활성화되지 않도록 마법사에서 옵션 선택을 취소하거나, 인스턴스를 변경하여 활성화된 인스턴스의 Performance Insights를 비활성화할 수 있습니다.

Q: 암호화된 스토리지를 사용하는 RDS 데이터베이스 인스턴스에서 Performance Insights가 작동합니까?

예. Performance Insights는 데이터베이스에 저장된 데이터는 읽지 않습니다.

Q: DB 로드란 무엇이며 Performance Insights에서 성능 문제를 감지하는 기본 수단으로 DB 로드를 사용하는 이유는 무엇입니까?

DB 로드는 고객의 애플리케이션이 데이터베이스에서 시간을 얼마나 사용하는지와 해당 시간을 어떻게 사용하는지 보여주는 시계열입니다. DB 로드는 AAS(평균 활성 세션) 단위로 측정됩니다. 여기에서 활성 세션이란 데이터베이스 엔진에 작업을 제출하고 응답 대기 중인 연결(세션)을 말합니다. 예를 들어, 데이터베이스 인스턴스에 SQL 문을 제출하면 인스턴스가 쿼리를 처리하는 동안 해당 세션은 '활성' 상태로 간주됩니다. AWS에서는 주어진 시간 동안 인스턴스에서 활성 상태인 세션 수를 계산하고 일정 기간 동안 평균을 냄으로써 이 인스턴스가 얼마나 바쁜지 인스턴스가 응답하길 기다리는 데 사용되는 시간 세션이 얼마나 되는지를 보여주는 지표를 제공할 수 있습니다. 이것이 DB 로드입니다. Performance Insights는 경량 샘플링 메커니즘을 사용하여 활성 세션의 수를 계산하고 약 1초마다 각 세션의 속성을 기록합니다. 샘플링된 데이터는 암호화되고 다양한 세부 수준으로 집계되어 DB 로드 차트에 제공됩니다. 콘솔 사용자는 원하는 기간을 선택하여 볼 수 있습니다.

Q: Performance Insights를 활성화하기 위해서는 데이터베이스에 특별한 작업을 수행해야 합니까?

아니요. 그러나 일부 데이터베이스 엔진에서는 추가 성능 추적 기능을 활성화하면 Performance Insights가 더욱 잘 작동합니다. 예를 들어 RDS PostgreSQL 또는 Aurora PostgreSQL에 pg_stat_statement 확장 기능이 활성화되면, Performance Insights에서 PostgreSQL 기본 SQL 식별자를 사용하여 해당 문을 식별하고 더 긴 문의 전체 텍스트를 수집할 수 있습니다. MySQL에서는 성능 스키마를 활성화하면 Performance Insights가 데이터베이스에 영향을 미치는 대기 이벤트에 대해 훨씬 더 다양하고 자세한 데이터를 수집할 수 있게 됩니다.

Q: Performance Insights를 활성화하면 데이터베이스 성능이 저하됩니까?

Performance Insights 에이전트는 데이터베이스 워크로드에 방해가 되지 않도록 설계되었습니다. Performance Insights는 인스턴스의 다른 프로세스보다 낮은 우선순위로 실행되어 호스트 및 데이터베이스의 상태를 모니터링합니다. Performance Insights가 높은 로드 또는 고갈된 리소스를 감지하면, 평상시 데이터 수집 빈도를 유지하지 않고 여전히 데이터를 수집하긴 하지만 안전할 때만 수집하는 방식으로 변경합니다. 데이터베이스 옵션(예: RDS PostgreSQL 및 Aurora PostgreSQL의 pg_stat_statement, MySQL의 성능 스키마 등)은 데이터베이스 리소스 일부를 사용할 수 있으므로 잠재적으로 성능에 영향을 미칠 수 있습니다. 이러한 옵션 활성화가 특성 시스템에 영향을 미치는지 아닌지는 애플리케이션 워크로드에 달려 있습니다. 따라서 프로덕션 시스템에서 데이터베이스 옵션을 활성화하기 전에 워크로드에 대해 이러한 옵션을 테스트해보는 것이 좋습니다.

Q: Enhanced Monitoring을 계속해서 사용해야 합니까 아니면 Performance Insights만 사용하면 됩니까?

Enhanced Monitoring을 사용하여 O/S 지표를 모니터링하는 경우 Enhanced Monitoring을 통해 해당 데이터를 계속 확보해야 합니다. 몇 달 후면 Performance Insights 콘솔 및 API를 통해 해당 데이터 및 포괄적인 데이터베이스 지표 모음을 사용할 수 있습니다. 그러면 Performance Insights에서 모든 성능 데이터를 확보할 수 있습니다. Enhanced Monitoring은 이 기능을 선호하는 고객을 위해 계속 제공되겠지만 AWS에서는 고객이 Performance Insights에서 데이터베이스 모니터링을 표준화하도록 권장합니다.

Q: Performance Insights에 저장된 데이터는 암호화됩니까?

예. Performance Insights는 사용자의 자체 KMS 키를 사용하여 잠재적으로 민감한 모든 데이터를 암호화합니다. 데이터는 암호화된 상태로 전송 및 저장됩니다. AWS 직원은 잠재적으로 민감한 성능 데이터에 액세스하거나 이러한 데이터를 볼 수 없습니다. RDS에 대한 모든 액세스 권한을 가진 AWS 계정의 사용자만 Performance Insights를 볼 수 있습니다. KMS 키에 대한 RDS 승인을 취소하면 AWS 직원이 언제든지 고객의 성능 데이터를 처리하고 표시할 수 있습니다.

Q: Performance Insights를 끄면 AWS에서 관련 데이터를 보관합니까 아니면 삭제합니까?

프리 티어의 성능 데이터 보관은 1일로 제한됩니다. 인스턴스에서 Performance Insights를 비활성화하면 해당 인스턴스에 대한 성능 데이터가 삭제됩니다.

Q: RDS 데이터베이스 인스턴스를 중지하면 Performance Insights 데이터 보관은 어떻게 됩니까?

Performance Insights가 활성화된 RDS 인스턴스를 중지하더라도 해당 인스턴스에 대한 기록 데이터의 보관 또는 가시성에는 아무런 영향을 미치지 않습니다. 하지만 인스턴스가 중지된 기간에는 아무런 데이터도 포함되지 않습니다.

Q: 기존 성능 도구를 사용해 Performance Insights와 인터페이스하려면 어떻게 해야 합니까?

Performance Insights에서는 앞으로 공개적으로 사용 가능한 API를 제공할 예정입니다. 고객 및 타사는 이 API를 통해 Performance Insight의 귀중한 데이터를 활용할 수 있습니다.

Q: 타사 성능 도구를 Performance Insights에 통합할 방법이 있습니까?

Performance Insights에서는 앞으로 공개적으로 사용 가능한 API를 제공할 예정입니다. 고객 및 타사는 이 API를 통해 Performance Insight의 귀중한 데이터를 활용할 수 있습니다.

Q: Performance Insights는 RDS가 제공되는 모든 AWS 리전에서 사용할 수 있습니까?

예. 점진적으로 RDS가 지원되는 모든 리전에서 이 기능을 제공할 예정입니다.

Q: 기존 인스턴스에서 Performance Insights를 켤 수 있습니까 아니면 새 인스턴스에서만 켤 수 있습니까?

예. Performance Insights를 활성화하도록 인스턴스를 수정하면 기존 인스턴스에서 Performance Insights를 활성화할 수 있습니다. 인스턴스를 생성할 때 Performance Insights를 활성화하도록 지정하면 새 인스턴스에서 이를 활성화할 수 있습니다.

Q: Performance Insights는 데이터베이스 인스턴스의 스토리지를 사용합니까?

아니요. Performance Insights는 RDS 인스턴스의 스토리지 공간을 사용하지 않습니다.

Q: 다른 데이터베이스 엔진에서 실행하는 경우 Performance Insights가 어떻게 달라집니까?

Performance Insights는 RDS의 모든 데이터베이스 엔진에서 튜닝 시 공통 접근 방식 및 디자인을 제공하도록 설계되었습니다. 엔진 유형별로 대기 이벤트 및 SQL 식별자와 같은 특정 속성이 다르기 때문에 다른 데이터베이스 엔진에서 사용하는 경우 당연히 이러한 속성이 Performance Insights에서 달라집니다. Performance Insights의 핵심 원리 중 하나는 데이터베이스 엔진의 기본 개념, 식별자 및 속성이 그대로 유지되어야 한다는 것입니다. Performance Insights는 일반적으로 다른 엔진별 속성의 대기 이벤트를 재해석하거나 이름을 바꾸지는 않지만, 데이터베이스 엔진에서 보고하는 대로 이를 제시합니다.

Q: Performance Insights는 다중 AZ 인스턴스 및 읽기 전용 복제본 인스턴스에서도 작동합니까?

예. Aurora 읽기 전용 복제본은 독립적인 인스턴스이므로, 이러한 인스턴스에서 Performance Insights를 활성화하거나 비활성화할 수 있습니다.

Q: Performance Insights에서 내 데이터를 내보낼 수 있습니까?

앞으로 Performance Insights에 데이터 내보내기 기능이 추가될 예정입니다.

Q: 성능 분석을 위해 나중에 Performance Insights로 데이터를 다시 가져올 수 있습니까?

아니요. Performance Insights는 인스턴스에서 직접 수집한 데이터만 표시합니다. 몇 달 후면 Performance Insights를 사용해 확보한 데이터를 API를 통해 제공하고, Amazon Athena, Amazon Redshift, Amazon Redshift Spectrum 및 Amazon Quicksight와 같은 분석 지향적 AWS 서비스를 사용해 분석을 수행할 수 있게 될 것입니다.