Amazon Aurora MySQL 3버전(MySQL 8.0 호환)의 블루/그린 배포를 통한 업그레이드 시 권장 확인 사항

Amazon Aurora MySQL 3버전 으로 업그레이드 시 Amazon RDS 블루/그린 배포를 통해 업그레이드를 진행할 수 있습니다. 블루/그린 배포는 프로덕션 데이터베이스 클러스터를 별도의 동기화된 스테이징 클러스터에 복사하여 프로덕션 클러스터에 영향을 주지 않고 스테이징 클러스터에서 데이터베이스를 변경할 수 있습니다. 업그레이드 될 새로운 프로덕션 데이터베이스 클러스터가 준비 되면 대부분의 경우 1분 미만의 가동 중지 시간으로 스테이징 클러스터를 새로운 프로덕션 데이터베이스 클러스터로 승격할 수 있습니다.

Aurora MySQL DB 클러스터의 블루/그린 배포를 생성하기 전에, 기존 DB 클러스터에 바이너리 로깅(binlog_format)을 켠 사용자 지정 DB 클러스터 파라미터 그룹과 연결해야 합니다. 블루 클러스터에서 그린 클러스터로 복제하려면 바이너리 로깅이 필요합니다. 모든 바이너리 로깅 형식을 사용할 수 있지만 복제 불일치의 위험을 줄이기 위해 ROW를 사용하는 것이 좋습니다. 바이너리 로깅을 활성화한 후에는 DB 클러스터를 재부팅하여 변경 사항을 적용해야 합니다. 블루/그린 배포의 요구 사항은 기존 DB 클러스터의 쓰기(Writer) 인스턴스가 사용자 지정 DB 클러스터 파라미터 그룹과 동기화되는 것이며, 그렇지 않으면 생성에 실패합니다.

이 게시물에서는 고객이 블루/그린 배포를 통해서 업그레이드를 계획하기 위해 확인해야 할 권장 사항인 전환 모범 사례와 발생할 수 있는 오류 사례에 대해 공유합니다.

블루/그린 전환 모범 사례

블루/그린 전환 전, 전환 가드레일 검사 목록을 확인합니다.

블루/그린 배포에서 전환을 시작하면 Amazon RDS에서 몇 가지 기본 검사를 실행하여 블루 및 그린 클러스터가 전환 준비가 되었는지 테스트합니다. 이러한 검사를 전환 가드레일이라고 합니다. 각 환경에 따른 전환 가드레일 검사를 진행하여 통과되지 않는다면 전환이 진행되지 않게 합니다. 전환 가드레일 검사 대상 정보를 미리 확인하여 작업을 준비한다 실제 전환 작업 시간을 줄이고, 전환이 시작되면 발생할 수 있는 블루 및 그린 클러스터 간의 데이터 손실을 방지할 수 있습니다.

전환 모범 사례를 확인합니다.

• 전환 중에는 두 환경 모두 데이터베이스 쓰기가 차단되기 때문에 블루 클러스터에서 트래픽이 가장 적은 시간을 선택하여 전환합니다.
• 그린 클러스터가 정상이고 복제 중인지 확인합니다.
• DNS 캐시 TTL(Time-to-Live)이 Aurora DNS 영역의 기본값인 5초 이상으로 늘어나지 않도록 해야 합니다. 그렇지 않으면 애플리케이션은 전환 후에도 계속해서 쓰기 트래픽을 블루 환경으로 전송합니다.
• 전환 중에는 전환에 포함된 블루/그린 클러스터를 수정할 수 없고, 전환 후에는 블루/그린 배포를 롤백할 수 없으므로 중요한 프로덕션 워크로드의 경우 전환하기 전 충분한 테스트가 필요합니다.

전환 전 CloudWatch 지표를 모니터링 합니다.

전환 전 다음 지표에 대해 모니터링 하여 전환을 준비합니다.

• AuroraBinlogReplicaLag – 가동 중지 시간을 줄이려면 전환하기 전에 그린 클러스터에서 이 값이 0에 가까운지 확인합니다.
• DatabaseConnections – 이 값을 모니터링 하여 전환이 가능한 지 예측합니다. 성능 개선 도우미가 활성화되어 있으면 DBLoad가 더 정확한 지표입니다.
• ActiveTransactions – DB 인스턴스 파라미터 그룹에서 innodb_monitor_enable=all로 설정된 경우 이 지표를 사용하여 전환을 차단할 수 있는 활성 트랜잭션이 많은지 확인합니다.

블루/그린 전환 중 발생 가능한 오류 사례

블루/그린 배포 전환 중 오류가 발생할 수 있는 케이스는 전환 모범 사례를 검토하여 예방할 수 있습니다. 다음은 블루/그린 배포 전환 중 미리 검토하면 좋을 오류가 발생할 수 있는 몇 가지 사례에 대해 안내합니다.

복제 관련 오류 사례

• 블루/그린 클러스터 간 데이터 충돌: 데이터 충돌로 인한 전환 작업 오류를 방지하기 위해 그린 환경을 읽기 전용 (read-only) 로 유지하고, 복제 완료 상태를 확인한 후에 전환을 시도합니다. 블루 클러스터와 그린 클러스터의 데이터 충돌로 인해 다음과 같은 오류가 발생할 경우 블루/그린 배포를 다시 진행해야 할 수 있습니다.

Apply Error 1062: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' at master log mysql-bin-changelog.000001, end_log_pos 20000080. See error log and/or performance_schema.r...

• 블루 클러스터의 외부 복제: 블루 클러스터에 외부 복제가 연결되어 있다면 전환에 다음과 같은 오류로 인해 전환에 실패하게 됩니다. 이를 방지하기 위해 블루/그린 배포 전 외부 DB와 연결된 복제가 있다면 사용하지 못하도록 mysql.rds_reset_external_master를 통해 외부 복제를 삭제한 후 블루/그린 배포를 진행하거나 이미 생성하였다면 소스가 되는 클러스터 환경에서 reset slave; 명령어를 통해 복제 정보를 삭제 후 복제 재 연결을 통한 전환 사전 작업을 실행할 수 있습니다.

Switchover from DB cluster aurora-test-blue to aurora-test-green was canceled due to external replication on aurora-test-blue. Stop replication from an external database to aurora-mysql-dba-meta-a before you switch over

• 그린 클러스터의 복제 지연: 블루/그린 전환 시 Amazon CloudWatch의 AuroraBinlogReplicaLag를 모니터링 하여 그린 클러스터에서 현재 복제 지연이 있는지 살펴보고 이 값이 0이 될 때 전환 작업을 진행합니다.

Switchover from DB cluster aurora-test-blue to aurora-test-green was canceled due to high replica lag on aurora-test-blue. Either switch over when there is lower replica lag, or increase the switchover timeout value.

• 블루 클러스터의 장기 실행 DDL : 블루 클러스터에 장기 실행 DDL이 있다면 다음과 같은 오류로 인해 전환에 실패하게 됩니다. 이를 방지하기 위해 블루/그린 배포 전 블루 클러스터에서 장기 실행 DDL을 종료합니다. SHOW PROCESS FULLIST; 명령어를 통해 장기 실행DDL을 확인하고, 장기 실행 DDL이 끝나기를 기다리거나, CALL mysql.rds_kill(process_id); 명령어를 통해 강제 종료할 수 있습니다.

Switchover from DB cluster aurora-test-blue to aurora-test-green was canceled due to a long-running Data Definition Language (DDL) on aurora-test-blue. Make sure DDLs are completed before you switch over.

파라미터관련 오류 사례

• slave_parallel_workers : 그린 클러스터에 사용자의 연결 없이 History list length가 급격히 증가되는 지표가 확인될 경우 블루 클러스터의 멀티스레드 복제 사용이 원인이 될 수 있습니다. 만약 멀티스레드 복제로 인해 그린 클러스터의 Rollback segment 길이가 증가한다면 Aurora MySQL 2버전에서 멀티스레드 복제를 사용 여부 확인 후 사용하지 않는 것으로 변경하시기 바랍니다.
• autocommit : 인스턴스 수준 파라미터가 autocommit=0 으로 설정되어 있을 경우 블루/그린 배포 생성 중 사전 체크 과정에서 그린 클러스터의 업그레이드가 다음과 같은 에러 메세지와 함께 실패할 수 있습니다.

"id": "schemaInconsistencyCheck",
"title": "Schema inconsistencies resulting from file removal or corruption",
"status": "ERROR", "description": "Cannot modify @@session.sql_log_bin inside a transaction"
"id": "engineMixupCheck",
"title": "Tables recognized by InnoDB that belong to a different engine",
"status": "ERROR", "description": "Cannot modify @@session.sql_log_bin inside a transaction"
"id": "getMismatchedMetadata",
"title": "Column definition mismatch between InnoDB Data Dictionary and actual table definition.",
"status": "ERROR", "description": "Cannot modify @@session.sql_log_bin inside a transaction"

사전 체크를 위해 임시 테이블을 생성하는데 이 때 drop if exist 문을 실행하여 해당 명령어가 복제본에 전달되지 않도록 SET SESSION sql_log_bin=0 명령을 내부적으로 수행하는데 autocommit=0으로 비활성화 되어 있을 경우 사전 체크 과정에서 에러가 발생합니다. autocommit=1로 한 새로운 사용자 지정 DB 클러스터 파라미터 그룹을 생성하여 그린 클러스터에 연결하고 업그레이드를 시도하여 오류를 해결할 수 있으며, 사전 체크에만 영향이 발생하기 때문에 사전 체크 완료 후, autocommit을 기존과 같이 변경합니다.

• lower_case_table_names : 기존 Aurora MySQL 2버전의 사용자 지정 DB 클러스터 파라미터 그룹에서 lower_case_table_names=1 로 설정되어 있다면, 신규 Aurora MySQL 3버전의 사용자 지정 DB 클러스터 파라미터 그룹도 lower_case_table_names=1 로 설정하지 않으면 신규 클러스터에서 Aurora MySQL 3버전으로 업그레이드가 되지 않습니다. 기본 값은 0으로 설정되어 있으므로 설정을 하지 않을 경우, 신규 클러스터의 업그레이드가 진행되지 않으며 사유는 다음과 같습니다.

The value of the lower_case_table_names parameter in the requested parameter group is different from the value in the source parameter group. Modifying the lower_case_table_names setting isn't supported for MySQL 8.0 and higher versions. Specify a DB cluster parameter group with the same value for the lower_case_table_names parameter.

블루/그린 배포로 전환 시 고려해야 할 사항

블루/그린 배포를 검토하고 있는 고객 운영 환경에서 AWS JDBC driver를 사용하거나 Aurora MySQL 2버전에서 3버전으로 바로 업그레이드가 불가능 한 마이너 버전을 사용하는 경우 다음 사항들에 대해 확인이 필요합니다.

AWS JDBC driver 사용 시 고려 사항

AWS JDBC Driver에서 현재 블루/그린 배포에 대해 원활한 전환을 지원하고 있지 않기 때문에 그린 클러스터의 인스턴스에 대해 재시작이 필요합니다. 이는 AWS JDBC Driver가 Aurora의 빠른 Fail-over를 위해 select server_id from infromation_schema.replica_host_status쿼리를 통한 복제 호스트의 server_id 값을 토폴로지 캐시에 저장하며 인스턴스를 재시작 하지 않는 블루/그린 배포 전환 후에 이 값이 갱신되지 않음으로 인해 발생합니다. AWS는 게시물을 작성한 2024년 4월 현재 이와 관련하여 고객의 불편을 최소화 하기 위해 AWS JDBC Driver의 지원에 대한 개선을 검토하고 있습니다.

Aurora MySQL 2버전의 업그레이드를 위한 최소 지원 마이너 버전 고려 사항

Aurora MySQL 3 업그레이드의 작업 시간과 오류를 최소화 하기위해 지원되는 업그레이드 가능 버전을 먼저 확인하시고 진행하시는 것을 권장 드립니다. 업그레이드 가능 버전을 확인하기 위해 다음과 같이 CLI를 통해 Aurora MySQL 3버전으로 한번에 버전 업그레이드가 가능한 지원되는 Aurora MySQL 2버전을 확인하실 수 있습니다. Aurora MySQL 3버전으로 업그레이드가 한번에 지원되지 않는 경우, Aurora MySQL 2에서 3버전으로의 업그레이드 가능 버전을 확인 하여 1회 업그레이드 진행 후, Aurora MySQL 3버전으로 업그레이드 합니다. 이와 같이 지원되지 않는 Aurora MySQL 2버전을 사용 중인 경우 2번의 업그레이드를 통해서 Aurora MySQL 3버전으로 업그레이드를 진행할 수 있습니다.

업그레이드 가능 버전 확인 커맨드 (4월 1주차 기준 결과)

aws rds describe-db-engine-versions --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.07.10 \
  --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion'
[
    "5.7.mysql_aurora.2.11.2",
    "5.7.mysql_aurora.2.11.3",
    "5.7.mysql_aurora.2.11.4",
    "5.7.mysql_aurora.2.11.5",
    "5.7.mysql_aurora.2.12.0",
    "5.7.mysql_aurora.2.12.1",
    "5.7.mysql_aurora.2.12.2",
    "8.0.mysql_aurora.3.06.0"
]

aws rds describe-db-engine-versions --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.11.2 \
  --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion'
[
    "5.7.mysql_aurora.2.11.3",
    "5.7.mysql_aurora.2.11.4",
    "5.7.mysql_aurora.2.11.5",
    "5.7.mysql_aurora.2.12.0",
    "5.7.mysql_aurora.2.12.1",
    "5.7.mysql_aurora.2.12.2",
    "8.0.mysql_aurora.3.03.1",
    "8.0.mysql_aurora.3.03.2",
    "8.0.mysql_aurora.3.03.3",
    "8.0.mysql_aurora.3.04.0",
    "8.0.mysql_aurora.3.04.1",
    "8.0.mysql_aurora.3.04.2",
    "8.0.mysql_aurora.3.05.2",
    "8.0.mysql_aurora.3.06.0"
]

결론

이 글에서는 Amazon Aurora MySQL 3버전의 블루/그린 배포를 통한 업그레이드 시 고객분들이 참고하시면 좋을 만한 다양한 확인 필요 사항과 모범 사례를 정리하였습니다. Amazon Aurora MySQL 2버전 클러스터에서 블루/그린 배포와 전환을 통해 Amazon Aurora MySQL 3버전으로 업그레이드 시 다운 타임을 최소화 하기 위해서 권장 사항을 검토하고 사전에 테스트 하여 성공적인 업그레이드를 준비하시는 것이 좋습니다.