Amazon Web Services 한국 블로그
Amazon RDS 및 Amazon Aurora를 Graviton2 기반 인스턴스로 이전 시 고려 사항
Amazon Relational Database Service (Amazon RDS) 및 Amazon Aurora 는 필요에 따라 데이터베이스 워크로드를 확장 할 수 있도록 다양한 인스턴스 유형을 지원합니다. (Amazon RDS DB 인스턴스 클래스 및 Aurora DB 인스턴스 클래스 참조 ). 2020 년에 AWS는 AWS Graviton2 x86 대응 제품에 비해 더 나은 비용 성능 비율을 제공하는 프로세서로서 Amazon RDS용 M6g 및 R6g 인스턴스 유형을 발표했으며, 최근 Aurora 용 R6g 인스턴스 유형을 정식 발표했습니다.Graviton2 프로세서는 64 비트 Arm Neoverse 코어를 사용하여 AWS에서 맞춤형으로 구축되었으며 Graviton2 M6g 및 R6g 데이터베이스 인스턴스를 시작할 수 있습니다. Amazon RDS 콘솔 또는 AWS 명령 줄 인터페이스 (AWS CLI)을 통해 다운 타임을 최소화하면서 다중 AZ 데이터베이스를 Graviton2로 이동하여 장애 조치 기간 동안 I/O를 일시 중단 할 수 있습니다.이 글에서는 기존 Amazon RDS 및 Aurora DB 인스턴스를 Graviton2 기반 인스턴스 유형으로 이전할 때, 주요 고려 사항에 대해 설명합니다. 다운 타임을 줄이기 위해 취할 수 있는 전제 조건과 다양한 전략에 대해 논의합니다.
Graviton2 기반으로 이동하는 이유
다음은 Amazon RDS 및 Amazon Aurora 용 Graviton2로 이동하는 몇 가지 이유입니다.
- Graviton2 인스턴스는 최대 52 %의 가격 / 성능 향상을 제공합니다. 데이터베이스 엔진, 버전 및 워크로드에 따라 RDS 오픈 소스 데이터베이스에 대해 최대 35 %의 가격 / 성능 향상을 제공합니다.
- Graviton2 프로세서는 항상 켜져 있는 완전 암호화 된 DDR4 메모리와 코어 당 50 % 더 빠른 암호화 성능을 제공합니다.
- Graviton2 인스턴스로 마이그레이션 할 때 코드 변경이 필요하지 않습니다.
솔루션 개요
이 글에서는 PostgreSQL 버전 9.6.16의 다중 AZ Aurora 데이터베이스 클러스터에 3 개의 인스턴스 (마스터 1 개와 리플리카 2 개)가있는 사용 사례를 고려해 보겠습니다.
일반적으로 먼저 비 프로덕션 환경에서 프로세스를 테스트하는 것이 좋습니다. 프로덕션 데이터베이스의 스냅 샷을 사용하고 현재 프로덕션 인스턴스와 유사한 구성 (인스턴스 클래스, 파라미터 그룹 설정, 암호화)이 있는 비 프로덕션 환경의 인스턴스로 복원하여 시작할 수 있습니다. 그런 다음 비 프로덕션 인스턴스를 Graviton2로 수정 한 다음 유효성 검사 테스트를 통해 모든 것이 예상대로 구성되고 작동하는지 확인합니다.
프로세스의 개략적 인 단계는 다음과 같습니다.
- 데이터베이스 업그레이드 (필요한 경우)
- 현재 데이터베이스 버전이 Graviton2로 이동하는 데 필요한 최소 버전을 충족하는지 확인합니다.
- 데이터베이스 엔진을 필요한 최소 버전으로 업그레이드하세요.
- 인스턴스 유형을 수정합니다.
- 전략과 인스턴스 수정 순서를 결정합니다.
- 인스턴스의 인스턴스 클래스를 적절한 Graviton2 인스턴스로 수정합니다.
- 애플리케이션이 올바르게 작동하는지 확인하고 확인합니다.
- 롤백 (필요한 경우).
데이터베이스 업그레이드하기
현재 데이터베이스 버전이 Graviton2로 이동하는 데 필요한 최소 버전을 충족하지 않는 경우에만 필요하므로 데이터베이스 버전을 업그레이드 해야 하는지 결정하는 것으로 시작합니다.
데이터베이스 버전 확인
다음 표는이 게시물에서 Graviton2에 대해 지원되는 버전을 보여줍니다. Graviton2와 호환되도록 컴파일 또는 개발 및 테스트 된 데이터베이스 버전입니다.
| MySQL | PostgreSQL | MariaDB | |
|---|---|---|---|
| Amazon RDS | 8.0.17 이상 | 13, 12.3 이상 | 10.5 및 10.4.13 이상 |
| Amazon Aurora | 2.09.2 이상 | 12.4 이상 및 버전 11.9 이상 | —- |
이 게시물의 사용 사례에서는 Graviton2로 이동하는 데 필요한 버전보다 낮은 Aurora PostgreSQL 버전 9.6.16을 사용합니다.
이 정보의 최신 업데이트는 DB 인스턴스 클래스 용으로 지원되는 DB 엔진 (Amazon RDS) 및 DB 인스턴스 클래스 용으로 지원되는 DB 엔진 (Aurora)을 참조하십시오.
데이터베이스가 Graviton2에서 지원하는 버전이 아닌 경우 지원되는 버전으로 업그레이드해야합니다. 현재 소스 버전에 유효한 모든 업그레이드 대상 목록을 가져 오려면 describe-db-engine-versions CLI 명령을 사용합니다.
Linux, macOS 또는 Unix의 경우 다음 코드를 사용합니다.
Windows의 경우 다음 코드를 사용하십시오.
다음 스크린 샷은 Linux 기반 운영 체제에서 이전 명령의 출력을 보여줍니다.
만약 IsMajorVersionUpgrade 값이 true이면, EngineVersion 버전으로 메이저 버전 업그레이드를 수행 할 수 있습니다. 어레이가 비어 있으면 메이저 버전 업그레이드를 수행 할 수 없습니다. 먼저 주 버전 업그레이드 경로가 있는 부 버전으로 업그레이드 해야 합니다.
필요한 최소 버전으로 데이터베이스 업그레이드
경우에 따라 현재 데이터베이스 버전에서 Graviton2에서 지원하는 최소 데이터베이스 버전으로의 직접 업그레이드 경로가 없는 경우가 있습니다. (이 게시물의 사용 사례의 경우 Aurora PostgreSQL 버전 9.6.16이고 Graviton2에 대해 지원되는 최소 버전은 11.9입니다.) 9.6에서 11.9 로의 직접 업그레이드 경로가 없으므로 먼저 9.6.16에서 10.14로 업그레이드 한 다음 11.9로 업그레이드 해야 합니다.
Amazon RDS의 경우 다음 단계에 따라 데이터베이스 엔진 버전을 업그레이드 할 수 있습니다.
Aurora의 경우 다음 단계에 따라 데이터베이스 엔진 버전을 업그레이드 할 수 있습니다.
업그레이드하는 동안 다운 타임이 필요한 인플레이스 업그레이드를 수행 할 수 있습니다. 가동 중지 시간을 최소화하려는 경우 AWS Database Migration Service (AWS DMS)를 사용하는 다른 접근 방식을 따를 수 있습니다 . 자세한 내용은 문서를 참조하세요.
인스턴스 수정
인스턴스를 수정하려면 다음 상위 수준 단계를 완료합니다.
- 이전 전략과 인스턴스 수정 순서를 결정합니다.
- 인스턴스 클래스를 적절한 Graviton2 인스턴스로 수정합니다.
이전 전략 결정
인스턴스 유형을 수정하기 위해 선택하는 전략은 다중 AZ 또는 읽기 전용 복제본과 같은 구성에 따라 다릅니다.
다중 AZ가있는 Amazon RDS의 경우 모든 인스턴스 수정이 보조 인스턴스에서 수행 된 후 장애 조치가 수행됩니다. 그런 다음 새 보조 (이전 기본) 인스턴스에서 수정 단계가 반복됩니다. 계획된 다운 타임 기간은 장애 조치 시간으로만 제한됩니다. 장애 조치 시간은 일반적으로 60~120 초입니다. 인스턴스 유형 수정 중에는 단일 AZ 인스턴스를 사용할 수 없습니다.
Aurora 복제본이 하나 이상 있는 Aurora의 경우 마스터 인스턴스를 수정하면 Aurora 복제본이 기본 인스턴스로 승격되고 수정은 새 Aurora 복제본 (이전 마스터)에서 계속됩니다. (일반적으로 120 초 미만의 짧은 중단이 있습니다.) 가동 중지 시간과 위험을 최소화하기 위해 먼저 Aurora 복제본에서 인스턴스를 수정하고 예상대로 작동하는지 확인한 다음 현재 Graviton2 리더로 장애 조치 할 수 있습니다. Aurora 클러스터 내에서 사용 사례에 적합한 순서로 인스턴스를 Graviton2로 수정할 수 있습니다.
또한, 기본(Primary) 인스턴스 또는 읽기 전용 복제본에 대해 동일한 클러스터 내에서 Graviton2 R6g 및 Intel R5 인스턴스를 혼합하고 일치시킬 수 있으므로 워크로드 요구 사항에 따라 가격/성능 향상을 극대화 할 수 있습니다.
인스턴스 유형 변경은 인스턴스를 다른 하드웨어 호스트로 재배치하는 것을 의미하며, 이는 버퍼 캐시가 유지되지 않음을 의미합니다. 따라서 수정 된 인스턴스의 데이터베이스가 다시 시작되면 버퍼 캐시가 콜드되고 초기 쿼리가 더 오래 걸릴 수 있습니다.
일반적인 모범 사례로 쉽게 롤백할 수 있도록 수정하기 전에 수동 스냅 샷을 생성 할 수 있습니다. 단일 AZ 설정의 Amazon RDS의 경우 이로 인해 스냅샷 시간 동안 크기에 따라 몇 초에서 몇 분까지 I/O가 일시 중단됩니다. 다중 AZ 구성에서는 스냅샷 작업 중 I/O 일시 중단이 없습니다. Aurora의 경우 성능 영향이나 데이터베이스 서비스 중단이 발생하지 않습니다.
일정에 따라 Amazon RDS 유지 관리 기간 동안 변경을 계획하는 것이 좋습니다. 이 유지 관리 기간은 시스템 변경 사항이 적용되는 주간 유지 관리 기간입니다. 유지 관리 기간은 요청되거나 필요한 경우 수정 및 소프트웨어 패치가 발생하는 시기를 제어 할 수 있는 기회로 생각할 수 있습니다.
이 게시물의 사용 사례에서는 Aurora 읽기 인스턴스 하나를 Graviton2로 이동 한 다음 유효성 검사를 실행하여 올바르게 작동하는지 확인합니다. 읽기 인스턴스 유형을 Graviton2로 수정 한 다음, 이 새로운 Graviton2 읽기 인스턴스로 장애 조치 및 쓰기 인스턴스로 승격합니다. 장애 조치 프로세스를 완료하는 데 몇 초 정도 걸립니다.
인스턴스 클래스 수정
Amazon RDS 콘솔에 로그인하여 시작합니다. 계획대로 먼저 읽기 전용 복제본의 인스턴스 클래스를 수정합니다.
-
- Amazon RDS 콘솔의 탐색 창에서 데이터베이스를 선택합니다.
- 읽기 인스턴스를 선택합니다 (이 게시물에서는
auroralab-pgsql-node-3)을 선택하고 수정을 선택합니다.
- DB 인스턴스 클래스 크기에 대해서는 메모리 최적화 클래스를 선택합니다.
- 인스턴스 클래스를 선택하십시오. 여기서는 db.r6g.large를 선택합니다. (“g”는 Graviton2를 나타냄).
- 계속을 선택합니다.
- 요약 페이지에서 변경 사항을 검토하세요.
- 변경 사항을 즉시 적용하려면 즉시 적용을 선택합니다. 변경 사항을 즉시 적용하지 않으면 사용자가 정의한 기본 유지 관리 기간 동안 변경 사항이 발생하도록 예약됩니다. 선택하면 즉시 적용을 경우에 따라 중단이 발생할 수 있습니다.
- DB 인스턴스 수정을 선택합니다.
다음 스크린 샷은 수정중인 인스턴스를 보여줍니다.
이 글의 사용 사례에서는 읽기 전용 복제본 인스턴스의 수정 시간은 몇 분이 걸렸습니다. 이 인스턴스가 수정되는 동안 쓰기 인스턴스와 다른 읽기 인스턴스가 열려 애플리케이션 요청을 처리합니다. 데이터 세트의 크기 또는 데이터베이스의 암호화 상태가 인스턴스 클래스 수정에 필요한 시간에 영향을 주지 않는 것으로 나타났습니다.
다음 스크린 샷은 하나의 쓰기 및 읽기 db.r5 large (x86)에 있고 하나의 읽기는 db.r6g.large (Graviton2) 인스턴스로 구동되고 있음을 보여줍니다.
이제 새 db.r6g.large 읽기 인스턴스를 쓰기로 변경 합니다. 각 읽기 전용 복제본은 우선 순위 계층과 연결됩니다. 장애 조치가 발생할 경우, Amazon RDS는 우선 순위가 가장 높은 읽기 전용 복제본 (가장 낮은 번호의 계층)을 승격합니다. 두 개 이상의 복제본의 우선 순위가 동일한 경우 Amazon RDS는 이전 기본 인스턴스와 동일한 크기의 복제본을 승격합니다. 장애 조치하기 전에 db.r6g.large 읽기 복제분의 장애 조치 우선 순위가 다른 복제본보다 높은지 확인해야합니다. 기본적으로 둘 다 Tier-1에 있으므로 auroralab-pgsql-node-2를 열고 구성을 Tier-2로 변경하세요.
auroralab-pgsql-node-2인스턴스를 선택하고 수정을 선택합니다.- 장애 조치 우선 순위를 Tier-2로 선택합니다.
- 계속을 선택합니다.
- DB 인스턴스 수정을 선택합니다 .
장애 조치 수행
auroralab-pgsql-node-1인스턴스를 선택하고, 동작 메뉴에서 장애 조치를 선택합니다.
DB 엔드 포인트 대신 클러스터 엔드 포인트 (권장)를 사용하여 연결하고, 재시도 논리를 구현하는 경우 애플리케이션은 서비스 중단을 최소화합니다. 장애 조치 중에 AWS는 새로 생성되거나 승격 된 DB 인스턴스를 가리키도록 클러스터 엔드 포인트 DNS를 수정합니다. 변경 후 Graviton2에서 실행중인 쓰기 인스턴스가 보입니다.
서비스 중단을 최소화하고 애플리케이션의 탄력성을 높이기 위해 Amazon RDS Proxy를 사용할 수도 있습니다 장애 조치 시간을 더 줄이기 위해 적극적인 TCP 연결 유지 설정 및 JDBC 연결 설정을 구성하거나 PGConn응용 프로그램 수준에서 클래스. 자세한 내용은 Amazon Aurora PostgreSQL 모범 사례를 참조하십시오
애플리케이션 동작 확인
이제 애플리케이션이 Graviton2 기반 RDS 또는 Aurora 데이터베이스에서 올바르게 작동하는지 확인할 수 있습니다. RDS 성능 인사이트 활성화하면, 데이터베이스 부하를 시각화하고, 실행 시간이 높은 SQL 문, 늦은 호스트, 또는 사용자 부하를 필터링해 주는 성능 통찰력 대시 보드를 사용할 수 있습니다.
테스트 기간 (아마 며칠 또는 사용자의 편안함 수준에 따라) 후에 나머지 읽기 인스턴스를 Graviton2로 변경하고 변경 전에 생성 된 스냅샷을 삭제할 수 있습니다.
롤백
기존에 변경 사항이있거나, 새로운 변경 사항이 예상대로 작동하지 않는 경우 대체 전략을 세우는 것이 중요합니다. 일반적으로 몇 가지 옵션이 있습니다.
- x86 읽기 인스턴스가있는 경우 장애 조치 우선 순위를 변경하여 클러스터의 x86 인스턴스로 장애 조치 할 수 있습니다.
- 앞부분에서 보았던 유사한 프로세스에 따라 인스턴스 유형을 x86 인스턴스 유형으로 다시 변경할 수도 있습니다.
- 여전히 문제가 발생하면 변경을 시작하기 전에 찍은 스냅 샷에서 복원 할 수 있습니다. Amazon RDS 또는 Aurora 사용시 추가 고려 사항에 대한 자세한 내용은 DB 스냅샷 복원을 참조하십시오
(롤백 절차는 그 자체로 별도의 주제이며, 이 글의 범위를 벗어납니다.)
요약
이 글에서는 가동 중지 시간을 최소화하기위한 몇 가지 주요 고려 사항과 함께 Aurora PostgreSQL 인스턴스를 Graviton2로 수정하는 단계별 지침을 제공했습니다. 유사한 단계에 따라 RDS 인스턴스를 Graviton2로 수정할 수 있습니다. Graviton2에 필요한 최소 버전이 아닌 경우 데이터베이스 업그레이드 프로세스에 대해서도 간략히 설명했습니다.
모범 사례로, 보유하고있을 수있는 데이터베이스 확장을 포함하여 낮은 환경에서 변경 사항을 항상 테스트하고 테스트 환경이 구성 및 볼륨 측면에서 프로덕션 환경과 유사한 지 확인하십시오.
Reagan Rosario 는 AWS에서 EdTech에 중점을 둔 솔루션 아키텍트로 일하고 있습니다. 그는 고객이 AWS 클라우드에서 확장 가능하고 가용성이 높으며 안전한 솔루션을 구축하도록 돕는 것을 좋아합니다.
Tyler Lynch 는 AWS의 EdTech에 주력하는 선임 솔루션 아키텍트입니다. 그는 교육과 평생 학습에 열정적입니다.
이 글은 AWS Database 블로그의 Key considerations in moving to Graviton2 for Amazon RDS and Amazon Aurora databases 한국어 번역본입니다.