다운타임을 최소화하는 RDS 블루/그린 마이그레이션
1줄 요약
Aurora MySQL 메이저/LTS 업그레이드 시 원본 파라미터 그룹의 binlog_format=MIXED 사전 적용(재부팅 필수) 후 RDS 블루/그린 배포를 활용하면 1분 내외의 초단기 다운타임으로 안전하게 전환할 수 있다.
1. 인시던트 및 업그레이드 배경
운영 중인 AWS Aurora MySQL 클러스터의 마이너 버전 EOS(End of Support)가 도래하여, 향후 안정적인 기술 지원과 보안 패치를 보장받기 위해 LTS(Long-Term Support, Aurora MySQL 3.x) 버전으로의 마이그레이션이 요구되었다.
가장 중요한 목표는 24/7 서비스 운영 중 다운타임을 1분 이내로 최소화하고, 검증 실패 시 즉시 롤백 가능한 안전장치를 확보하는 것이었다.
[블루/그린 전환 아키텍처]
[Blue (기존 Prod)] ──(binlog 복제)──> [Green (신규 LTS)]
│ │
(DNS 스위칭) ──────────────────────────> (새로운 Prod 승격)2. 핵심 전제 조건: binlog_format 사전 활성화
RDS 블루/그린 배포는 블루 환경의 변경 사항을 MySQL 논리적 복제(binlog)로 그린 환경에 실시간 반영한다. 기본적으로 Aurora는 성능 최적화를 위해 binlog가 비활성화(OFF)되어 있으므로, 배포 생성 전에 파라미터 그룹 수정이 선행되어야 한다.
# 대상: 블루(원본) 클러스터 파라미터 그룹
# binlog_format 변경 (Static 파라미터)
binlog_format = MIXED주의 (Static Parameter)
binlog_format은 Static 파라미터이므로 변경 후 DB 인스턴스 재부팅이 필수이다. 반드시 실제 배포 작업 전 사전 유지보수 윈도우에 재부팅을 완료해 두어야 한다.
3. 단계별 마이그레이션 실행 절차
1) 블루/그린 배포 생성
AWS 콘솔 또는 CLI에서 원본 클러스터를 대상으로 블루/그린 배포 생성을 시작한다.
- AWS가 자동으로 블루 환경 스냅샷을 생성하여 대상 LTS 버전의 그린 클러스터를 프로비저닝함.
- 스냅샷 복원 시점부터 블루의
binlog를 읽어와 데이터 동기화(Replication)를 실시간 유지함. - 이 작업은 수십 분이 소요되지만 원본 서비스에는 일체 부하를 주지 않음.
2) 그린 환경 격리 검증
그린 클러스터는 전용 엔드포인트를 가지므로, 프로덕션 트래픽 영향 없이 애플리케이션의 신규 버전 호환성 쿼리 및 성능 테스트를 완벽히 수행할 수 있다.
3) 전환 (Switchover)
검증이 끝나면 Switchover를 트리거한다.
- 블루 환경 쓰기(Write) 일시 차단
- 잔여
binlog이벤트를 그린 환경에 100% 동기화 (Data Consistency 보장) - 원본 엔드포인트의 DNS CNAME 레코드를 그린 클러스터로 자동 스왑
- 그린 클러스터가 메인 프로덕션으로 승격되어 트래픽 처리 개시
4) 사후 정리 및 롤백 대비
전환 직후 구(舊) 블루 환경은 삭제되지 않고 대기 상태로 유지된다. 서비스가 정상 안정화된 것을 확인한 후 수동으로 삭제하여 불필요한 인스턴스 비용을 정리한다.
4. 핵심 체크포인트 (Gotchas)
binlog_format재부팅 타이밍: 배포 당일 재부팅하면 예기치 않은 서비스 순단을 겪을 수 있으므로 며칠 전 미리 파라미터 그룹을 수정하고 재부팅해 두어야 한다.- 복제 지연(Replication Lag): Switchover 실행 전 CloudWatch에서
AuroraBinlogReplicaLag지표가 0초에 수렴하는지 반드시 확인해야 스위치오버 소요 시간을 1분 미만으로 줄일 수 있다. - 트리거 및 외부 외래키 점검: 그린 환경 생성 전 MySQL 엔진별 호환되지 않는 스토어드 프로시저나 트리거 설정이 없는지 사전 점검이 필요하다.
게시된 시간: 2026-07-28 09:03:17수정한 시간: 2026-08-15 13:57:00