Backend

Aurora MySQL 업그레이드엔 블루그린 배포 어때?

Rocket여기어때

2024년 1월 26일

원문에서 보기 ↗

Aurora MySQL 업그레이드엔 블루/그린 배포 어때?

23년 10월,

여기어때컴퍼니 SRE팀에 새롭게 합류한 DBA가 블루/그린 배포를 활용해 업그레이드를 진행한 경험을 공유하려 합니다.

어느 날 EOS라고 했다.

아…

요약하면, 3.01, 3.02 버전은 2024년 1월 15일부로 자동 업그레이드가 예정되어 있고, 이를 단순한 마이너 업그레이드로 대응하기보다는, 이후 진행해야 할 Aurora MySQL 2.x to Aurora MySQL 3.x 메이저 업그레이드를 준비하는 과정으로 보고 여러 업그레이드 방식을 조사해 보았습니다.

업그레이드는 “In-place”, “Snapshot 복원“, “Blue/Green 배포” 세 가지를 검토했으며, 운영 안정성과 유연성 측면에서 가장 효율적인 방법인 Blue/Green 배포 를 선택하였습니다. 업그레이드 대상 버전은 당시 기준 LTS(Long Term Support)로 제공되던 Aurora MySQL 3.04.1로 결정하여, 이후 장기적인 지원과 호환성을 고려하였습니다.

Aurora MySQL 버전 업그레이드

이 문서는 Aurora MySQL 2.11.2 to 3.04.1 메이저 업그레이드 기준으로 작성되었습니다.

1. In-place 업그레이드

In-place 업그레이드는 AWS Management Console 또는 AWS CLI를 이용한 클러스터 수정작업으로 간단하게 업그레이드가 가능합니다. 하지만 업그레이드 시작부터 완료까지 다운타임이 필요하며 소스클러스터가 업그레이드되므로 롤백이 어렵습니다.

In-place upgrade — console

AWS CLI로도 동일한 작업을 진행할 수 있습니다. 간단하게 엔진버전만 수정해 업그레이드 가능하며, — allow-major-version-upgrade 옵션은 마이너, 메이저버전 모두 업그레이드가 가능하게 합니다.

# in-place upgrade - AWS CLI

aws rds modify-db-cluster \
--db-cluster-identifier <<<cluster_name>>> \        #클러스터 식별자
--engine-version 8.0.mysql_aurora.3.04.1 \          #엔진버전(기존 값5.7.mysql_aurora.2.11.2)   
--allow-major-version-upgrade \                     #메이저버전업그레이드 허용
--apply-immediately \                               #변경사항 즉시적용
--profile= <<<credentials_profile>>>#

2. 스냅샷 및 복원

백업된 스냅샷이 있다면, 스냅샷 복원에서 엔진버전을 선택해 복원 가능합니다. 자동 스냅샷을 사용 중 이라면 PITR(Point In Time Recovery)을 이용해 복원 후, 업그레이드를 하는 방법이 있습니다.

스냅샷 복원

스냅샷을 활용한 업그레이드는 아래 그림의 순서로 진행하게 됩니다. Source — Target 간 데이터 싱크를 맞추기 위해 변경분에 대한 트랜잭션 컨트롤이 필요하며, 아래 그림의 3번 구간에서 다운타임이 발생합니다. 데이터를 동기화 하는 방법으로는 2번 작업 후 서비스를 중단하고 전환 전까지 발생한 변경분을 Binlog를 이용해 반영하는 방법과 Source — Target 간 Binlog Replication 구성해 싱크를 맞추는 방법이 있습니다.

이 방법은 트랜잭션 동기화나 Replication구성, 리소스 리네임, Dynamic Variables 조작 등이 수반되기 때문에 작업의 복잡도가 높아진다는 단점이 있습니다. 복잡도를 줄이기 위해 1, 2, 3번 모든 구간에서 다운타임을 가지는 방법도 있으나 작업 소요시간이 크게 늘어나게 됩니다. PITR을 사용해 백업에 필요한 시간을 줄여 작업 소요시간을 단축하는 전략도 있으니 스냅샷 복원을 통한 업그레이드를 준비하고 계신다면 참고 부탁드립니다.

3. 블루/그린 배포

Amazon Aurora RDS는 블루/그린 배포를 지원합니다. 블루/그린 배포에서 블루환경은 프로덕션 환경이며, 그린환경은 스테이징 환경입니다. 블루/그린 배포 생성 시 Logical Replication이 구성되고 자동으로 블루/그린 환경은 동기화 상태를 유지합니다.

블루/그린 배포가 생성되면, 그린환경에서 클러스터 변경 작업을 할 수 있습니다. 인스턴스 클래스 변경, DDL, 파라미터 그룹 변경 등이 해당되며, 프로덕션 워크로드에 영향을 주지 않고 작업 가능합니다. 그리고 전환 전 테스트를 통해 그린환경에 반영된 변경점들의 영향도를 미리 파악 할 수 있다는 것도 장점 중 하나입니다.

블루/그린 배포는 아래와 같이 생성 가능합니다.

블루/그린 배포 생성

블루/그린 배포 생성 과정

블루/그린 배포 생성이 완료되면, 버튼으로 간단하게 그린환경으로 전환 가능하며, 장애발생 시 블루환경으로 롤백이 용이합니다. 또한, 앞서 언급한 ‘Replication을 활용한 스냅샷 및 복원’ 은 작업의 복잡도가 매우 높다고 말씀드린 바 있습니다. 블루/그린 배포는 “Replication을 활용한 스냅샷 및 복원“과 거의 동일한 프로세스로 진행되지만, 복잡도가 높은 작업들을 직접 핸들링 하지 않아도 된다는 장점이 있습니다.

앞서 총 세가지의 업그레이드 방법을 비교해 보았는데요, 정리 해 비교하면 다음과 같습니다.

업그레이드 장/단점 비교

다양한 업그레이드 방법들을 비교/대조해 본 결과 안정성이 높고 유사시 빠른 롤백이 가능하며 실 작업시 작업자의 부담을 덜어줄 수 있는 ‘블루/그린 배포’ 방식을 선택하게 되었습니다. 여기어때는 블루/그린 배포 기능이 나오기 이전부터 Manual 블루/그린 배포라고 할 수 있는 방식을 적용하고 있었습니다. 이번 마이너 업그레이드에선 블루/그린 배포를 개발, 스테이징, 운영환경에 검증/적용 해보고 나아가 블루/그린 배포를 활용해 24년 MySQL 5.7 호환 버전 메이저 업그레이드를 진행할 계획입니다.

다음으로는 여기어때에선 블루/그린 배포를 업그레이드에 어떻게 활용했는지 공유드리겠습니다.

블루/그린 배포 및 전환 과정

블루/그린 배포 전 확인 사항

Binlog 활성화 여부 파악

블루 /그린 간 동기화를 위해 Replication을 구성하게 됩니다. binlog_format 파라미터의 값이 OFF 일 시 MIXED, ROW 둘 중 하나로 변경합니다.

클러스터 IAM Role 확인 및 추가

블루에 적용되어 있는 클러스터 IAM Role은 그린으로 복제되지 않습니다. 블루 환경에 별도의 롤을 부여해 사용하고 있다면 그린에 추가해주어야 합니다.

위 그림의 기본 구성에서 블루/그린 배포를 생성합니다. 블루/그린 배포를 구성함으로써 얻는 이점 중 하나가 그린환경에서 변경점에 대한 테스트가 가능하다는 것 입니다. 사전에 업그레이드 버전에 대해 개발, 스테이징, QA 등 여러 환경에서 검증과정을 진행하지만, 운영환경에서의 테스트도 필요했습니다. 그래서 블루/그린 배포 전환 전 리얼데이터를 활용, 사용자의 모든 쿼리를 점검하고 최적화하기 위해 Route 53 도메인으로 가중치 설정 하여 약 일주일간 읽기 트래픽 일부가 그린환경에서 실행되도록 유지했습니다. 가중치 기반으로 트래픽 분산하여 테스트 시 최소한의 오류로 운영 환경에서의 문제점을 파악할 수 있는 장점이 있습니다.

가중치 기반 라우팅 설정은 마법사로 진행했으며, 생성 방법은 다음과 같습니다.

1. 가중치 기반 라우팅 선택

2. 기본 구성 및 레코드 정의

마법사가 아닌, 빠른생성으로 진행한다면 레코드간 TTL값이 일치해야 생성 가능합니다.

Route 53 레코드 설정을 완료하고 생성하면, 대상이 되는 엔드포인트에 라운드 로빈 방식으로 트래픽이 들어오게 됩니다. 가중치를 약 9:1로 설정하여 진행했고 아래 그림과 같이 두개의 노드에 트래픽이 정상적으로 분산된 걸 확인 할 수 있습니다.

블루/그린노드 간 Database Connection 지표

블루/그린 배포 생성 후 약 일주일의 기간동안 트래픽을 흘려 테스트 진행 후 이상이 없으면 전환을 진행하게 됩니다. 전환이 완료된 그린은 new blue로, 기존 블루는 old blue로 변경되며 업그레이드 작업이 완료됩니다.

블루/그린 전환 과정

블루/그린 배포 전환 시 짧은 시간의 순단이 발생합니다. 테스트에서는 읽기 1초 미만, 쓰기 30초 미만의 순단이 발생함을 확인했습니다. 아래 표의 3번 프로세스부터 서비스 트래픽이 전환되며, 짧은 읽기 순단이 발생합니다.

전환 프로세스

블루/그린 배포를 사용하며, 작업시간 및 작업준비에 필요한 시간을 1시간에서 5분 미만으로 약 90%이상 줄일 수 있었습니다. 기존에 리소스가 많이 들던 작업(Replicaiton 구성, 파라미터 변경, 리소스 리네임 등등..)을 핸들링 하지 않고 간편하게 배포 및 전환이 가능한 부분은 블루/그린 배포의 가장 큰 장점이라고 생각합니다.

이처럼 블루/그린 배포는 Aurora MySQL의 업그레이드, 변경작업에 편리한 도구로써 사용할 수 있는데요, 편리함도 있지만 블루/그린 환경유지 시 발생하는 비용에 대한 고려가 필요합니다. 비용에 대한 문제만 없다면 짧은 순단과 적은 리소스로 블루/그린 배포를 활용한 업그레이드는 어떨까요?