본문 바로가기
CSP (Cloud Service Provider)/AWS

Amazon Aurora MySQL version 3 Upgrade

by BTC_Crong 2024. 3. 26.

베하~! 안녕하세요 1-Tier팀 입니다.

오늘은 Aurora MySQL을 Version 3 로 업그레이드를 하기 위한 준비 과정과 방법에 대해 알아보고자 합니다.

 

Amazon Aurora MySQL 버전 3는 가장 최신화 된 메이저 버전으로 MySQL 8.0과 호환 됩니다.

버전 3에서는 Amazon Aurora Serverless v2, Amazon Aurora zero-ETL, AWS Graviton3 지원, 향상된 바이너리 로그  Amazon Aurora I/O-Optimized와 같은 새로운 기능에 대한 지원이 포함되며

기존의 버전 2 (MySQL 5.7 호환)는 2024년 10월 31일에 표준 지원이 종료됩니다.

지원 종료 후 최대 3년간 기존 버전을 확장 지원 받을 수 있습니다.

확장 지원 시 아래와 같이 추가 요금이 발생합니다. (서울 리전 기준)
https://aws.amazon.com/ko/rds/aurora/pricing/

 

MySQL PostgreSQL 관계형 데이터베이스 – Amazon Aurora Pricing – AWS

 

aws.amazon.com

1년차 및 2년차 요금
(ACU-시간당)
3년차 요금
(ACU-시간당)
0.102 USD 0.204 USD

 

업그레이드 준비

업그레이드 전 데이터베이스 및 애플리케이션이 정상적으로 동작 되는지 확인하기 위해 테스트 및 검증 절차가 필요하며 몇 가지 주요 초점을 기준으로 업그레이드를 준비하게 됩니다.

 

  • 호환성 : 애플리케이션이 예상대로 작동하려면 특정 프로덕션에서 업그레이드 하기 전에 업그레이드 프로세스를 테스트하여 호환성 문제를 확인해야 합니다.
    Amazon Aurora의 빠른 데이터베이스 복제 기능을 사용하여 클러스터를 복제 후 새 클러스터에서 업그레이드 및 업그레이드 후 테스트를 수행하거나 스냅샷으로 새 클러스터에서 테스트를 수행할 수 있습니다.
  • 성능 : MySQL 5.7과 MySQL 8.0 간의 변경으로 인해 성능 차이가 발생할 수 있으므로 쿼리 성능을 테스트 하기 위해 권장 사항과 도구에 대해 논의해야 합니다.
  • 가용성 : 애플리케이션 가동 중지 시간을 최소화 해야하며 만일 문제가 발생할 경우를 대비해 대체 옵션을 준비해야 합니다.
  • 노력 : 업그레이드를 준비하는 동안 계획하고 테스트하는 데 필요한 노력을 고려해야 할 수도 있습니다. 또한 해당 작업을 다른 곳에서 재사용할 수 있는지 고려할 필요가 있습니다.

업그레이드 프로세스

업그레이드 사전 체크 - 스냅샷 생성 - 재시작 및 Undo log 제거 - Writer 패치 및 데이터 딕셔너리 업데이트 - Reader 패치

 

1. 업그레이드를 시작하면 수행하기 앞서 호환성 문제를 찾습니다.

2. 문제 발생 시 롤백을 위한 스냅샷을 생성합니다.

3. 실행 트랜잭션이 있거나 할 경우 제거합니다.

4. Writer 인스턴스가 먼저 업그레이드 됩니다.

5. Reader 인스턴스가 업그레이드 됩니다.

업그레이드 옵션

다음과 같은 업그레이드 옵션이 있습니다.

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

In-place 업그레이드

가장 간단한 옵션으로, 새 클러스터가 생성되지 않아 모든 데이터를 새 클러스터 볼륨에 복사할 필요가 없어 동일한 클러스터 엔드포인트와 기타 특성을 유지할 수 있습니다.

그러나 업그레이드 프로세스를 실행 시 성공하거나 실패할 때 까지 중지할 수 없으며 문제 발생 시 변경 사항 롤백을 시도합니다.

Amazon RDS 블루/그린 배포

가동 중지 시간 최소화가 최우선 과제인 경우 사용됩니다.

이전 클러스터와 새 클러스터를 나란히 실행하여 데이터를 복제하고 MySQL 바이너리 로그 복제를 사용하여 동기화 상태를 유지합니다. 원하는 시점에 업그레이드를 수행하면 블루에서 그린 환경으로 전환이 가능하며 30~3,600초(1시간) 사이에서 전환 시간 초과를 지정할 수 있습니다. 전환 시간 초과 시 자동으로 블루환경으로 롤백되며 성공 시 블루 환경의 엔드포인트와 일치하도록 그린 환경의 엔드포인트 이름을 변경합니다.

이후 블루 환경이 필요 없으면 삭제처리 합니다.

스냅샷 복원 및 Aurora Clone 복제

주요 버전 업그레이드를 테스트하기 위한 테스트 환경을 만들 때 도움이 되며 클러스터의 수동 스냅샷을 생성하고 업그레이드 하려는 엔진 버전으로 복제 합니다.

업그레이드 된 클러스터를 사용할 수 있게 되면 모든 트래픽을 새 클러스터로 리디렉션 하여 업그레이드 합니다.

이후 원하는 시점에 원래 클러스터를 제거합니다.

스냅샷을 찍거나 클론을 생성하기 전에 가동 중지 시간이 발생하며 새 클러스터에는 새 엔드포인트가 생성되어 애플리케이션 코드를 새 클러스터를 가리키도록 업데이트 해야 합니다.

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

버전 2와 버전 3의 차이점

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-v2-v3.html

 

Comparison of Aurora MySQL version 2 and Aurora MySQL version 3 - Amazon Aurora

If your high availability requirements are fulfilled by the Aurora built-in replication features, you can leave binary log replication turned off. That way, you can avoid the performance overhead of binary log replication. You can also avoid the associated

docs.aws.amazon.com

 

그럼 다음 포스팅에서 또 만나요 베빠~!

댓글