AWS RDS 블루/그린 배포 생성

시작

이번에는 AWS 환경에서 RDS를 업그레이드 위한 방법 중 하나인 RDS 블루/그린 배포 생성 내용 입니다.

사용 방법은 AWS Docs에 자세히 적혀있으니, 저는 RDS 블루/그린 배포 생성을 진행해보며 있었던 이슈 사항에 대해 적어보려 합니다.

개요

RDS 블루/그린 배포는 프로덕션 환경(블루)을 복사하는 스테이징 환경(그린)을 만듭니다.

스테이징 RDS 환경이 생성되는 동안은 논리적 복제를 사용하여 현재 프로덕션 환경과 계속 동기화 됩니다.

그린 환경이 생성되면 새로운 프로덕션 환경으로 승격할 수 있고, 일반적으로 승격되는 시간은 1분 이내 입니다.

(이 때 순단 발생) / (승격이 되면 블루 환경으로 다시 돌아갈 수 없습니다.)

블루/그린 배포 전 필수 작업 사항

파라미터 수정

파라미터	값	미변경 시
binlog_format	OFF -> ROW	그린DB 생성 불가	블루DB/그린DB 모두 변경 필요
event_scheduler	ON -> OFF	그린DB 생성 후, 블루DB <-> 그린DB 전환 불가	그린DB만 변경해도 됨

블루DB 프로시저 정리

MySQL 5.7에서 8.0으로 업그레이드할 때 발생하는 구문 불일치 문제가 있어 프로시저를 정리해야함. (미작업 시 그린DB 생성 불가)

첫 번째 이슈 (블루/그린 배포 생성 실패)

(원인 : 불필요 프로시저 = 불필요 SQL)

MySQL 5.7에서 동작하는 프로시저 SQL 구문이 MySQL 8.0에서는 동작하지 않아, 그린 DB 생성이 불가한 경우가 있었습니다.

에러 로그는 아래처럼 발생합니다.

[클러스터 로그]
Failed to provision due to upgrade incompatibilities. See https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.mysql80-upgrade-procedure.html#AuroraMySQL.mysql80-upgrade-troubleshooting to resolve these issues, then delete and recreate this Blue/Green Deployment.
# MySQL 5.7에서 8.0으로 업그레이드할 때 발생하는 구문 불일치 문제
 
[DB 로그]
{
  "id": "routinesSyntaxCheck",
  "title": "MySQL 8.0 syntax check for routine-like objects",
  "status": "OK",
  "description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
    {
      "level": "Error",
      "dbObject": "charging.pSubTotal_DailySalesStatus",
      "description": "at line 117,28: unexpected token ''월화수목금토일"
    }
  ]
}

다국어 문자열 처리: 다국어 문자열이 직접적으로 프로시저에 사용되면서 MySQL 8.0의 새로운 구문 분석 규칙에 맞지 않는 경우 발생할 수 있습니다.
인용 및 이스케이프 필요: 한글 문자열에 대해 적절한 인용(quote) 또는 이스케이프 처리가 필요할 수 있습니다.

두 번째 이슈 (블루/그린 배포 생성 후 전환 실패)

(원인 : event_scheduler 파라미터)

그린 DB 생성 후, 블루DB ↔ 그린DB 전환이 실패하는 경우가 있었습니다.

처음에는 그린DB 생성 중 블루DB에 쌓이는 데이터 차이 때문이라고 생각했었는데요,

그런데 이건 생각해보니 블루DB에서 그린DB로 논리적 복제가 이루어지기 때문에 원인이 아닐거라고 판단할 수 있었고,

AWS 독스에서 제약사항을 읽고 DB 로그를 통해 문제를 해결할 수 있었습니다.

[클러스터 로그]
Switchover from DB cluster elecar-core-aurora-testdb-cluster to elecar-core-aurora-testdb-cluster-green-4c1oms was cancelled due to replication errors on elecar-core-aurora-testdb-cluster-green-4c1oms. Correct the replication errors and then switch over.
# 블루/그린 배포 전환이 복제 오류로 인해 취소되었습니다. 이는 그린 클러스터에서 레플리케이션이 제대로 이루어지지 않았음을 의미합니다.)
 
[라이터 인스턴스 로그]
Read Replica Replication Error - SQLError: 1062, reason: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' at source log mysql-bin-changelog.000007, end_log_pos 100338508. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
# 에러 코드 1062는 일반적으로 Duplicate Entry(중복된 키 값) 오류입니다. 레플리케이션이 진행되는 동안 중복된 데이터가 삽입되려고 했기 때문에 복제 프로세스가 중단되었습니다.
# 이로 인해 복제 작업의 코디네이터가 중단되었습니다. 더 많은 정보를 확인하려면 performance_schema.replication_applier_status_by_worker 테이블을 확인해야 합니다.

event_scheduler의 영향

데이터 충돌 가능성 : 이벤트 스케줄러가 활성화되어 있는 경우, 자동으로 실행되는 이벤트가 데이터 변경 작업을 수행할 수 있습니다. 이로 인해 레플리케이션 시 중복된 데이터 삽입이 발생하여 1062 Duplicate Entry 오류가 발생할 수 있습니다.
복제 일관성 문제 : 스케줄된 이벤트가 마스터와 레플리카 간의 데이터 일관성을 해칠 수 있습니다. 특히, 블루/그린 전환 시점에서 데이터 동기화가 깨질 수 있습니다.

event_scheduler Off로 변경 후

이벤트 실행 중지: 스케줄러가 자동으로 실행하는 이벤트가 중지되면서, 불필요한 데이터 변경 작업이 중단됩니다.
데이터 충돌 방지: 스케줄러에 의해 생성된 중복된 트랜잭션이 제거되어 Duplicate Entry 오류가 해결됩니다.
복제 안정성 향상: 스케줄러에 의해 발생하는 비동기 작업이 제거되어 복제 프로세스가 더 안정적으로 진행됩니다.

정리

버튼 하나로 기존 프로덕션 환경과 데이터가 동일하고 버전업된 그린 DB를 편하게 만들 수 있습니다. 이후 전환은 1~2분 밖에 소요되지 않아 편합니다.
프로덕션 환경(블루DB)에서 스테이징 환경(그린DB)으로 자동 복제가 가능해 프로덕션 환경에 영향을 주지 않고 스테이징 환경에서 테스트가 가능합니다.
각 Account마다 환경이 다르니, 작업 전 AWS에서 작성한 독스의 제한 사항을 꼼꼼히 읽고 진행해야 합니다.
- https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html
단점은 블루DB ↔ 그린DB 전환 시, 원복은 불가능 합니다
- https://aws.amazon.com/ko/rds/faqs/
AWS 콘솔 상에서 원복이 불가능하므로, 원복 방안은 다음과 같을 수 있겠습니다
- 개발단의 DB 엔드포인트를 old가 붙은 블루 DB 엔드포인트로 변경합니다.
- 작업 전 생성한 스냅샷으로 복원합니다.
- 새로운 데이터가 쌓여있는 경우, 일부 데이터를 버리거나 변경된 데이터를 찾아 재반영하는 작업을 진행합니다.
  (https://aws.amazon.com/ko/blogs/tech/amazon-rds-mysql-blue-green-after-restoring/)

기린의 System Engineering 노트

AWS RDS 블루/그린 배포 생성

시작

개요

블루/그린 배포 전 필수 작업 사항

첫 번째 이슈 (블루/그린 배포 생성 실패)

두 번째 이슈 (블루/그린 배포 생성 후 전환 실패)

정리

티스토리툴바