Amazon Aurora MySQL 버전 3으로 업그레이드 (MySQL 8.0 호환)

이 글은 AWS Database Delivery Blog에 게시된 Upgrade to Amazon Aurora MySQL version 3 (with MySQL 8.0 compatibility) by Shagun Arora, Isael Pimentel, Aditi Sharma, and Dilip Simha 을 한국어 번역 및 편집하였습니다.

Amazon Aurora MySQL-Compatible Edition 버전 3 (MySQL 8.0 호환)은 Amazon Aurora MySQL에서 지원되는 최신 메이저 버전입니다. Amazon Aurora MySQL 버전 3을 사용하면 최신 MySQL 호환 기능과 성능 향상을 얻을 수 있습니다. MySQL 8.0에는 JSON 함수, Windows 함수, 공통 테이블 표현식(CTE) 및 역할 기반 권한을 포함한 여러 가지 새로운 기능이 도입되었습니다. Amazon Aurora MySQL 3에는 Amazon Aurora Serverless v2, Amazon Aurora zero-ETL, AWS Graviton3 지원, 향상된 바이너리 로그 및 Amazon Aurora I/O-Optimized와 같은 새로운 기능에 대한 지원도 포함되어 있습니다. 전체 기능 목록은 MySQL 8.0과 호환되는 Aurora MySQL 버전 3 을 참조하세요.

Amazon Aurora MySQL의 새로운 메이저 버전이 출시되면 DB 클러스터를 업그레이드할 방법과 시기를 선택할 수 있습니다. 주요 엔진 버전 업그레이드로 인해 기존 애플리케이션과 이전 버전과 호환되지 않는 변경 사항이 발생할 수 있습니다. 따라서 데이터베이스 버전을 업그레이드하고 이점을 극대화하려면 일반적인 과제와 모범 사례를 알고 있는 것이 중요합니다.

이 게시물에서는 업그레이드를 준비하면서 시작해야 할 프레임워크에 대해 논의하고 표준 지원 일정 종료를 검토한 후 업그레이드 프로세스에 대해 자세히 설명합니다. Aurora 업그레이드 사전 확인부터 시작하여, 전체 단계 및 Aurora MySQL 클러스터 수정을 수행하는 데 사용할 수 있는 다양한 옵션을 살펴보세요. 또한 이 게시물에서는 프로덕션 데이터베이스 클러스터를 업그레이드하기 전 성능 테스트에 대한 모범 사례, 변경 사항을 모니터링하는 기술 및 기타 주요 고려 사항에 대해 설명합니다.

메이저 버전 업그레이드 준비

주요 버전 업그레이드를 계획하는 동안 데이터베이스 및 애플리케이션 기능이 예상대로 유지되는지 확인하기 위해 일련의 테스트 및 검증 단계를 정의하는 것부터 시작할 수 있습니다. 주요 버전 업그레이드를 위한 요구 사항과 성공 기준을 마련할 때 이 주제를 더 작은 목표로 나누는 것이 도움이 될 수 있습니다. 다음은 계획에 구성을 위한 몇 가지 주요 초점 영역입니다.

호환성 – 업그레이드를 통해 클라이언트 응용 프로그램이 올바르게 작동하는지 확인합니다. 애플리케이션이 예상대로 계속 작동하려면 특정 방식으로 존재하거나 작동해야 하는 플랫폼, 데이터베이스 및 쿼리 수준의 기능을 확인하세요. 프로덕션에서 업그레이드하기 전에 업그레이드 프로세스를 테스트하여 호환성 문제를 확인하세요. 테스트 방법은 업그레이드하기 전에 새 Aurora 버전으로 DB 클러스터 테스트 를 참조하세요.
성능 – 프로덕션 데이터베이스를 업그레이드하기 전 성능 테스트에는 적절한 애플리케이션 성능을 유지하고 예상되는 개선 사항을 확인하는 것이 포함됩니다. 이 게시물에서는 MySQL 5.7과 MySQL 8.0 간의 변경으로 인해 차이가 발생할 수 있으므로 쿼리 성능을 테스트하기 위한 권장 사항과 도구에 대해 논의합니다.
가용성 – 가용성에는 두 가지 주요 측면이 있습니다. 첫 번째는 애플리케이션 가동 중지 시간을 최소한으로 유지하는 것이고, 두 번째는 문제가 발생할 경우를 대비한 대체 옵션을 갖는 것입니다. 허용 가능한 가동 중지 시간과 업그레이드 프로세스에 대한 제어 수준에 따라 이 게시물에서 설명하는 여러 업그레이드 옵션 중에서 선택할 수 있습니다.
노력 – 주요 버전 업그레이드를 준비하는 동안 프로덕션 환경을 변경하기 전에 비프로덕션 환경에서 업그레이드를 계획하고 테스트하는 데 필요한 엔지니어링 노력을 측정해야 할 수도 있습니다. 준비 단계를 수행하는 데 드는 비용과 노력을 평가할 때마다 해당 작업을 다른 곳에서 재사용할 수 있는지 고려하세요. 좋은 변경 관리 절차를 만드는 데 투자한다면 다른 상황에서도 해당 작업을 재사용할 수 있습니다.

업그레이드 일정

Amazon Aurora MySQL 버전 2 (MySQL 5.7 호환)는 2024년 10월 31일에 표준 지원이 종료됩니다. 자세한 지침은 Amazon Aurora MySQL 호환 버전 2 표준 지원 종료 준비 를 참조하세요.

표준 지원 일정 종료

표준 지원 일정이 끝나면 다음 주요 날짜를 참고하세요.

현재부터 2024년 10월 31일 까지 – Amazon Aurora MySQL 버전 2(MySQL 5.7 호환)에서 Amazon Aurora MySQL 버전 3 (MySQL 8.0 호환)으로 클러스터를 업그레이드할 수 있습니다.
2024년 10월 31일 – 현재 Aurora MySQL 버전 2의 표준 지원이 종료됩니다. Aurora 또는 RDS의 표준 지원 종료 날짜 이후 최대 3년 동안 기존 버전을 계속 사용하려면 Amazon RDS 확장 지원 을 선택하면 됩니다.

Amazon RDS 확장 지원

2023년 9월, AWS는 Amazon Relational Database Service (Amazon RDS)가 Aurora 이후 최대 3년 동안 Amazon Aurora MySQL 또는 Amazon RDS for MySQL 메이저 버전에 대한 중요한 보안 및 버그 수정을 제공하는 유료 서비스인 Amazon RDS Extended Support 를 발표했습니다. 또는 RDS 표준 지원 종료 날짜. 자세한 내용은 Amazon Aurora의 MySQL 데이터베이스에 대한 Amazon RDS 확장 지원 소개 및 Aurora 가격 의 Amazon RDS 및 Amazon RDS 확장 지원 비용을 참조하세요.

Aurora 버전의 출시 날짜 및 지원 종료 날짜 업데이트 타임라인에 대한 자세한 내용은 Amazon Aurora 메이저 버전 및 Amazon Aurora 마이너 버전 을 참조하세요.

대상 버전 선택

기존 Aurora MySQL 2 클러스터를 Amazon Aurora MySQL 3으로 업그레이드하기로 결정하면 업그레이드 대상 버전으로 선택할 수 있는 마이너 버전이 여러 개 있다는 것을 알 수 있습니다. 이 게시물을 작성하는 현재 최신 Amazon Aurora MySQL 버전은 커뮤니티 MySQL 8.0.32와 호환되는 Amazon Aurora MySQL 3.05입니다. Aurora MySQL 3은 Aurora MySQL 3.04 (MySQL 8.0.28과 호환 가능) 마이너 버전인 LTS (장기 지원) 버전도 지원합니다. LTS 릴리스를 사용하는 데이터베이스 클러스터는 해당 릴리스가 출시된 후 최소 3년 동안 동일한 마이너 버전을 유지할 수 있으므로 클러스터의 업그레이드 주기가 줄어듭니다. Aurora MySQL 3으로 업그레이드하는 동안 LTS 릴리스를 사용하는 대신 최신 기본 마이너 버전으로 업그레이드하여 최신 기능과 버그 수정에 액세스하는 것이 좋습니다. 각 버전의 기능과 개선 사항을 설명하는 Amazon Aurora MySQL 3 릴리스 정보는 Amazon Aurora MySQL 버전 3용 데이터베이스 엔진 업데이트를 참조하세요.

Amazon Aurora MySQL 3 업그레이드 사전 확인

데이터베이스 엔진의 주요 버전을 업그레이드할 때 새 버전과 해당 기능이 기존 애플리케이션과 호환되는지 확인하는 것은 업그레이드의 전반적인 성공에 중요한 역할을 합니다. MySQL 데이터베이스 버전과 릴리스는 작동 방식과 애플리케이션과의 상호 작용 방식이 다를 수 있으며, 이로 인해 애플리케이션 동작이 변경될 수 있습니다.

MySQL 8.0에는 MySQL 5.7과 비교하여 많은 변경 사항이 포함되어 있습니다. 예를 들어 이전에 예약되지 않았던 일부 키워드 가 MySQL 8.0에서는 예약 키워드가 될 수 있으며(예: RANGE) MySQL 8.0에서는 일부 기능 (예: 쿼리 캐시)이 제거될 수 있습니다. 업그레이드 중에 이러한 차이점을 해결해야 할 수도 있습니다. 모범 사례로서 MySQL 8.0의 새로운 기능 을 면밀히 검토하여 모든 변경 사항을 참조하고 워크로드에 적용되는지 확인하는 것이 좋습니다. 특히 Amazon Aurora MySQL의 경우 Aurora MySQL 버전 2와 Aurora MySQL 버전 3 비교 를 검토하여 업그레이드 시 변경 사항에 대해 알아볼 수도 있습니다.

AWS Management Console 또는 AWS 명령줄 인터페이스 (AWS CLI)에서 Aurora MySQL 2에서 Aurora MySQL 3으로의 업그레이드를 시작하면 Aurora는 백그라운드에서 자동으로 사전 확인을 실행하여 비호환성을 감지합니다. 이러한 사전 확인은 필수이며 건너뛸 수 없습니다. 여기에는 커뮤니티 MySQL에 포함된 일부 검사와 Aurora에서 도입된 일부 검사가 포함됩니다. 자세한 내용은 Aurora MySQL에 대한 메이저 버전 업그레이드 사전 확인 을 참조하세요. 사전 확인은 업그레이드를 위해 DB 인스턴스가 중지되기 전에 실행됩니다. 즉, 사전 확인이 실행되는 동안 가동 중지 시간이 발생하지 않습니다. 사전 확인에서 비호환성이 발견되면 Aurora는 데이터베이스 가동 중지 없이 자동으로 업그레이드를 취소하고 원래 5.7 버전 호환 Writer 인스턴스는 변경되지 않습니다.

그런 다음 Aurora는 Amazon RDS 콘솔의 로그 및 이벤트 섹션에서 비호환성에 대한 이벤트를 생성하고 비호환성은 upgrade-prechecks.log 파일에도 보고됩니다. 0이 아닌 errorCount는 업그레이드가 성공하지 못했음을 나타냅니다. 대부분의 경우 로그 항목에는 문제 해결을 위한 MySQL 설명서 링크가 포함되어 있습니다. 성공적인 업그레이드를 방해할 수 있는 샘플 시나리오와 그 해결 방법은 Aurora MySQL 버전 3의 업그레이드 문제 해결에 설명되어 있습니다. Amazon RDS 콘솔의 로그 및 이벤트 섹션에서 upgrade-prechecks.log를 찾을 수 있습니다. aws rds describe-db-log-files 다음에 aws rds download-db-log-file-portion을 사용하여 AWS CLI를 사용할 수도 있습니다.

업그레이드를 시작하기 전에 커뮤니티 버전 MySQL 사전 검사기 도구 를 사용하여 임시 테스트를 실행하여 기존 Aurora MySQL 데이터베이스를 분석하고 대부분의 잠재적인 업그레이드 문제를 식별할 수도 있습니다.

가장 좋은 방법은 프로덕션 환경에서 업그레이드하기 전에 업그레이드 프로세스를 테스트하는 것입니다. 테스트 방법은 업그레이드하기 전에 새 Aurora 버전으로 DB 클러스터 테스트 를 참조하세요. 이러한 테스트를 수행하면 Aurora 사전 확인 로그 파일을 사용하여 업그레이드 비호환성(있는 경우)이 제공될 뿐만 아니라 사전 확인을 실행하는 데 걸리는 시간과 전체 업그레이드 기간에 대한 추정도 제공됩니다. 업그레이드 기간은 작업 부하와 데이터베이스 개체 수에 따라 달라질 수 있습니다.

마지막으로 Aurora 사전 확인은 프로시저 정의의 예약어와 같은 데이터베이스 객체의 비호환성을 확인합니다. 애플리케이션 측 논리의 유효성을 검사하지 않습니다. 따라서 예약된 키워드나 지원되지 않는 구문이 애플리케이션에 어떤 영향을 미칠 수 있는지 확인해야 합니다. 업그레이드하기 전에 모든 기능적 측면이 새 버전에서 올바르게 작동하는지 확인하기 위해 애플리케이션을 철저히 테스트하는 것이 좋습니다.

업그레이드 프로세스

Amazon Aurora MySQL은 다음 순서도에 표시된 것처럼 여러 단계의 프로세스로 메이저 버전 업그레이드를 수행합니다.

버전 2.x의 Aurora MySQL 클러스터에서 업그레이드를 시작하면 Aurora는 먼저 사전 확인을 수행하여 앞서 설명한 대로 대상 버전과의 호환성 문제를 찾습니다. 그런 다음 업그레이드에 문제가 있는 경우 롤백하는 데 사용할 수 있는 업그레이드 전 스냅샷 생성을 진행합니다. 그런 다음 데이터베이스가 다시 시작되고 데이터베이스에 장기 실행 트랜잭션이 있거나 기록 길이가 긴 경우 이 단계에서 Undo 로그 가 제거됩니다. MySQL 8에는 데이터 딕셔너리 의 새로운 구현이 도입되었기 때문에 데이터베이스 객체는 변경 사항에 따라 변환되고 클러스터의 writer 인스턴스가 먼저 업그레이드된 다음 reader 인스턴스가 업그레이드됩니다. 자세한 내용은 데이터 딕셔너리가 업그레이드되는 방식 및 Aurora MySQL in-place 메이저 버전 업그레이드가 작동하는 방식을 참조하세요.

Amazon Aurora MySQL의 메이저 버전 업그레이드 수행

이제 배경 자료를 검토했으므로 클러스터의 메이저 버전을 Amazon Aurora MySQL 3으로 업그레이드하는 단계에 대해 논의하겠습니다. Amazon Aurora MySQL을 사용하면 콘솔, AWS CLI 또는 Amazon RDS API를 통해 DB 클러스터를 수정하여 수동으로 메이저 버전 업그레이드를 시작할 수 있습니다. 업그레이드 작업을 수행하려면 업그레이드가 진행되는 동안 애플리케이션에 대한 가동 중지 시간이 필요합니다. Aurora는 전체 클러스터의 엔진 버전을 업그레이드합니다. 따라서 업그레이드는 라이터 및 리더 DB 인스턴스에서 동시에 수행됩니다. 가장 좋은 방법은 롤백 계획을 세우기 위해 업그레이드를 시작하기 전에 수동 스냅샷을 생성하는 것입니다. 이 섹션에서는 다음과 같은 업그레이드 옵션을 간단한 순서대로 다룹니다.

In-place 업그레이드
Amazon RDS 블루/그린 배포
스냅샷 복원 및 Aurora clone 복제

In-place 업그레이드

이는 클러스터 자체에서 업그레이드 프로세스를 실행할 수 있는 가장 간단한 옵션입니다. 새 클러스터가 생성되지는 않습니다. 이 기술은 모든 데이터를 새 클러스터 볼륨에 복사할 필요가 없기 때문에 동일한 클러스터 엔드포인트와 클러스터의 기타 특성을 유지합니다. Aurora가 in-place 업그레이드를 수행하는 동안 클러스터는 가동 중지 시간을 관찰합니다. 한 가지 염두에 두어야 할 점은 업그레이드 프로세스는 업그레이드 중에 취소할 수 없으며 업그레이드가 성공하거나 실패할 때까지 실행된다는 것입니다. 업그레이드 프로세스 중에 문제가 발생할 경우 Aurora는 변경 사항 롤백을 시도합니다. 자세한 내용은 Aurora MySQL in-place 메이저 버전 업그레이드 작동 방식 을 참조하세요.

이 옵션은 프로덕션 환경을 업그레이드하는 데 사용할 수 있지만 업그레이드 기간 동안 가동 중지 시간이 필요합니다. 이 옵션은 설정이 간단하므로 프로덕션에서 업그레이드 프로세스를 수행하기 전에 업그레이드 프로세스를 테스트하는 데 사용할 수도 있습니다. In-place 업그레이드를 수행하는 전체 단계는 in-place 업그레이드를 수행하는 방법 을 참조하세요. 문제 해결 팁은 Aurora MySQL in-place 업그레이드 문제 해결 을 참조하십시오.

Amazon RDS 블루/그린 배포

업그레이드 중에 데이터베이스의 가동 중지 시간을 최소화하는 것이 최우선 과제인 경우 업그레이드된 이전 클러스터와 새 클러스터를 나란히 실행하는 관리형 프로세스를 사용할 수 있습니다. Amazon RDS 블루/그린 배포 를 사용하면 새 클러스터가 인계받을 준비가 될 때까지 이전 클러스터에서 새 클러스터로 데이터를 복제합니다. 가동 중지 시간을 최소화하고 업그레이드 위험을 낮추기 위해 데이터베이스 클러스터를 업그레이드하는 동안 이 기능을 사용할 수 있습니다. 블루/그린 배포는 현재 프로덕션 환경(블루 환경)과 스테이징 환경(그린 환경)이라는 두 가지 데이터베이스 환경으로 구성됩니다. 이는 MySQL 바이너리 로그 복제를 사용하여 동기화 상태로 유지됩니다. 따라서 Aurora MySQL DB 클러스터에 대한 블루/그린 배포를 생성하기 전에 클러스터는 바이너리 로깅 (binlog_format)이 활성화된 사용자 지정 DB 클러스터 파라미터 그룹과 연결되어야 합니다. 아직 활성화되지 않은 경우 이 변경을 수행하려면 블루 클러스터를 다시 시작해야 합니다. 블루/그린 배포를 생성하는 단계는 블루/그린 배포 생성 을 참조하세요.

블루 환경에 영향을 주지 않고 메이저 또는 마이너 DB 엔진 버전을 업그레이드하는 등 그린 환경에서 변경할 수 있습니다. 그린 환경에서 업그레이드를 테스트한 후 전환을 수행하여 그린 환경을 승격할 수 있습니다. 30-3,600초(1시간) 사이에서 전환 시간 초과를 지정할 수 있습니다. 전환이 성공한 후 Amazon RDS는 애플리케이션 변경이 필요하지 않도록 블루 환경의 해당 엔드포인트와 일치하도록 그린 환경의 엔드포인트 이름을 바꿉니다. 성공적인 전환을 확인하려면 블루/그린 배포 모범 사례 를 참조하세요. 자세한 단계가 포함된 데모를 보려면 RDS 블루/그린 배포를 통해 Amazon Aurora MySQL 버전 3으로 업그레이드 를 참조하세요.

스냅샷 복원 및 Aurora Clone 복제

업그레이드 중 가동 중지 시간을 더 잘 견딜 수 있는 개발/테스트 환경 업그레이드와 같은 사용 사례의 경우 스냅샷 복원 또는 Aurora clone 복제를 사용할 수 있습니다. 이는 데이터베이스 성능 및 애플리케이션 호환성 측면에서 주요 버전 업그레이드를 테스트하기 위한 테스트 환경을 만들 때 도움이 되는 경우가 많습니다.

업그레이드하려는 클러스터의 수동 스냅샷을 생성 하는 것부터 시작합니다. 스냅샷을 생성하기 전에 현재 클러스터에서 쓰기 워크로드를 중지하기로 결정할 수 있습니다. 그런 다음 스냅샷에서 복원 할 수 있으며 복원하는 동안 업그레이드하려는 대상 엔진 버전을 선택합니다. 업그레이드는 복원 프로세스의 일부로 수행됩니다. 업그레이드가 완료되고 업그레이드된 클러스터를 사용할 수 있게 되면 모든 클라이언트 트래픽을 새로 업그레이드된 클러스터로 리디렉션합니다. 워크로드를 다시 활성화하기 전에 필요한 모든 구성 설정과 기타 사용자 정의가 새 클러스터에 적용되었는지 확인하세요. 더 이상 필요하지 않은 경우 원래 클러스터를 제거할 수 있습니다.

더 큰 데이터 세트의 경우 Aurora가 3개의 가용 영역에 분산된 분산 스토리지 클러스터 볼륨을 구축하므로 복원 시간이 늘어날 수 있습니다. Aurora clone 은 더 빠르고 비용 효율적인 옵션입니다. 쓰기 워크로드를 중지하고 원래 클러스터의 Aurora clone 복제본을 생성 할 수 있습니다. clone 복제가 준비되면 전체 업그레이드(앞서 설명한 대로)를 수행하여 clone 복제 데이터베이스에서 주요 버전 업그레이드를 수행할 수 있습니다. 업그레이드가 완료되고 클러스터를 사용할 수 있게 되면 애플리케이션 트래픽을 업그레이드 클러스터로 리디렉션할 수 있습니다.

두 옵션 모두 스냅샷을 찍거나 클론을 생성하기 전에 쓰기를 중지하므로 가동 중지 시간이 발생합니다. 또한 새 클러스터를 생성합니다. 이는 클러스터에 새 엔드포인트가 생기고 새로 업그레이드된 클러스터를 가리키도록 애플리케이션 코드를 업데이트해야 함을 의미합니다.

메이저 버전 업그레이드 방법 요약

다음 표에는 업그레이드 옵션이 요약되어 있습니다.

Method	Pros	Cons
In-place 업그레이드	간단하고 편리함 동일한 데이터베이스 엔드포인트를 유지합니다.	업그레이드 기간 동안의 가동 중지 시간
RDS 블루/그린 배포	AWS에 의해 관리되는 기능 효율적 위험 및 가동 중지 시간 감소 블루와 그린 환경을 동기화 상태로 유지합니다. 엔드포인트가 자동으로 업데이트됩니다.	바이너리 로깅이 아직 활성화되지 않은 경우 활성화가 요구 되며, 이로 인해 다시 시작됩니다. 또한, 새로운 그린 환경을 조성하므로 추가 비용이 발생합니다. 전환이 수행된 후에는 이전 블루 클러스터를 삭제 하여 비용을 절감할 수 있습니다.
스냅샵 복원	업그레이드를 테스트하거나 프로덕션 환경에서 업그레이드를 수행하는 데 사용할 수 있습니다.	새 클러스터를 복원하고 업그레이드하는 데 걸리는 시간에 대한 가동 중지 시간입니다.
Clone 복제	스냅샷을 복원하는 것보다 빠릅니다.	Clone에서 전체 업그레이드를 수행하는 데 걸리는 시간에 대한 다운타임입니다.

마지막으로, 또 다른 옵션은 롤백 옵션을 포함하도록 수동 블루/그린 배포 를 설정하는 것입니다.

프로덕션 환경을 업그레이드하기 전에 테스트 환경 성능 테스트

테스트 환경을 업그레이드한 후 프로덕션에서 업그레이드를 수행하기 전에 데이터베이스 성능을 모니터링하고 테스트하는 것이 중요합니다. 쿼리 실행 엔진은 일반적으로 버전이 바뀔 때마다 향상되지만, 드물게 최신 버전에서는 쿼리가 덜 최적화 된 실행 계획을 사용할 수도 있습니다. MySQL 5.7과 MySQL 8.0 간의 변경(예: 새 데이터 사전)으로 인해 쿼리 성능 차이를 관찰할 수 있습니다. 다음은 이러한 성능 불일치를 진단하기 위한 권장 사항입니다.

과거 성능 데이터를 저장하고 Aurora 클러스터에 대한 기준을 설정하는 것이 좋습니다. 이 데이터를 사용하여 현재 성능을 과거 추세와 비교할 수 있습니다. 또한 정상적인 성능 패턴과 이상 징후를 구별하고 문제를 해결하기 위한 기술을 고안할 수도 있습니다.
Aurora MySQL 2 클러스터에서 샘플 워크로드를 캡처하고 Aurora MySQL 3에서 다시 실행하여 버전 3의 성능 변경 사항을 검토합니다. mysqlslap 과 같은 도구를 사용하여 무차별 대입 테스트를 위한 워크로드를 재생할 수 있습니다. 그러나 동일한 매개변수를 사용하여 동일한 쿼리를 다시 실행하기 때문에 결과가 다를 수 있으며 추가 확인이 필요할 수 있습니다.
sysbench를 사용하여 Aurora 성능을 평가할 수 있습니다. 자세한 내용은 Amazon Aurora 성능 평가 기술 안내서 를 참조하세요. 이 가이드에서는 sysbench를 사용하여 성능을 평가하지만 bash 스크립트를 조정하여 원하는 도구를 사용하도록 지침을 조정할 수 있습니다.
Amazon RDS 성능 개선 도우미 를 사용하여 데이터베이스의 로드, 상위 SQL 쿼리, 사용자 및 대기 이벤트를 평가하세요. 데이터베이스 로드가 Amazon Aurora MySQL 대기 이벤트 에 어떤 영향을 미치는지 모니터링합니다. 이는 성능 병목 현상을 식별하는 가장 중요한 도구 중 하나입니다.
실행하는 데 오랜 시간이 걸리므로 최적화 후보가 되는 쿼리를 찾으려면 Aurora MySQL 슬로우 쿼리 로그 를 활성화하는 것이 좋습니다.
메이저 버전 업그레이드로 인해 쿼리의 쿼리 실행 계획이 변경될 수 있습니다. 차이점을 비교하기 위해 이전 버전과 새 버전에서 샘플 실행 계획을 수집할 수 있습니다. 또한 쿼리를 검토하여 이전 버전에서 force index와 같은 옵티마이저 힌트를 사용했는지 확인하세요. 이는 메이저 버전 업그레이드 후 다르게 수행될 수 있습니다. 성능 개선 도우미와 슬로우 쿼리 로그를 사용하여 데이터베이스 대기에 영향을 미치는 상위 SQL을 식별한 후 다음 도구 중 일부를 사용하여 쿼리를 최적화할 수 있습니다.
- EXPLAIN 은 쿼리 실행과 관련된 개별 단계를 표시할 수 있습니다.
- 쿼리 프로파일링 은 현재 세션 중에 실행 중인 문의 리소스 사용량을 나타냅니다.
- ANALYZE TABLE 은 옵티마이저가 쿼리를 실행하기 위한 적절한 계획을 선택하는 데 도움이 되는 테이블 및 인덱스 통계를 업데이트합니다.
쿼리 캐시 는 MySQL 8.0 커뮤니티와 Amazon Aurora MySQL 3에서도 제거되었습니다. Aurora MySQL 2 클러스터에서 쿼리 캐시를 사용해 온 경우 SelectLatency와 같은 쿼리 지연 시간 지표 측면에서 이 변경 사항이 데이터베이스 성능에 어떤 영향을 미치는지 확인하세요.
MySQL 8.0 Community Edition은 이전 MySQL 버전과 다르게 임시 테이블을 처리하며 이러한 동작 변경은 Amazon Aurora MySQL 3에서도 따릅니다. 워크로드에서 임시 테이블을 많이 생성하는 경우 변경 사항과 그 영향을 검토하려면 Aurora MySQL 버전 3의 새로운 임시 테이블 동작 을 참조하세요.
MySQL 8.0 Community Edition의 기본 문자 세트 는 utf8mb4이며 Aurora MySQL 3에도 동일하게 적용됩니다.
일부 쿼리 및 저장 프로시저는 데이터 정렬 충돌로 인해 테이블 인덱스를 사용할 수 없는 경우 성능이 저하될 수 있으므로 업그레이드하기 전에 문자 집합을 변경해야 하는지 확인하십시오.
두 버전 간의 성능을 비교할 때 성능 관련 매개변수의 기본값이 변경되었는지 확인하세요. 이는 문제를 격리하고 범위를 좁히는 데 좋은 단계가 될 수 있습니다. 자세한 내용은 변경된 서버 기본값 을 참조하세요.

모니터링 및 알림

이제 업그레이드를 시작했으므로 DB 인스턴스의 상태를 모니터링하고 업그레이드 중 오류도 확인할 수 있는 몇 가지 방법을 검토해 보겠습니다.

Aurora 이벤트를 모니터링 하여 업그레이드의 현재 상태를 확인할 수 있습니다. DB 인스턴스 이벤트 에서 업그레이드에 해당하는 RDS 이벤트 ID를 구독하여 업그레이드 상태 알림을 받을 수 있습니다.
CPUUtilization 및 FreeableMemory와 같은 Amazon CloudWatch 지표를 사용하여 업그레이드 후 리소스 소비를 모니터링하고 이것이 SelectLatency, CommitLatency와 같은 쿼리 지연 시간 지표에 미치는 영향을 모니터링합니다. 지표의 전체 목록은 Amazon Aurora에 대한 Amazon CloudWatch 지표 를 참조하세요. 또한 CloudWatch 알람 를 사용하면 지표가 지정된 임계값을 초과하는 경우 알림을 받고 문제를 해결할 수 있습니다.
Aurora 업그레이드의 경우 초기 단계 에는 Aurora가 완전한 종료를 수행하고 트랜잭션 롤백 및 제거 취소와 같은 미해결 작업을 완료하는 것이 포함됩니다. 따라서 프로덕션 환경에서 업그레이드 시작을 준비하는 동안 데이터베이스에 업그레이드 기간에 영향을 줄 수 있는 장기 실행 트랜잭션이 없는지 확인하세요. 마찬가지로, 롤백 세그먼트 기록 길이가 길면 Aurora가 대상 버전으로 업그레이드하기 전에 실행 취소 로그를 제거하므로 업그레이드 프로세스가 느려질 수 있습니다. 확인하려면 다음 명령을 사용할 수 있습니다.

SHOW ENGINE INNODB STATUS
SHOW FULL PROCESSLIST
SELECT NAME,COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME="trx_rseg_history_len";

클러스터 시작 및 종료 시 오류가 발생하면 Amazon Aurora MySQL은 mysql-error.log 파일을 작성합니다. 로그 파일에는 로그 항목이 작성된 시기를 확인하는 데 도움이 되는 타임스탬프도 있습니다. 업그레이드 중에 문제가 발생한 경우 로그를 검토할 수 있습니다. 자세한 내용은 Aurora MySQL 오류 로그 를 참조하세요.
어떤 이유로든 업그레이드가 실패하면 mysql-error.log 파일을 검토하여 문제를 해결할 수 있습니다. 업그레이드 사전 확인 중에 오류가 발생한 경우 upgrade-prechecks.log 파일에서 오류와 해결 단계를 검토하세요.

주요 고려사항

Amazon Aurora MySQL 5.7에서 8.0으로 업그레이드할 때 몇 가지 주요 고려 사항이 있습니다.

Aurora는 대상 업그레이드 버전에 대한 새 파라미터 그룹이 제공되지 않은 경우 메이저 버전 업그레이드 중에 자동으로 생성합니다. 사용자 지정 매개변수 그룹을 사용하는 Amazon Aurora MySQL 인스턴스의 경우, 업그레이드할 때 항상 유사하거나 동일한 값을 갖는 유사한 매개변수가 있는 현재 버전 매개변수 그룹과 일치하는 대상 버전의 매개변수 그룹을 선택하세요. 매개변수 변경 사항에 대해 알아보려면 Aurora MySQL 버전 3의 매개변수 변경 사항을 참조하세요.
lower_case_table_names 파라미터에 사용자 지정 값을 사용하는 경우 이 설정으로 미리 사용자 지정 파라미터 그룹을 설정해야 합니다. Amazon Aurora MySQL 버전 2에서 버전 3으로 업그레이드할 때 lower_case_table_names에 동일한 설정을 사용하는 것이 좋습니다. MySQL 5.7과 달리 MySQL 8.0은 업그레이드 후 lower_case_table_names 값 변경을 제한합니다. 애플리케이션 요구 사항을 검토하고 원하는 설정 값을 결정하세요. 한번 결정된 후에는 변경할 수 없습니다.
Amazon Aurora 글로벌 데이터베이스 를 사용하는 경우 글로벌 데이터베이스에 대한 in-place 주요 버전 업그레이드의 단계 를 검토하세요.
Aurora Serverless v1을 사용하는 경우 가동 중지 시간을 최소화하면서 Amazon Aurora Serverless v1에서 v2로 업그레이드 를 참조하세요.
Aurora 클러스터에 다수의 데이터베이스 객체(테이블, 데이터베이스, 이벤트, 트리거, 저장 프로시저)가 포함되어 있는 경우 업그레이드를 더 빠르게 완료하기 위해 더 많은 CPU 용량과 메모리 리소스를 제공하는 더 큰 인스턴스 클래스 를 사용하는 것이 좋습니다.

결론

이 게시물에서는 Amazon Aurora MySQL 3 업그레이드 절차, 다양한 업그레이드 프로세스 및 모범 사례를 검토했습니다. 최신 버전에서 사용할 수 있는 새로운 기능과 최적화를 활용하려면 Amazon Aurora MySQL 2.x 클러스터를 업그레이드하고 필요한 테스트를 수행하는 것이 좋습니다.

업그레이드에 대한 자세한 내용은 Amazon Aurora MySQL DB 클러스터 업그레이드를 참조하세요.

AWS 기술 블로그