※ Amazon Aurora MySQL 버전 2 (MySQL 5.7 호환) 표준 지원 종료 날짜: 2024년 10월 31일

AWS Aurora MySQL 버전 업그레이드 작업 전 알아두면 좋을 내용들을 정리하였다.

배포방식

1️⃣ In-Place 배포 방식

현재 데이터베이스를 다이렉트로 업그레이드 하는 작업이기에 다운타임 발생

2️⃣ Blue/Green 배포 방식

  • 프로덕션 환경(블루)에 영향을 주지 않고 스테이징 환경(그린)에서 DB 변경(또는 업그레이드)

  • 이 후 그린환경이라는 복제본과 블루 환경을 교체하는 방식이기에 무중단으로 배포해야하는 환경에서 우선적으로 고려해볼 수 있는 배포방식. (그렇다고해서 다운타임이 전혀 없지는 않고 약 2분가량의 다운타임 발생)

  • 일단 그린 환경의 복제본이 생성되고나면 두 환경 간 스위칭을 하지 않으면 블루환경에서 발생되는 변경사항은 그린 환경에 그대로 동기화 된다. 최종적으로 블루 그린 환경 간 스위칭을 시작하면 동기화가 모두 완료될때까지 쓰기작업이 중단된다. 따라서 이 때 발생되는 다운타임을 최소화 하기위해서 Switch Over 작업은 트래픽이 가장 적은 시간대에 수행하는 것을 권장하고있다.

  • 위에서 말한 ‘동기화 작업’을 위해 Aurora MySQL은 기본적으로 binlog_format 파라미터가 ROW로 활성화 되어있어야한다. 따라서 “블루그린 배포” 생성 전 해당 파라미터를 수정하고, 이 파라미터가 잘 적용되도록 하기 위해 인스턴스 재부팅을 해야한다. 즉, 이 때 첫번째 다운타임 발생.

파라미터 설정

주요포인트를 정리하였다.

  • 파라미터 그룹은 기본적으로 클러스터 파라미터 그룹과 인스턴스 파라미터 그룹 2가지로 분류.

  • 즉, 기존의 5.7버전 DB의 클러스터에는 5.7버전의 클러스터 파라미터 그룹, 인스턴스에는 5.7버전의 인스턴스 파라미터 그룹이 설정되어있는 상태.

  • DB 메이저 업그레이드 작업은 이 각각의 파라미터 그룹도 8.0 버전 파라미터 그룹으로의 교체까지도 포함된다.

  • 처음에는 클러스터와 인스턴스 파라미터 그룹이 Default 버전으로 설정 (클러스터 생성시 별도의 사용자 정의 파라미터그룹을 지정하지 않으면 Default로 설정되는 파라미터 그룹이며, 삭제 불가능한 파라미터 그룹)

  • 클러스터 파라미터 그룹에 있는 Param이 인스턴스 파라미터 그룹에도 있는 것을 볼 수 있는데, 이 때 인스턴스 파라미터 그룹이 더 우선순위를 가지고 있기 때문에 클러스터 파라미터 그룹의 Param은 무시된다.

  • 만약 Default가 아닌 **‘사용자 정의 클러스터 파라미터 그룹’**을 클러스터에 적용하면 이 클러스터 파라미터 그룹 내 Param이 더 우선권을 가진다. (인스턴스 파라미터 그룹의 중복되는 Param은 무시)

  • 그리고 다시 인스턴스에도 Default가 아닌 사용자가 생성한 ‘사용자 정의 인스턴스 파라미터 그룹’을 적용하면 당연히 이 파라미터 그룹이 또 다시 우선권을 가진다.

  • 즉, 파라미터 그룹 우선순위를 요약하면 Default Cluster PG < Default Instance PG < Custom Cluster PG < Custom Instance PG

위 내용은 DB 인스턴스 마다 서로 다른 파라미터 그룹을 설정할 수 있도록 설계되었다고 생각하면 이해하기 쉽다. 이것을 이해하고나면 5.7 파라미터 그룹의 내용을 기반으로 8.0 파라미터 그룹을 어떻게 생성 및 반영할지 계획해 볼 수 있다.

클러스터 및 인스턴스 파라미터 그룹 각각에서,

  1. 적용된 5.7 파라미터 그룹이 Default인지 아닌지 확인

  2. Default 파라미터 그룹 대비 어떤 Parameter가 변경되어있는지 확인 → 값이 다른 파라미터는 사용자 정의된 파라미터

  3. 이 파라미터가 Default 8.0 버전 파라미터 그룹에도 존재하는 경우 사용자 정의된 값으로 적용

  • 위에서도 언급했지만, Blue/Green 배포방식으로 업그레이드 하는경우, binlog_format 파라미터를 ROW로 수정 후 재부팅해야한다.

  • 5.7버전 파라미터 그룹을 보면 utf8 관련된 파라미터가 다음과 같이 있다. uft8은 “utf8mb3”의 별칭이며, 이 utf8(utf8mb3) 타입은 8.0.x과 8.4.x LTS release 버전까지만 지원될 예정이며, 향후 주요 릴리스에서 제거 예정이라고 안내되고있다.(관련내용 공식문서) 따라서 이에 대비하기 위해 8.0 업그레이드 작업은 utf8mb4로 설정하여 테스트 진행했고, 이상 없는 것을 확인 후 실제 운영싸지 안전하게 utf8mb4 타입으로 적용되었다. 두 타입은 내부적으로 한 문자를 표현하는데 사용되는 byte 크기가 다음과 같은 차이가 있다. **• utf8: 3 byte • utf8mb: 4 byte **emoji가 사용되는 서비스, 그리고 외국어가 사용되는 서비스에서 특히 utf8mb4 사용이 권장되고있는데, utf8 타입 DB에 이러한 데이터가 저장되어있는 DB를 갑자기 utf8mb4로 변경 및 업그레이드하는 경우 문제가 될 수 있으니 이 부분 주의해서 충분한 테스트가 필요하다고했다.

  • event_scheduler 파라미터는 5.7과 8.0 모두 기본적으로 ‘-’(Dynamic)로 설정되어있는데, 이게 5.7에서는 false(비활성) 상태이며 8.0에서는 true(활성) 상태로 적용된다는 내용이 있었다. 실제로 각 버전 DB에서 SHOW`` VARIABLES ``LIKE`` ``'event%'``; 명령을 실행해보면 다른 결과값을 출력하고있다. 이에 따라 8.0에서는 SHOW PROCESSLIST; 실행시 아래와 같은 Daemon이 계속해서 대기중인 것을 볼 수 있었다.

ROLLBACK

최근 참석했던 ‘**Aurora MySQL 2 End of Life (EOL) 웨비나’**에서도 현재로써는 롤백을 위한 서비스가 아직까진 지원되고있지 않다는 얘기를 들었다. 다른 여러 문서도 찾아보았지만 결국 블루/그린 배포 방식은 운영 중인 데이터베이스 업그레이드시 발생되는 다운타임을 최소화하기 위한 방법일 뿐 롤백을 더 수월하게 할 수 있도록 지원해주지는 않는다.

어쩔수 없지만 번거롭더라도 업그레이드 전 다음과 같은 롤백 프로세스 세워두었다.

  • 업그레이드 전 복제본 생성(백업) → 일종의 백업이자 롤백시 사용될 DB 클러스터

    • In Place 방식이라면, 업그레이드 전 “복제본 생성”

    • Blue/Green 배포 방식이라면, Switch Over 후의 기존의 Blue 환경이 곧 롤백용 클러스터 (기존의 Blue 환경은 스위칭 되고나면 Blue 클러스터명 뒤에 -old가 추가된다)

  • 업그레이드 후 문제가 있다고 판단되어 롤백 해야하는 경우: 업그레이드된 DB 클러스터 명을 ‘A’, 위에서 언급한 백업용 클러스터 명을 ‘B’라고 할 때, A 클러스터 명을 A-bak 으로 수정, B 클러스터 명을 A로 수정 (애플리케이션이 바라보는 클러스터의 엔드포인트를 기존의(B) DB클러스터가 다시 갖도록 교체하는 작업)

이렇게 하면 기존의 ‘A’ DB 클러스터 엔드포인트를 바라보고있던 애플리케이션에서 코드 수정 없이 DB 롤백이 되도록 의도할 수 있다.

물론 이 방법은 다음과 같은 문제가 있다.

  • 클러스터 명을 전환하는 동안의 다운타임.

  • 업그레이드 후 롤백 시점 동안에 발생된 변경사항 반영 X → 서비스의 종류에 따라 다르지만 사실상 크리티컬한 문제.. 변경 사항을 롤백용 DB에 동기화 될 수 있도록 별도 방법만 구축해놓는다면 더 완벽할텐데 이 내용은 추후 더 찾아볼 예정

업그레이드 후기

1. 아쉬움

아쉬움이 남는 부분도 있었다. 작업 대상 DB와 동일한 인프라 내에 있는 애플리케이션에서는 DB에 붙기 위해 RDS 엔드포인트를 하드코딩으로, 다이렉트로 바라보고있었다. 그것도 다양한 모듈과 매우 많은 코드에서. 이 프로젝트 지원에 투입 된지 얼마 안되었기에 애플리케이션 구성을 전부 알지 못하는 상태였고, 수정시 영향도를 가늠할 수 없었다. Prd DB 업그레이드 작업 기간도 넉넉하지 않아 더욱 더 인프라를 함부로 손 볼 수 없었다.

만약 작업기간도 충분하고 인프라 변경도 할 수 있었다면, ELB와 PrivateLink을 구성하여 트래픽을 제어하고 보다 좋은 사전테스트를 해볼 수 있었을텐데 하는 아쉬움이 남았다. (속도 & 보안 개선도 할 수 있었을텐데)

2. 고객사 측에서 RDS의 Private IP 사용여부

이번에 업그레이드 대상 고객사는 고객사 측에서 사용하는 가상환경 안에서 Aurora MySQL DB에 연결시 엔드포인트가 아니라 IP를 통해서 연결하고있었다. 참고로 RDS의 IP는 동적으로 변한다. 그래서 AWS에서도 IP가 아니라 엔드포인트로 DB 연결하는 것을 모범사례라고 설명하고있다.

그럼에도 고객사에서 IP를 사용한 이유는 통신장비에서 RDS 엔드포인트 형식의 값을 사용할 수 없어서라는 이유를 들었다. 그래서 콘솔에서는 확인할 수도 없는 Private IP를 아마도 지금까지 nslookup 같은 명령으로 찾아서 사용해왔던 것 같다. 지금까지 운좋게 Private IP가 바뀐적 없이 운영되어 왔지만, 결국 이번 업그레이드 작업 때문에 IP가 변경되면서 접속문제가 발생하긴 했었다(다행히 크리티컬하진 않은).

따라서, 다음 업그레이드 작업시에는 고객사 측 환경에서 RDS 연결시 IP를 사용하고 있지는 않은지 확인해보는 것도 체크포인트가 될 수 있겠다. 이 경우 고객사에게 IP가 변경될 수 있다는 점을 안내하면서 별도의 프록시 서버 구성을 제안하는 것도 방법이 될 수 있다.

※ 변경까지 걸린 시간

  1. 약 200GB 크기의 스토리지, db.r6.xlarge 사이즈 Aurora MySQL의 복제본 생성: 약 10분

  2. DB의 버전 업그레이드: 약 20분

  3. 재부팅: 약 1분