베하~! 안녕하세요 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 블루/그린 배포 |
|
|
스냅샵 복원 |
|
|
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
그럼 다음 포스팅에서 또 만나요 베빠~!
'CSP (Cloud Service Provider) > AWS' 카테고리의 다른 글
CodeBuild - empty git-upload-pack given for primary source and source version refs/heads/develop (1) | 2024.06.13 |
---|---|
S3 취약점 - 허용되지 않은 요청에 S3 요금 부과되는 현상 (0) | 2024.05.21 |
AWS CloudFormationd으로 기존 리소스 IaC 템플릿 생성하기 (0) | 2024.02.19 |
[AWS] S3 Server Access Logging (1) | 2024.02.02 |
[AWS] Amazon GuardDuty (0) | 2024.02.02 |
댓글