USD 0.120 per hour per vCPU running RDS Extended Support for MySQL 5.7 in Year 1, Year 2
2024년 2월 29일부터 AWS RDS MySQL 5.7 버전이 지원 종료 되었으며
업그레이드 전 연장 지원에 들어가며 추가 비용이 발생할 수 있습니다.
회사 메인 DB도 5.7버전을 사용하며 이미 연장 지원 추가비용이 발생하여 더이상의 추가 비용을 방지 하기 위해 데이터베이스 버전 업그레이드를 진행하기로 하였고,
버전 업그레이드 방식을 고민하는 사람들을 위해 찾아보며 정리한 자료를 공유합니다.
:: 업그레이드 방식
1) AWS RDS 블루/그린 배포
현재 운영 환경(블루)에 스테이징 환경(그린)을 생성하고 동기화 → 테스트 후 스위칭
특징
- 리전간 읽기전용 복제본이 있는경우 불가능 → 프로젝트의 복제본 확인 할 것
- 읽기전용 복제본이 있는 RDS에서 적용하고 싶은 경우 다른 리전의 읽기전용 RDS의 클러스터를 승격시키면 두 리전간 클러스터의 연결이 끊어져 복제본이 없는 클러스터로 취급 → 블루그린 배포 사용가능
- 다운타임이 제로는 아님: 파라미터 활성화를 위한 쓰기 인스턴스 재부팅 시간과 블루/그린 전환 시간.
- 그린 스테이징 생성 시간 50기가 기준 : 1시간정도
- Reference
- https://velog.io/@dev-hr2/Mysql-5.7-8.0-Version-Upgrade
- https://blog.hbsmith.io/블루-그린-배포를-이용한-aurora-mysql-버전-무중단-업그레이드-경험-공유-23c52b988abe
- https://aws.amazon.com/ko/blogs/tech/lg-electronics-blue-green-deployments-in-amazon-aurora-and-amazon-rds/
- https://www.slideshare.net/awskorea/d1s08lgaurora-bluegreen-deployment-upgradepdf#23
장점
- 엔드포인트 변경 X
- 전환 중 데이터 손실 발생 가능성 낮음
- 운영 환경에 영향을 주지 않고 스테이징 환경에서 자유롭게 테스트 가능
- 대부분 2~7분 이내에 그린 환경으로 빠르게 전환이 가능
(다운타임은 보통 1분 미만이지만 워크로드에 따라 더 길어질 수 있음) - Replication 방식과 비슷하지만 복잡도가 높은 작업들을 직접 핸들링 하지 않음
- 제한적으로 롤백이 쉬움
단점
- 사전 작업 필요
최소 medium 사이즈 이상 인스턴스에서 가능 → staging, dev 환경에서는 테스트가 어렵다.- 테스트 결과 micro / small 사이즈에서도 사용이 가능했음
- 리소스 사용량을 두 배로 늘림 → 두 가지 환경(블루 + 그린)이 실행되어 전환 기간동안 비용이 2배
2) In-Place 업그레이드 (RDS 콘솔 이용)
RDS 에서 DB 인스턴스 수정을 이용한 엔진 버전 변경
특징
- 메이저 버전 업그레이드에는 기존 애플리케이션과 호환되지 않는 데이터베이스 변경 사항이 포함될 수 있음.
- Reference
Amazon RDS의 MySQL 버전 5.6 DB 인스턴스를 MySQL 버전 5.7 이상으로 업그레이드하려면 먼저 사용 가능한 OS 업데이트를 수행합니다. OS 업데이트가 완료된 후 각 메이저 버전으로 업그레이드해야 합니다. 5.6을 5.7로 업그레이드한 후 5.7을 8.0으로 업그레이드합니다. 2014년 4월 24일 이전에 생성한 MySQL DB 인스턴스에는 업데이트가 적용될 때까지 사용 가능한 OS 업데이트가 표시됩니다. OS 업데이트에 대한 자세한 내용은 DB 인스턴스의 업데이트 적용 단원을 참조하십시오.
장점
- 엔드포인트 변경 X
- 업그레이드 방법이 간단함
- 여러가지 제약사항이 존재하지만 업그레이드 시간을 단축가능
- 비용 X
단점
-
업그레이드 프로세스 중에 가동 중지 시간 발생 (일반적으로 10분이나, 예측할 수 없음)
Amazon RDS 콘솔에서 DB 인스턴스를 업그레이드하는 경우, DB 인스턴스 상태를 보고 업그레이드 완료 시간을 알 수 있습니다. AWS Command Line Interface(AWS CLI)를 사용하여 업그레이드하는 경우, describe-db-instances 명령을 사용하여
Status값을 확인합니다.- 사전 점검을 실행해도 가동 중지를 일으키지 않음. 사전 점검에서 비호환성이 발견되면 Amazon RDS는 DB 인스턴스가 중지되기 전에 자동으로 업그레이드를 취소
-
AWS가 업그레이드 도중 실패하면 자동 롤백하지만, 성공 후 문제가 생긴 경우 롤백이 어려움
- aws 문서에 의하면 MySQL 5.7에서 8.0으로의 메이저 버전 업그레이드는 실패 후 자동 롤백을 지원함
3) 스냅샷을 이용한 RDS 재생성
기존 DB를 백업한 스냅샷을 8.0 버전으로 생성한 신규 DB 인스턴스에 복원 하는 방법
특징
- 업그레이드 할 RDS(5.7)의 Snapshot 생성 → 스냅샷을 이용해 RDS 재생성 (8.0)
- Reference https://btcd.tistory.com/1693
장점
- 버전간 제약사항이 In-place에 비해 매우 적음
- 업데이트 시 발생하는 비용 X
- 롤백 O
단점
- 작업시간이 가장많이 소요됨
- 작업 복잡도 높음
- 클러스터 전환 시 다운타임 발생
- 엔드포인트 변경
- 데이터 손실 발생 가능성
- Source ↔ Target 간 데이터 싱크를 맞추기 위해 변경분에 대한 트랜잭션 컨트롤이 필요
4) Read Replica 생성 및 승격 방식
기존 DB의 읽기 복제본 생성 후 primary 로 승격 → 해당 인스턴스 업그레이드 → 기존환경과 동일하게 구성
특징
- 블루/그린 배포를 사용할 수 없으며 현재 프로덕션 애플리케이션에 MySQL 데이터베이스 인스턴스를 사용 중인 경우 → 다운타임 단축을 위해 고려해볼 수 있음.
- Reference
장점
- Read Replica 통해 새로 구성한 환경에서 테스트 가능
- 기존 데이터 자동 복제 및 RDS 기본 기능으로 관리가 쉬움
단점
- 비용 발생 (블루/그린 방식과 비슷함)
- 롤백 어려움
- 엔드포인트가 변경됨
- 기존 인프라에 종속 (Replica는 원본의 파라미터 그룹, 보안 설정 대부분 상속)
