Amazon Aurora에서 개념 증명 수행 - Amazon Aurora
Aurora 개념 증명 개요1. 목표 식별2. 워크로드 특성에 대한 이해3. 콘솔 또는 CLI를 이용한 실습4. Aurora 클러스터 생성5. 스키마 설정6. 데이터 가져오기7. SQL 코드 포팅8. 구성 설정 지정9. Aurora에 연결10. 워크로드 실행11. 성능 측정12. Aurora 고가용성 실습13. 다음에 수행할 작업

Amazon Aurora에서 개념 증명 수행

다음은 Aurora에 대해 개념 증명을 설정하고 실행하는 방법에 대한 설명입니다. 개념 증명은 Aurora가 애플리케이션에 적합한지 확인하기 위해 수행하는 조사입니다. 개념 증명을 통해 고객님의 고유한 데이터베이스 애플리케이션의 컨텍스트에서 Aurora 기능을 이해할 수 있고 Aurora가 현재 데이터베이스 환경과 어떻게 대비되는지 알 수 있습니다. 또한 데이터 이동, SQL 코드 포트, 성능 튜닝, 현재 관리 절차 변경에 필요한 작업의 수준을 알 수 있습니다.

이 주제에서는 아래에 나열된 것과 같이 개념 증명을 실행하는 데 수반되는 높은 수준의 절차 및 의사 결정의 개요와 단계별 요점이 정리되어 있습니다. 자세한 지침을 얻으려면 특정 주제에 대한 전체 문서로 연결되는 링크를 따라가면 됩니다.

Aurora 개념 증명 개요

Amazon Aurora에 대한 개념 증명을 수행할 때는 기존 데이터 및 SQL 애플리케이션을 Aurora로 포팅하기 위해 필요한 것이 무엇인지 알아야 합니다. 프로덕션 환경을 대표하는 다량의 데이터 및 활동을 사용하여 규모에 따라 Aurora의 여러 가지 중요 속성을 시험합니다. 이 작업의 목표는 이전 데이터베이스 인프라에 맞지 않게 만드는 과제와 Aurora의 장점이 서로 잘 부합하는지에 대한 확신을 얻는 것입니다. 개념 증명을 마치는 시점에 더 큰 규모의 성능 벤치마킹과 애플리케이션 테스트를 수행할 확고한 계획이 수립됩니다. 이 시점에서 프로덕션 배포까지의 과정 중 가장 큰 작업 항목에 대해 이해하게 됩니다.

모범 사례에 대한 다음 조언을 통해 벤치마킹 중에 문제를 일으키는 일반적인 실수를 피할 수 있습니다. 그러나 이 주제에서는 벤치마크 수행 및 성능 튜닝 수행의 단계별 과정은 다루지 않습니다. 그러한 절차는 워크로드와 고객님이 사용하는 Aurora 기능에 따라 달라집니다. 자세한 내용은 Aurora DB 클러스터의 성능 및 확장 관리, Amazon Aurora MySQL 성능 개선 사항, Amazon Aurora PostgreSQL 관리, 성능 개선 도우미를 통한 Amazon Aurora 모니터링와 같은 성능 관련 문서를 참조하십시오.

이 주제에서 제공하는 정보는 조직이 코드를 작성하고 스키마를 설계하며 MySQL 및 PostgreSQL 오픈 소스 데이터베이스 엔진을 지원하느 애플리케이션에 주로 적용됩니다. 애플리케이션 프레임워크에서 생성하는 상업용 애플리케이션 또는 코드를 테스트하는 경우, 모든 지침을 적용할 수 있는 유연성을 갖지 못할 수 있습니다. 그러한 경우 AWS 담당자와 함께 사용하는 애플리케이션 유형에 대한 Aurora 모범 사례 또는 사례 연구가 있는지 확인하세요.

1. 목표 식별

Aurora를 개념 증명의 일부로 평가할 때 무엇을 측정할 것이며 시험의 성공을 어떤 방식으로 평가할 것인지 선택해야 합니다.

애플리케이션의 모든 기능이 Aurora와 호환되는지 반드시 확인해야 합니다. Aurora 메이저 버전은 해당 MySQL 및 PostgreSQL 메이저 버전과도 유선 호환되므로 이러한 엔진을 위해 개발된 애플리케이션은 대부분 Aurora와도 호환됩니다. 하지만 그럼에도 개별 애플리케이션에 대해 호환성을 검증해야 합니다.

예를 들어 Aurora 클러스터를 설정할 때 선택하는 구성 중 일부는 특정 데이터베이스 기능을 사용할 수 있는지 또는 사용해야 하는지에 대해 영향을 미칩니다. 프로비저닝되었다라는 표현을 쓰는 가장 범용성이 큰 Aurora 클러스터로 시작할 수 있습니다. 그런 다음 서버리스 또는 병렬 쿼리와 같은 특수 구성이 고객님의 워크로드에 이점을 제공하는지 여부를 판단할 수 있습니다.

다음 질문을 사용하면 고객님의 목표를 식별하고 계량화하는 데 도움이 됩니다.

  • Aurora는 워크로드의 모든 기능적 사용 사례를 지원합니까?

  • 어떤 데이터세트 크기 또는 로드 수준을 원하십니까? 그러한 수준으로 규모를 조정할 수 있습니까?

  • 고객님의 구체적인 쿼리 처리량 또는 지연 요구 사항은 무엇입니까? 이 요건을 달성할 수 있습니까?

  • 워크로드에 대한 계획된 또는 계획되지 않은 가동 중단을 수용할 수 있는 최소 시간은 얼마입니까? 이 목표를 달성할 수 있습니까?

  • 운영 효율성 유지에 필수적인 지표는 무엇입니까? 이 지표를 정확하게 모니터링할 수 있습니까?

  • Aurora는 비용 절감, 배포 증가 또는 프로비저닝 속도와 같은 특정 비즈니스 목표를 지원합니까? 이러한 목표를 계량화할 수 있는 방법이 있습니까?

  • 워크로드에 대한 모든 보안 및 규정 준수 요구 사항을 충족할 수 있습니까?

약간의 시간을 들여 Aurora 데이터베이스 엔진 및 플랫폼 기능에 대한 지식을 쌓고 서비스 설명서를 검토하십시오. 원하는 성과를 얻는 데 도움이 될 수 있는 모든 기능을 메모해 두십시오. 이러한 기능 중 한 가지는 AWS 데이터베이스 블로그 게시글 통합 워크로드를 위해 MySQL과 호환되는 Amazon Aurora를 계획하고 최적화하는 방법에서 설명하는 워크로드 통합입니다. 또 다른 한 가지는 Amazon Aurora 사용 설명서의 Aurora 복제본에 Amazon Aurora Auto Scaling 사용에 설명된 수요 기반 확장입니다. 그밖에 성능 향상 또는 단순화된 데이터베이스 연산이 있습니다.

2. 워크로드 특성에 대한 이해

의도한 사용 사례의 맥락에서 Aurora를 평가하세요. Aurora는 온라인 트랜잭션 처리(OLTP) 워크로드에 좋은 선택입니다. 또한 별도의 데이터 웨어하우스 클러스터를 프로비저닝하지 않고도 실시간 OLTP 데이터를 보유한 클러스터에서 보고서를 실행할 수 있습니다. 다음 특성을 확인하여 사용 사례가 이 범주에 해당하는지 알아낼 수 있습니다.

  • 동시 클라이언트가 수십, 수백 또는 수천에 달하는 높은 동시성

  • 지연 시간이 밀리초에서 몇 초로 짧은 대량의 쿼리

  • 짧은 실시간 트랜잭션

  • 인덱스 기반 조회 기능을 갖춘 고도로 선택적인 쿼리 패턴

  • HTAP의 경우, Aurora 병렬 쿼리를 이용할 수 있는 분석적 쿼리

데이터베이스 선택에 영향을 미치는 주된 요인 중 한 가지는 데이터 속도입니다. 빠른 속도에는 매우 자주 삽입되고 업데이트되는 데이터가 수반됩니다. 이러한 시스템에는 데이터베이스에 대한 수천 건의 연결과 수십만 건의 동시 쿼리 읽기 및 쓰기가 발생할 수 있습니다. 고속 시스템에서 발생하는 쿼리는 비교적 적은 수의 행에 영향을 미치는 것이 보통이며, 일반적으로 동일 행에 있는 여러 열에 액세스합니다.

Aurora는 고속 데이터 처리를 위해 설계되었습니다. 워크로드에 따라 단일 r4.16xlarge DB 인스턴스가 포함된 Aurora 클러스터는 초당 600,000건 이상의 SELECT 문을 처리할 수 있습니다. 이러한 클러스터는 워크로드에 따라 초당 200,000개의 INSERT, UPDATE 및 DELETE 문을 처리할 수 있습니다. Aurora는 행 스토어 데이터베이스로, 대량의 처리량 및 고도로 병렬화된 OLTP 워크로드에 이상적입니다.

또한 Aurora는 OLTP 워크로드를 처리하는 동일한 클러스터에서 보고 쿼리를 실행할 수도 있습니다. Aurora는 최대 15개의 복제본을 지원하며, 각 복제본은 기본 인스턴스에서 평균 10~20밀리초 이내에 지원됩니다. 분석가는 데이터를 별도 데이터 웨어하우스 클러스터에 복사하지 않고도 실시간으로 OLTP 데이터를 쿼리할 수 있습니다. 병렬 쿼리 기능을 사용하는 Aurora 클러스터를 통해 처리 필터링 대부분과 집계 작업을 엄청나게 분산된 Aurora 스토리지 하위 시스템으로 오프로드할 수 있습니다.

이 계획 단계를 사용하여 Aurora, 기타 AWS 서비스, AWS Management Console 및 AWS CLI의 기능을 숙지하세요. 또한 이러한 것들이 고객님이 개념 증명에 사용할 계획인 기타 도구와 어떻게 연동되는지 확인하십시오.

3. AWS Management Console 또는 AWS CLI를 이용한 실습

다음 단계로 AWS Management Console 또는 AWS CLI를 이용한 실습을 통해 이러한 도구와 Aurora를 숙지하세요.

AWS Management Console을 이용한 실습

Aurora 데이터베이스 클러스터를 이용한 다음과 같은 초기 활동은 주로 AWS Management Console 환경을 숙지하고 Aurora 클러스터 설정 및 수정을 연습할 수 있도록 하기 위한 것입니다. Amazon RDS에서 MySQL 호환 및 PostgreSQL 호환 데이터베이스 엔진을 사용하는 경우, Aurora를 사용할 때 이 지식을 활용할 수 있습니다.

Aurora 공유 스토리지 모델과 복제, 스냅샷과 같은 기능을 이용하여 전체 데이터베이스 클러스터를 고객님이 자유롭게 조작할 수 있는 다른 종류의 객체로 취급할 수 있습니다. 개념 증명 중에 Aurora 클러스터의 용량을 자주 설정, 제거 및 변경할 수 있습니다. 용량, 데이터베이스 설정 및 물리적 데이터 레이아웃에 대한 초기 선택에 락인(lock-in)되지 않습니다.

시작하려면 빈 Aurora 클러스터를 설정하십시오. 초기 실험에 대해 provisioned(프로비저닝된) 용량 유형과 regional(리전) 위치를 선택합니다.

SQL 명령줄 애플리케이션과 같은 클라이언트 프로그램을 사용해 이 클러스터에 연결합니다. 처음에는 클러스터 엔드포인트를 사용해 연결합니다. 이 엔드포인트에 연결하여 데이터 정의 언어(DDL) 문과 추출, 변환, 로드(ETL) 프로세스와 같은 쓰기 연산을 수행합니다. 개념 증명 후반부에는 쿼리 워크로드를 클러스터에 있는 여러 DB 인스턴스에 배포하는 리더 엔드포인트를 사용해 쿼리 집약적인 세션을 연결합니다.

Aurora 복제본을 추가하여 클러스터의 규모를 확장하십시오. 이를 위한 절차는 Amazon Aurora를 사용한 복제 단원을 참조하십시오. AWS 인스턴스 클래스를 변경하여 DB 인스턴스의 규모를 확장 또는 축소합니다. 시스템 용량에 대한 초기 추정치가 부정확한 경우 처음부터 다시 시작하지 않고 나중에 조정할 수 있도록 Aurora가 이러한 종류의 연산을 어떻게 단순화하는지 이해하십시오.

스냅샷을 생성하여 다른 클러스터로 복원합니다.

클러스터 지표를 검토하여 시간 경과에 따른 활동을 보고 지표가 클러스터 내의 DB 인스턴스에 어떻게 적용되는지 알아보십시오.

처음에는 AWS Management Console을 통해 이러한 작업을 수행하는 방법을 숙지하면 도움이 됩니다. Aurora로 할 수 있는 작업이 무엇인지 이해하고 나면 AWS CLI를 사용해 이러한 작업을 자동화하는 단계로 나아갈 수 있습니다. 다음 단원에서는 개념 증명 기간 중 이러한 활동의 절차와 모범 사례에 대한 더 자세한 내용을 보실 수 있습니다.

AWS CLI을 이용한 실습

개념 증명 설정에서도 배포 및 관리 절차를 자동화하는 것이 좋습니다. 이를 위해서는 AWS CLI를 숙지해야 합니다. Amazon RDS에서 MySQL 호환 및 PostgreSQL 호환 데이터베이스 엔진을 사용하는 경우, Aurora를 사용할 때 이 지식을 활용할 수 있습니다.

Aurora에는 일반적으로 클러스터 내에 정렬된 DB 인스턴스 그룹이 수반됩니다. 따라서 많은 연산에는 어떤 DB 인스턴스가 클러스터와 연결되어 있는지 확인하고 모든 인스턴스의 루프에서 관리 연산을 수행하는 작업이 수반됩니다.

예를 들어 Aurora 클러스터 생성과 같은 단계를 자동화한 후 더 규모가 큰 인스턴스 클래스로 확장하거나 추가 DB 인스턴스로 확장할 수 있습니다. 이렇게 하면 개념 증명 중에서 어느 단계이든 반복할 수 있고 다양한 종류 또는 구성의 Aurora 클러스터가 포함된 가정(what-if) 시나리오를 탐색하는 데 도움이 됩니다.

AWS CloudFormation과 같은 인프라 배포 도구의 기능 및 제한 사항에 대해 알아보십시오. 개념 증명 컨텍스트에서 수행하는 활동은 프로덕션 용도로 적합하지 않다는 것을 알게 될 수도 있습니다. 예를 들어 수정을 위한 AWS CloudFormation 동작은 새 인스턴스를 생성하고 데이터를 포함한 현재 인스턴스를 삭제하는 것입니다. 이 동작에 대한 자세한 내용은 AWS CloudFormation 사용 설명서의 스택 리소스의 업데이트 동작을 참조하세요.

4. Aurora 클러스터 생성

Aurora에서는 DB 인스턴스를 클러스터에 추가하고 DB 인스턴스를 더 강력한 인스턴스 클래스로 확장하여 가정(what-if) 시나리오를 탐색할 수 있습니다. 또한 구성 설정이 다양한 클러스터를 생성하여 동일한 워크로드를 병렬로 실행할 수 있습니다. Aurora는 DB 클러스터를 설정, 제거 및 구성할 수 있는 유연성이 높습니다. 이를 고려할 때 개념 증명 프로세스 초기 단계에서 이러한 기법을 실습하는 것이 도움이 됩니다. Aurora 클러스터 생성을 위한 일반적인 절차는 Amazon Aurora DB 클러스터 생성 단원을 참조하십시오.

실현 가능한 경우 다음 설정을 사용해 클러스터를 시작하십시오. 염두에 두고 계신 구체적인 특정 사용 사례가 있는 경우에만 이 단계를 건너뛰십시오. 예를 들어 고객님의 사용 사례에 특수한 종류의 Aurora 클러스터가 필요한 경우 이 단계를 건너뛸 수 있습니다. 또는 데이터베이스 엔진 및 버전의 특정 조합이 필요한 경우 건너뛸 수 있습니다.

  • [간편 생성(Easy create)]을 비활성화합니다. 개념 증명의 경우 나중에 동일한 또는 약간 다른 클러스터를 생성할 수 있도록 고객님이 선택하는 모든 설정을 숙지하는 것이 좋습니다.

  • 최신 DB 엔진 버전을 사용하세요. 데이터베이스 엔진 및 버전의 이러한 조합은 다른 Aurora 기능과 폭넓게 호환되며 프로덕션 애플리케이션의 고객 사용량이 상당히 큽니다.

    • Aurora MySQL 버전 3.x (MySQL 8.0 호환)

    • Aurora PostgreSQL 버전 15.x 또는 16.x

  • 개발/테스트 템플릿을 선택합니다. 이 선택은 개념 증명 활동에 중요하지는 않습니다.

  • [DB 인스턴스 클래스(DB instance class)]에서 [메모리 최적화 클래스((Memory optimized classes)]와 [xlarge] 인스턴스 클래스 중 하나를 선택합니다. 나중에 인스턴스 클래스를 확장 또는 축소 조정할 수 있습니다.

  • [다중 AZ 배포(Multi-AZ Deployment)]에서 [다른 AZ에 Aurora 복제본 또는 리더 노드 생성(Create an Aurora Replica or Reader node in a different AZ)]을 선택합니다. Aurora가 지닌 가장 유용한 속성 중 다수는 여러 DB 인스턴스로 구성된 클러스터와 관련된 것입니다. 새로운 클러스터에서는 항상 최소 2개의 DB 인스턴스로 시작하는 것이 타당합니다. 두 번째 DB 인스턴스에 대해 다른 가용 영역을 사용하면 다양한 고가용성 시나리오를 테스트하는 데 도움이 됩니다.

  • DB 인스턴스의 이름을 선택할 때 일반적인 이름 지정 규칙을 사용하십시오. 클러스터 DB 인스턴스를 “라이터”로 참조해서는 안 됩니다. 서로 다른 DB 인스턴스는 이러한 역할을 필요에 따라 수임하기 때문입니다. clustername-az-serialnumber과 같은 것을 사용하는 것이 좋습니다(예: myprodappdb-a-01). 이 조각들은 DB 인스턴스와 그 배치를 고유하게 식별합니다.

  • Aurora 클러스터에 대해 백업 보존을 ‘높음’으로 설정합니다. 장기 보존 기간을 통해 최대 35일 동안 PITR(특정 시점으로 복구)를 수행할 수 있습니다. DDL 및 데이터 조작 언어(DML) 문과 관련된 테스트를 실행한 후에 데이터베이스를 알려진 상태로 재설정할 수 있습니다. 또한 실수로 데이터를 삭제 또는 변경한 경우 이를 복구할 수 있습니다.

  • 클러스터 생성 시 추가 복구, 로깅 및 모니터링 기능을 활성화합니다. 역추적, 성능 개선 도우미, 모니터링 및 로그 내보내기에서 사용 가능한 모든 선택지를 활성화합니다. 이러한 기능을 활성화하면 워크로드에 대한 역추적, 확장 모니터링 또는 성능 개선 도우미와 같은 기능의 적합성을 테스트할 수 있습니다. 또한 개념 증명 중에 성능을 쉽게 조사하고 문제 해결을 수행할 수 있습니다.

5. 스키마 설정

Aurora 클러스터에서 애플리케이션을 위한 데이터베이스, 테이블, 인덱스, 외래 키 및 기타 스키마 객체를 설정하십시오. 다른 MySQL 호환 또는 PostgreSQL 호환 데이터베이스 시스템으로부터 다른 시스템으로 이동하는 경우 이 단계는 단순하고 간결할 것으로 기대하시면 됩니다. 데이터베이스 엔진에 대해서는 동일한 SQL 구문 및 명령줄 또는 고객님이 잘 알고 있는 기타 클라이언트 애플리케이션을 사용하십시오.

클러스터에 SQL 문을 발행하려면 클러스터 엔드포인트를 찾아 그 값을 클라이언트 애플리케이션에 연결 파라미터로 제공하십시오. 클러스터 세부 정보 페이지에 있는 Connectivity(연결성) 탭에서 클러스터 엔드포인트를 찾을 수 있습니다. 이 클러스터 엔드포인트는 Writer(라이터)라고 레이블이 지정된 것입니다. Reader(리더)라는 레이블이 지정된 다른 엔드포인트는 보고서 또는 기타 읽기 전용 쿼리를 실행하는 최종 사용자에게 공급할 수 있는 읽기 전용 연결을 대표합니다. 고객님의 클러스터에 연결하는 것과 관련된 모든 문제에 대한 도움을 받으려면 Amazon Aurora DB 클러스터에 연결 단원을 참조하십시오.

다른 데이터베이스 시스템에서 스키마와 데이터를 포트하는 경우 이 시점에서 일부 스키마 변경이 이루어질 것으로 기대해야 합니다. 이러한 스키마 변경 사항은 Aurora에서 사용할 수 있는 SQL 구문과 역량과 부합해야 합니다. 이 시점에서 특정 열, 제약 조건, 트리거 또는 기타 스키마 객체는 생략할 수 있습니다. 이렇게 하면 특히 이 객체들이 Aurora 호환성을 위해 재작업이 필요하고 개념 증명 관련 목표에는 중요하지 않은 경우 도움이 될 수 있습니다.

기본 엔진이 Aurora의 기본 엔진과 다른 데이터베이스 시스템에서 마이그레이션하는 경우 AWS Schema Conversion Tool(AWS SCT)을 사용해 프로세스를 간소화하는 것을 고려하세요. 자세한 내용은 AWS Schema Conversion Tool 사용 설명서를 참조하세요. 마이그레이션 및 포트 활동에 대한 일반적인 세부 정보는 AWS 백서, Migrating Your Databases to Amazon Aurora(Amazon Aurora로 데이터베이스 마이그레이션)를 참조하세요.

이 단계에서는 스키마 설정과 관련해(예: 인덱싱 전략 또는 분할된 테이블과 같은 기타 테이블 구조) 비효율성이 있는지 평가할 수 있습니다. 이러한 비효율성은 DB 인스턴스가 여러 개이고 워크로드가 큰 클러스터에 애플리케이션을 배포하면 증폭될 수 있습니다. 지금 또는 전체 벤치마크 테스트와 같은 추후 활동 중에 이러한 성능 속성을 미세 조정할 수 있을지 고려하십시오.

6. 데이터 가져오기

개념 증명 중에 이전 데이터베이스 시스템에서 데이터 또는 대표 샘플을 가져오십시오. 실현 가능한 경우 각 테이블에 최소한 일부라도 데이터를 설정하십시오. 이렇게 하면 모든 데이터 유형 및 스키마 기능의 호환성을 테스트하는 데 도움이 됩니다. 기본 Aurora 기능을 사용해본 후에 데이터 양을 늘리십시오. 개념 증명이 끝나가는 시점에 정확한 결론을 도출할 수 있을 만큼 큰 데이터세트로 ETL 도구, 쿼리 및 전체 워크로드를 테스트해야 합니다.

몇 가지 기법을 사용해 물리적 또는 논리적 백업 데이터를 Aurora로 가져올 수 있습니다. 자세한 내용은 개념 증명에 사용 중인 데이터베이스 엔진에 따라 Amazon Aurora MySQL DB 클러스터로 데이터 마이그레이션 또는 데이터를 PostgreSQL과 호환되는 Amazon Aurora로 마이그레이션 단원을 참조하십시오.

현재 고려 중인 ETL 도구 및 기술을 실험해 보십시오. 고객님의 필요를 가장 잘 충족하는 것이 무엇인지 확인하십시오. 처리량과 유연성을 모두 고려하십시오. 예를 들어 어떤 ETL 도구는 일회성 전송을 수행하고 어떤 ETL 도구는 낡은 시스템에서 Aurora로의 지속적인 복제가 수반됩니다.

MySQL 호환 시스템에서 Aurora MySQL로 마이그레이션하는 경우 기본 데이터 전송 도구를 사용할 수 있습니다. PostgreSQL 호환 시스템에서 Aurora PostgreSQL으로 마이그레이션하는 경우에도 마찬가지입니다. Aurora에서 사용하는 기본 엔진이 아닌 다른 기본 엔진을 사용하는 데이터베이스 시스템에서 마이그레이션하는 경우 AWS Database Migration Service(AWS DMS)로 실험할 수 있습니다. AWS DMS에 대한 자세한 내용은 AWS Database Migration Service 사용 설명서를 참조하세요.

마이그레이션 및 포트 활동에 대한 자세한 내용은 AWS 백서인 Aurora 마이그레이션 핸드북을 참조하세요.

7. SQL 코드 포팅

SQL 및 연결된 애플리케이션을 사용해보려면 다양한 사례에 따라 다양한 수준의 작업이 필요합니다. 특히 작업의 수준은 MySQL 호환 또는 PostgreSQL 호환 시스템 또는 다른 종류의 시스템 중 어느 시스템에서 이동하느냐에 따라 달라집니다.

  • RDS for MySQL 또는 RDS for PostgreSQL에서 이동하는 경우 SQL 변경 사항은 Aurora를 이용해 원본 SQL 코드를 사용하고 필요한 변경 사항을 수동으로 통합할 수 있을 정도로 적습니다.

  • 이와 마찬가지로 MySQL 또는 PostgreSQL과 호환되는 온프레미스 데이터베이스에서 이동하는 경우 원본 SQL 코드를 사용해보고 변경 사항을 수동으로 통합할 수 있습니다.

  • 다른 상업용 데이터베이스에서 이동하는 경우에는 필수 SQL 변경 사항이 더 광범위합니다. 이 경우에는 AWS SCT 사용을 고려하십시오.

이 단계에서는 스키마 설정과 관련해(예: 인덱싱 전략 또는 분할된 테이블과 같은 기타 테이블 구조) 비효율성이 있는지 평가할 수 있습니다. 지금 또는 전체 벤치마크 테스트와 같은 추후 활동 중에 이러한 성능 속성을 미세 조정할 수 있을지 고려하십시오.

애플리케이션에서 데이터베이스 연결 로직을 확인할 수 있습니다. Aurora 분산형 처리를 이용하려면 읽기 및 쓰기 연산에 대해 별도의 연결을 사용하고 쿼리 연산에 대해 비교적 짧은 세션을 사용해야 할 수 있습니다. 연결에 관한 자세한 내용은 9. Aurora에 연결 단원을 참조하십시오.

프로덕션 데이터베이스에서 문제를 해결하기 위해 타협과 거래를 해야 했는지 생각해 보십시오. 개념 증명 일정에 스키마 설계 및 쿼리를 개선할 수 있는 시간을 할애하십시오. 성능, 운영 비용 및 확장성 개선을 쉽게 달성할 수 있는지 여부를 판단하려면 다양한 Aurora 클러스터에서 원본 및 수정 애플리케이션을 나란히 사용해 보십시오.

마이그레이션 및 포트 활동에 대한 자세한 내용은 AWS 백서인 Aurora 마이그레이션 핸드북을 참조하세요.

8. 구성 설정 지정

Aurora 개념 증명 실습의 일부로 데이터베이스 구성 파라미터를 검토할 수도 있습니다. 현재 환경에서 성능 및 확장성을 위해 MySQL 또는 PostgreSQL 구성 설정을 이미 튜닝했을 수도 있습니다. Aurora 스토리지 하위 시스템은 고속 스토리지 하위 시스템을 통해 분산형 클라우드 기반 환경에 맞게 조정 및 튜닝됩니다. 결과적으로 다수의 이전 데이터베이스 엔진 설정은 적용되지 않습니다. 초기 실험은 기본 Aurora 구성 설정으로 수행하는 것이 좋습니다. 성능 및 확장성 병목 현상이 발생하는 경우에만 현재 환경의 설정을 다시 적용하십시오. 관심이 있는 경우 이 주제에 관해 더 깊이 알아보려면 AWS 데이터베이스 블로그의 Aurora 스토리지 엔진 소개를 참조하세요.

Aurora 덕분에 특정 애플리케이션 또는 사용 사례에 최적의 구성 설정을 쉽게 재사용할 수 있습니다. 각 DB 인스턴스에 대해 별도의 구성 파일을 편집하는 대신에 전체 클러스터 또는 특정 DB 인스턴스에 할당하는 파라미터 세트를 관리하십시오. 예를 들어 시간대 설정은 클러스터의 모든 DB 인스턴스에 적용되며 각 DB 인스턴스에 대한 페이지 캐치 크기 설정을 조정할 수 있습니다.

기본 파라미터 세트 중 하나로 시작하고, 미세 조정해야 할 파라미터에만 변경 사항을 적용하십시오. 파라미터 그룹 사용에 대한 자세한 내용은 Amazon Aurora DB 클러스터와 DB 인스턴스 파라미터 단원을 참조하십시오. Aurora 클러스터에 적용되거나 적용되지 않는 구성 설정에 대해서는 데이터베이스 엔진에 따라 Aurora MySQL 구성 파라미터 또는 Amazon Aurora PostgreSQL parameters를 참조하십시오.

9. Aurora에 연결

초기 스키마 및 데이터 설정을 수행하고 샘플 쿼리를 실행할 시점을 알게 됨에 따라 Aurora 클러스터에서 다양한 엔드포인트에 연결할 수 있습니다. 사용할 엔드포인트는 연산이 SELECT 문과 같은 읽기인지, 아니면 CREATE 또는 INSERT 문과 같은 쓰기인지에 따라 달라집니다. Aurora 클러스터에서 워크로드를 늘리고 Aurora 기능으로 실험을 할 때 애플리케이션이 각 연산을 적절한 엔드포인트에 할당하는 것이 중요합니다.

클러스터 엔드포인트를 쓰기 연산에 사용하면 읽기/쓰기 기능이 있는 클러스터의 DB 인스턴스에 항상 연결됩니다. 기본적으로 Aurora 클러스터에 있는 하나의 DB 인스턴스에만 읽기-쓰기 기능이 있습니다. 이 DB 인스턴스를 기본 인스턴스라고 합니다. 원본 기본 인스턴스를 사용할 수 없게 되면 Aurora는 장애 조치 메커니즘을 활성화하고 다른 DB 인스턴스가 기본 인스턴스로 인계를 받습니다.

이와 마찬가지로 SELECT 문을 리더 엔드포인트로 유도함으로써 쿼리를 처리하는 작업을 클러스터 내 DB 인스턴스에 분산할 수 있습니다. 각 리더 연결은 라운드 로빈 DNS 확인을 사용해 다른 DB 인스턴스에 할당됩니다. 읽기 전용 DB Aurora 복제본에서 대부분의 쿼리 작업을 하면 기본 인스턴스에 대한 로드가 줄어들어 DDL 및 DML 문을 처리할 수 있는 여유가 생깁니다.

이러한 엔드포인트를 사용하면 하드 코딩된 호스트 이름에 대한 종속성이 줄어들고 애플리케이션이 DB 인스턴스 장애에서 더 빨리 복구될 수 있습니다.

참고

Aurora에는 고객님이 생성하는 사용자 지정 엔드포인트가 있습니다. 이러한 엔드포인트는 개념 증명 중에는 대개 필요하지 않습니다.

Aurora 복제본은 복제본 지연 시간이 대개 10-20밀리초라 하더라도 이 지연 시간의 적용을 받습니다. 복제 지연 시간을 모니터링하고 데이터 일관성 요구 사항의 범위 내에 있는지 확인할 수 있습니다. 어떤 경우에는 읽기 쿼리에 강력한 읽기 일관성이 필요합니다(쓰기 후 읽기 일관성). 이 경우 해당 쿼리에 리더 엔드포인트가 아닌 클러스터 엔드포인트를 계속 사용할 수 있습니다.

분산형 병렬 실행을 위한 Aurora 기능을 최대한 활용하려면 연결 로직을 변경해야 할 수 있습니다. 목표는 모든 읽기 요청을 기본 인스턴스로 전송하는 일을 방지하는 것입니다. 읽기 전용 Aurora 복제본은 모든 동일 데이터와 함께 대기하면서 SELECT 문을 처리할 준비를 하고 있습니다. 애플리케이션 로직을 코딩하여 각각의 연산 유형에 적절한 엔드포인트를 사용하십시오. 다음과 같은 일반 지침을 따르십시오.

  • 모든 데이터베이스 세션에 하드 코딩된 단일 연결 문자열을 사용하지 않도록 하십시오.

  • 가능한 경우 DDL 및 DDL 문과 같은 쓰기 연산을 클라이언트 애플리케이션 코드 내 함수에 묶습니다. 이렇게 하면 다양한 종류의 연산에서 특정 연결을 사용하게 할 수 있습니다.

  • 쿼리 작업을 위해 별도의 함수를 만듭니다. Aurora는 리더 엔드포인트에 대한 각각의 새 연결을 다른 Aurora 복제본에 할당하여 읽기 집약적인 애플리케이션에 대해 로드 밸런싱을 수행합니다.

  • 쿼리 세트를 수반하는 연산의 경우 관련된 각 쿼리 세트가 완료되면 리더 엔드포인트에 대한 연결을 종료한 후 다시 엽니다. 이 기능을 소프트웨어 스택에서 사용할 수 있다면 연결 풀링을 사용하십시오. 서로 다른 연결에 쿼리를 유도하면 Aurora가 클러스터 내 DB 인스턴스에 읽기 워크로드를 분산하는 데 도움이 됩니다.

Aurora의 연결 관리 및 엔드포인트에 대한 일반적인 정보는 Amazon Aurora DB 클러스터에 연결 단원을 참조하십시오. 이 주제에 관해 자세히 알아보려면 Aurora MySQL 데이터베이스 관리자용 핸드북 – 연결 관리를 참조하십시오.

10. 워크로드 실행

스키마, 데이터 및 구성 설정을 완료한 후에는 워크로드를 실행하여 클러스터에 대한 실습을 시작할 수 있습니다. 프로덕션 워크로드의 주요 속성을 반영하는 워크로드를 개념 증명에 사용하십시오. 항상 sysbench 또는 TPC-C와 같은 합성 벤치마크보다는 실제 테스트 및 워크로드를 사용해 성능 관련 의사결정을 내리는 것이 좋습니다.

가능한 한 애플리케이션이 실행될 실제 조건을 복제하십시오. 예를 들어 사용자는 일반적으로 Aurora 클러스터와 동일한 AWS 리전과 동일한 Virtual Private Cloud(VPC)에 있는 Amazon EC2 인스턴스에서 애플리케이션 코드를 실행합니다. 프로덕션 애플리케이션이 여러 가용 영역에 걸쳐 있는 여러 EC2 인스턴스에서 실행되는 경우 이와 동일한 방법으로 개념 증명 환경을 설정하십시오. AWS 리전에 대한 자세한 내용은 Amazon RDS 사용 설명서의 리전 및 가용 영역을 참조하세요. Amazon VPC 서비스에 대한 자세한 내용은 Amazon VPC 사용 설명서의 Amazon VPC란 무엇인가? 단원을 참조하십시오.

애플리케이션 작업의 기본 기능을 확인하고 나서 Aurora를 통해 데이터에 액세스할 수 있게 되었다면 Aurora 클러스터의 여러 속성을 실습해볼 수 있습니다. 시험해 보려는 기능 중 일부는 로드 밸런싱, 동시 트랜잭션 및 자동 복제와의 동시 연결입니다.

이 시점이 되면 데이터 전송 메커니즘이 익숙할 것이므로 더 큰 비율의 샘플 데이터를 이용해 테스트를 실행할 수 있습니다.

이 단계에서는 메모리 제한 및 연결 제한과 같은 구성 설정을 변경하면 결과가 어떻게 되는지 확인할 수 있습니다. 8. 구성 설정 지정에서 알아본 절차를 다시 살펴보십시오.

스냅샷 생성 및 복원과 같은 메커니즘을 이용해 실험할 수도 있습니다. 예를 들어 다양한 AWS 인스턴스 클래스, AWS 복제본의 수 등을 이용해 클러스터를 생성할 수 있습니다. 그런 다음 각 클러스터에서 스키마와 모든 데이터가 포함된 동일한 스냅샷을 복원할 수 있습니다. 이 주기에 대한 자세한 내용은 DB 클러스터 스냅샷 생성 및 DB 클러스터 스냅샷에서 복원 단원을 참조하십시오.

11. 성능 측정

이 영역의 모범 사례는 적합한 모든 도구와 프로세스를 설정하여 워크로드 연산 중에 비정상적 작동을 신속히 격리하도록 설계되었습니다. 또한 이러한 설정을 통해 해당되는 모든 원인을 안정적으로 식별할 수 있는지 확인할 수 있습니다.

항상 모니터링 탭을 검토하여 클러스터의 현재 상태를 확인하거나 시간 경과에 따른 추세를 살펴볼 수 있습니다. 이 탭은 각 Aurora 클러스터 또는 DB 인스턴스의 콘솔 세부 정보 페이지에 제공됩니다. 이 탭에는 Amazon CloudWatch 모니터링 서비스의 지표가 차트 형태로 표시됩니다. 지표를 이름, DB 인스턴스, 기간을 기준으로 필터링할 수 있습니다.

모니터링 탭에서 더 많은 사항을 선택할 수 있게 하려면 클러스터 설정에서 기본 모니터링 및 성능 개선 도우미를 활성화하십시오. 클러스터 설정 시 이를 선택하지 않았다면 이 선택 항목을 활성화할 수도 있습니다.

성능을 측정하려면 전체 Aurora 클러스터에 대한 활동을 보여주는 차트에 거의 의존해야 합니다. Aurora 복제본의 로드 및 응답 횟수가 이와 유사한지 확인할 수 있습니다. 읽기/쓰기 기본 인스턴스와 읽기 전용 Aurora 복제본 간에 작업이 분할되는 방식도 확인할 수 있습니다. DB 인스턴스 간 약간의 불균형 또는 하나의 DB 인스턴스에만 영향을 미치는 문제가 있는 경우 이 특정 인스턴스의 모니터링 탭을 검토할 수 있습니다.

환경 및 실제 워크로드를 설정하여 프로덕션 애플리케이션을 에뮬레이션한 후에는 Aurora가 얼마나 잘 작동하는지 성능을 측정할 수 있습니다. 답해야 할 가장 중요한 질문은 다음과 같습니다.

  • Aurora가 초당 몇 건의 쿼리를 처리하고 있습니까? Throughput(처리량) 지표를 검토하여 다양한 연산 유형의 수치를 확인할 수 있습니다.

  • Aurora가 특정 쿼리를 처리하는 데 평균적으로 시간이 얼마나 걸립니까? Latency(지연 시간) 지표를 검토하여 다양한 연산 유형의 수치를 확인할 수 있습니다.

이를 위해서는 아래에 설명된 대로 Amazon RDS 콘솔에서 해당 Aurora 클러스터의 [모니터링(Monitoring)] 탭을 살펴보세요.

가능하다면 이러한 지표의 기준 값을 현재 환경에 설정하십시오. 불가능하다면 프로덕션 애플리케이션과 동등한 워크로드를 실행하여 Aurora 클러스터에 기준을 구성하십시오. 예를 들어 동시 사용자 및 쿼리의 수가 비슷한 Aurora 워크로드를 실행할 수 있습니다. 그런 다음 다양한 인스턴스 클래스, 클러스터 크기, 구성 설정 등으로 실험해 가면서 값이 어떻게 변하는지 관찰합니다.

처리량 숫자가 예상보다 낮으면 워크로드 처리를 위한 데이터베이스 성능에 영향을 미치는 요인을 더 조사하십시오. 이와 마찬가지로 지연 시간 숫자가 예상보다 더 높다면 추가 조사를 실시합니다. 이를 위해서는 DB 서버의 보조 지표(CPU, 메모리 등)를 모니터링해야 합니다. DB 인스턴스 각 지표의 한도에 근접하는지 확인할 수 있습니다. 또한 DB 인스턴스가 동시 쿼리, 더 큰 데이블에 대한 쿼리 등을 처리할 추가 용량이 얼마나 되는지도 확인할 수 있습니다.

작은 정보

예상 범위를 벗어나는 지표 값을 감지하려면 CloudWatch 경보를 설정하십시오.

이상적인 Aurora 클러스터 크기 및 용량을 평가하는 과정에서 오버-프로비저닝 리소스 없이 최상의 애플리케이션 성능을 달성하는 구성을 찾을 수 있습니다. 한 가지 중요한 요인은 Aurora 클러스터에 있는 DB 인스턴스에 적절한 크기를 찾는 것입니다. 현재 프로덕션 환경과 CPU 및 메모리 용량이 비슷한 인스턴스 크기를 선택하는 것부터 시작하십시오. 선택한 인스턴스 크기에서 워크로드에 대한 처리량 및 지연 시간 수치를 수집합니다. 이어서 인스턴스를 그다음으로 큰 크기로 확장합니다. 처리량 및 지연 시간 수치가 개선되는지 확인합니다. 또한 인스턴스 크기를 줄이고, 지연 시간 및 처리량 수치가 그대로 유지되는지 확인합니다. 이 작업의 목표는 가능한 한 가장 작은 인스턴스에서 최대 처리량을 최소 지연 시간으로 얻는 것입니다.

작은 정보

기존 용량이 충분한 Aurora 클러스터 및 연의 크기를 조정하여 갑작스럽고 예측할 수 없는 트래픽 급등을 처리할 수 있게 합니다. 미션 크리티컬 데이터베이스의 경우 최소 20퍼센트의 예비 CPU 및 메모리 용량을 남겨 두십시오.

웜 및 안정적 상태에서 데이터베이스 성능을 측정하기에 충분할 만큼 오래 성능 테스트를 실행합니다. 이러한 안정적 상태에 도달하려면 수 분 또는 몇 시간 동안 워크로드를 실행해야 할 수 있습니다. 실행을 시작할 때 발생하는 약간의 편차는 정상적인 것입니다. 이러한 편차가 발생하는 이유는 각 Aurora 복제본이 자체 처리하는 SELECT 쿼리에 근거하여 캐시를 워밍업하기 때문입니다.

Aurora는 여러 동시 사용자 및 쿼리를 수반하는 트랜잭션 워크로드에서 최상의 성능을 발휘합니다. 충분한 로드를 촉진하여 최적의 성능을 얻을 수 있도록 보장하려면 멀티스레딩을 사용하는 벤치마크를 실행하거나 여러 개의 성능 테스트 인스턴스를 동시에 실행하는 벤치마크를 실행하십시오. 수백 또는 수천 건의 동시 클라이언트 스레드에서 성능을 측정하십시오. 프로덕션 환경에서 예상되는 동시 스레드의 수를 시뮬레이션하십시오. 더 많은 스레드에서 추가 스트레스 테스트를 수행하여 Aurora 확장성을 측정할 수도 있습니다.

12. Aurora 고가용성 실습

주요 Aurora 기능 중 다수는 고가용성을 포함합니다. 이러한 기능으로 자동 복제, 자동 장애 조치, 특정 시점으로 복원을 포함한 자동 백업, 클러스터에 DB 인스턴스를 추가할 수 있는 기능을 들 수 있습니다. 이러한 기능의 안전성과 안정성은 미션 크리티컬 애플리케이션에 중요합니다.

이러한 기능을 평가하려면 특정 사고 방식이 필요합니다. 성능 측정 등 앞서 한 활동에서 모든 것이 제대로 작동할 때 시스템이 어떤 성능을 보이는지 관찰하십시오. 고가용성 테스트 시 최악의 작동에 대해 충분히 생각해야 합니다. 드문 일이라 하더라도 다양한 종류의 장애를 고려해야 합니다. 시스템이 정확하고 빠르게 복구되게 하려면 의도적으로 문제를 도입해야 할 수 있습니다.

작은 정보

개념 증명의 경우 동일한 AWS 인스턴스 클래스로 Aurora 클러스터에서 모든 DB 인스턴스를 설정합니다. 이렇게 하면 장애를 시뮬레이션하기 위해 DB 인스턴스를 오프라인으로 전환할 때 성능 및 확장성에 큰 변동이 없이 Aurora 가용성 기능을 시험해 볼 수 있습니다.

각 Aurora 클러스터에서 최소 두 개의 인스턴스를 사용하는 것이 좋습니다. Aurora 클러스터의 DB 인스턴스는 최대 3개의 가용 영역(AZ)에 걸쳐 존재할 수 있습니다. 최초 2개 또는 3개의 DB 인스턴스 각각을 다른 AZ에 배치하십시오. 더 큰 규모의 클러스터를 사용하려면 해당 AWS 리전의 모든 AZ에 DB 인스턴스를 분산하십시오. 이렇게 하면 내결함 능력이 향상됩니다. 한 가지 문제가 전체 AZ에 영향을 미친다 해도 Aurora는 다른 AZ에 있는 DB 인스턴스에 장애 조치를 취할 수 있습니다. 인스턴스가 3개 이상인 클러스터를 실행하는 경우 DB 인스턴스를 세 가지 AZ 모두에 균등하게 분산하십시오.

작은 정보

Aurora 클러스터용 스토리지는 DB 인스턴스에서 독립되어 있습니다. 각 Aurora 클러스터의 스토리지는 항상 세 가지 AZ에 걸쳐 있습니다.

고가용성 기능을 테스트할 때 항상 테스트 클러스터에서 동일한 용량을 지닌 DB 인스턴스를 사용하십시오. 이를 통해 DB 인스턴스 하나가 다른 인스턴스를 인계할 때마다 성능, 지연 시간 등이 예기치 않게 변경되는 것을 방지할 수 있습니다.

장애 조건을 시뮬레이션하여 고가용성 기능을 테스트하는 방법에 대해 알아보려면 오류 삽입 쿼리를 사용하여 Amazon Aurora MySQL 테스트 단원을 참조하십시오.

개념 증명 실습의 한 가지 목표는 DB 인스턴스의 이상적 개수와 이 DB 인스턴스의 최적 인스턴스 클래스를 알아내는 것입니다. 이를 위해서는 고가용성 및 성능에 대한 요구 사항을 균형 있게 조절해야 합니다.

Aurora의 경우 클러스터에 DB 인스턴스가 많을수록 고가용성의 이점이 더 큽니다. 더 많은 DB 인스턴스를 보유하면 읽기 집약적인 애플리케이션의 확장성도 향상됩니다. Aurora는 SELECT 쿼리에 대한 여러 연결을 읽기 전용 Aurora 복제본에 배포할 수 있습니다.

한편, DB 인스턴스의 수를 제한하면 기본 노드에서 나오는 복제 트래픽이 줄어듭니다. 복제 트래픽은 전체 성능 및 확장성의 다른 속성인 네트워크 대역폭을 소비합니다. 따라서 쓰기 집약적인 OLTP 애플리케이션에 대해서는 다수의 스몰 DB 인스턴스보다는 더 적은 수의 라지 DB 인스턴스를 보유하는 것이 더 낫습니다.

일반적인 Aurora 클러스터에서는 하나의 DB 인스턴스(기본 인스턴스)가 모든 DDL 및 DML 문을 처리합니다. 기타 DB 인스턴스(Aurora 복제본)는 SELECT 문만 처리합니다. 각 DB 인스턴스가 정확히 동일한 양의 작업을 하는 것은 아니지만 클러스터에 있는 모든 DB 인스턴스에 대해 동일한 인스턴스 클래스를 사용하는 것이 좋습니다. 이로써 장애가 발생하고 Aurora가 읽기 전용 DB 인스턴스 중 하나를 새로운 기본 인스턴스로 승격시키는 경우 기본 인스턴스의 용량은 이전과 동일합니다.

동일 클러스터에서 다양한 용량을 지닌 DB 인스턴스를 사용해야 하는 경우 DB 인스턴스에 대해 장애 조치 티어를 설정하십시오. 이러한 티어로 인해 Aurora 복제본이 장애 조치 메커니즘에 의해 승격되는 순서가 결정됩니다. 다른 것보다 훨씬 더 크거나 작은 DB 인스턴스를 더 낮은 장애 조치 티어에 배치하십시오. 이로써 승격과 관련해 마지막으로 선택됩니다.

특정 시점으로 자동 복원, 수동 스냅샷 및 복원, 클러스터 역추적 등 Aurora 데이터 복구 기능을 연습합니다. 적절한 경우 스냅샷을 다른 AWS 리전에 복사하고 다른 AWS 리전으로 복원하여 DR 시나리오를 모방합니다.

RTO(복원 시간 목표), RPO(복원 시점 목표) 및 지리적 중복성에 대한 조직의 요구 사항을 조사합니다. 대부분의 조직은 재해 복구라는 넓은 범주로 이 항목들을 그룹화합니다. 재해 복구 프로세스의 맥락에서 이 단원에 설명된 Aurora 고가용성 기능을 평가하여 RTO 및 RPO 요구 사항이 충족되게 하십시오.

13. 다음에 수행할 작업

개념 증명 프로세스를 성공적으로 종료하는 시점에 예상 워크로드에 근거하여 Aurora가 적합한 솔루션이라는 것을 확인합니다. 이전 프로세스에서는 Aurora가 실제 운영 환경에서 어떻게 작동하는지 확인하고 성공 기준과 비교 측정하였습니다.

Aurora를 이용해 데이터베이스 환경을 가동하기 시작한 후에는 더 세부적인 평가 단계로 나아감으로써 최종 마이그레이션 및 프로덕션 배포까지 완료할 수 있습니다. 상황에 따라 이러한 기타 단계는 개념 증명 프로세스에 포함될 수도 포함되지 않을 수도 있습니다. 마이그레이션 및 포트 활동에 대한 자세한 내용은 AWS 백서인 Aurora 마이그레이션 핸드북을 참조하세요.

또 다른 후속 단계에서는 워크로드에 타당하고 프로덕션 환경에서 보안 요구 사항을 충족하도록 설계된 보안 구성을 고려해 보십시오. Aurora 클러스터 마스터 사용자 자격 증명에 대한 액세스 권한을 보호하기 위해 어떤 제어를 실시할지 계획하십시오. 데이터베이스 사용자의 역할 및 책임을 정의하여 Aurora 클러스터에 저장된 데이터에 대한 액세스 권한을 제어하십시오. 애플리케이션, 스크립트 및 타사 도구 또는 서비스에 대한 데이터베이스 액세스 요구 사항을 고려하십시오. AWS Secrets Manager 및 AWS Identity and Access Management(IAM) 인증과 같은 AWS 서비스 및 기능에 대해 알아보세요.

이 시점에 이르면 Aurora를 이용한 벤치마크 테스트 실행의 절차 및 모범 사례를 이해해야 합니다. 성능 튜닝을 추가로 수행할 필요가 있다는 것을 알게 될 수도 있습니다. 자세한 내용은 Aurora DB 클러스터의 성능 및 확장 관리, Amazon Aurora MySQL 성능 개선 사항, Amazon Aurora PostgreSQL 관리 및 성능 개선 도우미를 통한 Amazon Aurora 모니터링 단원을 참조하십시오. 추가 튜닝을 수행하는 경우 개념 증명 중에 수집한 지표를 숙지해야 합니다. 다음 단계를 위해 구성 설정, 데이터베이스 엔진 및 데이터베이스 버전에 대한 선택 사항이 다른 새 클러스터를 생성할 수 있습니다. 또는 특정 사용 사례의 필요에 부합하는 특별한 종류의 Aurora 클러스터를 생성할 수도 있습니다.

예를 들어 하이브리드 트랜잭션/분석적 처리(HTAP) 애플리케이션을 위한 Aurora 병렬 쿼리 클러스터를 탐색할 수 있습니다. 광범위한 지리적 분산이 재해 복구에 중요한 경우 또는 지연 시간을 최소화하고 싶은 경우 Aurora 글로벌 데이터베이스를 탐색할 수 있습니다. 워크로드가 간헐적이거나 개발/테스트 시나리오에서 Aurora를 사용 중이라면 Aurora Serverless 클러스터를 탐색할 수 있습니다.

프로덕션 클러스터는 고용량의 수신 연결을 처리해야 할 수도 있습니다. 이러한 기법에 대해 알아보려면 AWS 백서인 Aurora MySQL 데이터베이스 관리자용 핸드북 – 연결 관리를 참조하세요.

개념 증명을 마친 후 사용 사례가 Aurora에 적합하지 않다고 판단되면 다른 AWS 서비스를 고려합니다.

  • 순전히 분석적인 사용 사례의 경우 워크로드에는 OLAP 워크로드에 더 적합한 열 기반 스토리지 형식 및 기타 기능이 도움이 됩니다. 이러한 사용 사례에 대처할 수 있는 AWS 서비스는 다음과 같습니다.

  • Aurora와 이 서비스 중 한 개 이상을 조합하면 많은 워크로드에서 그 이점을 활용할 수 있습니다. 다음 기능을 이용해 이러한 서비스 간에 데이터를 이동할 수 있습니다.