RDS Proxy와 ProxySQL의 AWS Blue/Green Deployments Switchover 지원

아마존 AWS 클라우드 9월 3, 2026 0
Share

Last Updated on 9월 3, 2026 by Jade(정현호)

AWS RDS Blue/Green Deployments(이하 BGD)는 운영 중인 DB(Blue)와 동일한 복제본(Green)을 별도로 띄워두고, Green에서 엔진 업그레이드나 스키마 변경을 먼저 검증한 뒤 트래픽을 한 번에 넘기는(Switchover) 방식입니다.

AWS가 이 전환 과정 자체(복제 catch-up, write 정지, 이름 교체)는 대신해주지만, 중요한 애플리케이션이 "언제 새 writer로 다시 연결해야 하는지"는 여전히 클라이언트 쪽 문제로 남아 있었습니다.

전통적으로는 DNS가 새 인스턴스를 가리키도록 전파될 때까지 기다리는 수밖에 없었고, 또한 Blue와 Green의 인스턴스(또는 클러스터 엔드포인트 URL)이 서로 변경되는 대기 시간이 곧 애플리케이션이 체감하는 다운타임이었습니다.

BGD 전환시 다운타임이나 쓰기 불가 등의 지연시간에 대해서 단축하고자 하는 기능이 Proxy에서 BGD 지원 기능이 추가되고 있습니다.

대표적으로 AWS RDS Proxy는 2026년 4월 BGD 지원을 발표했고, ProxySQL은 2026년 7월 v3.0.10부터 관련 기능을 정식으로 추가했습니다. 이번 글에서는 두 프록시가 각각 BGD 전환 정보를 어떻게 얻고, 그 정보로 클라이언트 연결을 어떻게 유지시켜주는지를 테스트와 함께 정리해 보도록 하겠습니다.

1. AWS RDS Blue/Green Deployments 개요

AWS Blue/Green Deployments는 운영 클러스터(Blue)의 물리 복제본(Green)을 만들고, Green에서 엔진 버전 업그레이드나 파라미터 변경을 먼저 적용해 검증한 뒤, 준비가 끝나면 Switchover 명령으로 트래픽을 Green으로 넘기는 기능입니다. Switchover는 대략 다음 순서로 진행됩니다.

단계 작업
Guardrail 검사 Blue, Green이 전환 가능한 상태인지 확인
양쪽 환경 write 중지 두 환경 모두 primary에 신규 write 차단
연결 drop + 신규 연결 차단 양쪽 DB 인스턴스 연결 종료
복제 catch-up 대기 Green이 Blue를 따라잡아 동기화될 때까지 대기
Rename Green을 Blue 이름으로, Blue는 -oldN으로 endpoint 변경
연결 허용 양쪽 DB에 연결 재허용
New prod에 write 허용 구 prod(현 Blue)는 읽기 전용으로 남기고, 재부팅 전까지 읽기만 허용

여기서 핵심은 Rename 단계입니다. Green이 Blue의 이름을 넘겨받는 방식이라, 클라이언트 입장에서는 원래 접속하던 호스트명이 그대로 유지됩니다.

문제는 이 이름이 가리키는 실제 IP가 바뀌는 순간, 클라이언트(또는 그 앞의 커넥션 풀)가 들고 있던 기존 TCP 연결과 DNS 캐시가 곧바로 갱신되지 않는다는 데 있습니다. 물론 도메인명이 서로 변경되는 그 시간도 짧지만 존재하며, 이 "이름은 그대로인데 실체가(IP주소가) 바뀌는" 시점의 공백을 얼마나 줄여주느냐가 이번 글에서 비교할 두 프록시의 핵심 차이입니다.

2. AWS RDS Proxy의 BGD 지원

2.1 지원 시점 및 버전

Amazon RDS Blue/Green Deployments가 Amazon RDS Proxy를 지원한다는 발표는 2026년 4월 9일에 나왔습니다. Aurora MySQL/PostgreSQL 호환, RDS for MySQL/PostgreSQL/MariaDB에서 사용 가능하며(모든 상용 리전), Aurora Global Database는 지원 대상에서 제외됩니다. 드라이버나 애플리케이션 코드 변경 없이 적용됩니다.

해당 기능을 사용하기 위해서는 다음과 같은 준비조건이 있습니다.

  • Blue/Green Deployments를 생성하기 전에, Blue 클러스터를 RDS Proxy에 먼저 등록해둬야 합니다.
  • 버전 조건 : Aurora MySQL 기준으로 토폴로지 감지가 실제로 동작하려면 Aurora MySQL 3.07 이상이어야 합니다. AWS 공식 릴리스 노트에 따르면, 이전 버전에서는 BGD switchover 이후 SERVER_ID 값이 갱신되지 않아 AWS JDBC Driver 같은 스마트 드라이버가 클러스터 토폴로지를 제대로 발견하지 못하는 문제가 있었고, 이 문제는 Aurora MySQL 3.07부터 수정되어 switchover 시 SERVER_ID가 정상적으로 갱신된다는 내용이 있습니다.
  • Green 인스턴스 엔진 버전이 3.07 이상부터 mysql.rds_topology 딕셔너리 테이블에 BGD 정보가 갱신되며 뒤에서 다룰 ProxySQL 프록시에서 해당 딕셔너리를 통해 BGD 토폴로지를 확인합니다.

2.2 동작 방식

RDS Proxy가 있을 때 Switchover는 다음과 같이 진행됩니다.

단계 작업 애플리케이션 영향
BGD 생성 시 Green 환경을 자동 인식하고 상태 감시 시작(고객 설정 작업 없음) 변화 없음
Guardrail 프록시가 Blue·Green 양쪽에 도달 가능한지 추가 검증 실패 시 전환이 진행되지 않음
Read-only 프록시는 계속 Blue로 라우팅 write는 1290, read는 정상
Green 승격 약 1초 주기 감시로 새 writer를 감지 → 즉시 Green으로 라우팅 DNS 전파 없이 복구
Rename 접속 주소(RDS Proxy Endpoint)가 그대로 유지되어 DNS 재해석 불필요 Stale DNS 구간 없음

핵심은 RDS Proxy가 DNS에 의존하지 않는다는 점입니다. 프록시 자신이 DB 인스턴스 상태를 직접 감시하다가 새 writer를 감지하면 곧바로 그쪽으로 라우팅을 바꾸고, 클라이언트가 바라보는 주소(프록시 엔드포인트) 자체는 전환 전후로 전혀 바뀌지 않습니다. 클라이언트 쪽 DNS 캐시가 낡은 값을 들고 있을 여지 자체가 없는 구조입니다.

2.3 Switchover 테스트 — RDS Proxy 사용 유무

RDS Proxy 없이(직접 접속) 전환했을 때

  • read-only 구간(약 2-3초): write만 실패(1290), read는 정상
  • 접속 불가 구간(Error 2003, 약 12-13초): write, read 모두 실패
  • 복구: DNS가 새 DB로 바뀐 직후(약 1초)
  • 해석: write가 총 약 15-17초간 불가능했고, 그중 대부분(약 12-13초)은 접속 자체가 안 되는 구간(전환 중 DNS가 아직 옛 DB를 가리키는 구간으로 해석됨)
  • 해당 시간은 2026년 1월 경 BGD 자체의 전환 속도 개선이 반영된 전환시간이고 그 전에는 Switchover에 다소 더 많이 소요되었습니다.

RDS Proxy를 통해 접속했을 때

  • read-only 구간(43:09, errno 1290 발생): write만 실패, read는 정상
  • 연결 끊김 구간(Error 2013, 약 3초): write만 실패, read는 여전히 정상
  • 복구: 새 writer 감지 직후(43:13) INSERT 즉시 성공
  • 해석: write가 총 약 4초간만 불가능했고, 접속 자체가 완전히 안 되는 구간은 전혀 없었음. read는 전 구간 정상.

가장 크게 줄어든 부분은 "완전 접속 불가" 구간(약 12-13초 → 0초)입니다. RDS Proxy 없이는 read조차 안 되는 완전한 블랙아웃 구간이 있었지만, RDS Proxy를 거치면 이 구간이 통째로 사라지고 read는 전환 내내 끊김 없이 유지됩니다. write 다운타임도 약 15-17초에서 4초로 큰 폭으로 줄었습니다.

이렇게 다운타임이 크게 줄어드는 이유는 전환 감지와 라우팅 갱신이 클라이언트 쪽 DNS 조회 과정을 아예 거치지 않기 때문입니다. RDS Proxy 없이 직접 접속하는 경우에는 Rename 이후 클라이언트(또는 그 앞단의 OS Resolv)가 바뀐 이름의 새 IP를 다시 조회해서 캐시를 갱신할 때까지 기다려야 하고, 이 DNS 조회·전파·캐시 만료 대기 시간이 앞서 본 "완전 접속 불가" 구간의 대부분을 차지합니다. 반면 RDS Proxy는 이름 조회 결과에 의존하지 않습니다.

프록시 자신이 Blue/Green 상태를 직접 감시하다가 새 writer를 인지하는 즉시 자신의 내부 라우팅 대상만 바꿔치기하므로, 클라이언트 입장에서는 DNS 관련 대기 시간 자체가 구조적으로 발생하지 않습니다. 다운타임이 15-17초에서 4초로 줄어든 차이는 결국 이 DNS 조회 대기 시간이 통째로 사라진 결과로 볼 수 있습니다.

3. ProxySQL의 BGD 지원

3.1 지원 시작 시점 및 버전

ProxySQL은 v3.0.10(3.1.10 / 4.0.10과 동시 릴리스, 2026년 7월 31일)부터 AWS RDS Blue/Green Deployments 지원을 정식으로 추가했습니다. 관련 기능은 PR #5861("Add support for AWS Multi-AZ Instance blue/green Deployment", 2026-07-29 머지)로 도입되었고, mysql.rds_topology 테이블을 모니터링해 Multi-AZ Blue/Green 전환을 실시간으로 따라가는 방식입니다.

새 hostgroup 자동 발견, 대상 주소 DNS pin, 기존 writer에서 커넥션 제거, 전환 완료/롤백 여부와 무관한 정리 작업까지 포함합니다.

다만 v3.0.10의 정식 BGD 기능은 mysql_replication_hostgroups 기반 등록을 전제로 설계되어 있고, Aurora 클러스터에서 널리 쓰이는 mysql_aws_aurora_hostgroups 기반 등록에 대한 지원은 별도로 진행 중입니다. 이 작업은 PR #6044("feat: add AWS Aurora blue/green Deployments support")에서 다루고 있으며, Aurora MySQL에서도 BGD가 지원되도록 계속 진행 중인 상태입니다.

3.2 동작 방식

ProxySQL은 mysql_aws_rds_bgd_hostgroups라는 설정 테이블을 기준으로 별도 워커 스레드가 mysql.rds_topology를 주기적으로 조회하며 다음 상태를 따라갑니다.

AVAILABLE → WRITER_SWITCHOVER_INITIATED → WRITER_SWITCHOVER_IN_PROGRESS
  → WRITER_SWITCHOVER_POST_PROCESSING → WRITER_SWITCHOVER_COMPLETED
  → READER_SWITCHOVER_IN_PROGRESS → SWITCHOVER_COMPLETED → NONE

POST_PROCESSING 단계에서 blue 호스트명을 미리 알아낸 green IP로 pin하고 기존 커넥션을 drain하는데, 이 부분이 RDS Proxy의 "DNS 없이 직접 라우팅"과 같은 역할을 합니다. 등록 방식은 두 가지입니다.

  • 자동(auto) 모드: mysql.rds_topology에서 Blue/Green 토폴로지를 감지하면 mysql_aws_rds_bgd_hostgroups 행을 자동 생성
  • 명시(explicit) 모드: green_writer_hostgroup/green_reader_hostgroup을 직접 지정해 등록

3.3 Switchover 테스트 — RDS for MySQL(Source + Read Replica)

RDS for MySQL의 Source 인스턴스 1개 + Read Replica 1개 상태에서 Blue/Green Deployments를 구성하여 테스트를 진행했습니다.

테스트 과정에서 다음과 같은 조건으로 진행하였습니다.

  • Green writer(hostgroup 3), Green reader(hostgroup 4)를 switchover 전에 mysql_servers에 미리 수동으로 등록하였습니다.
  • green writer는 auto-discovery가 되어 runtime_mysql_servers에서 확인되었지만 green reader 인스턴스가 확인이 되지 않아 mysql_servers에 green 인스턴스 2개를 모두 등록했습니다.
  • green reader는 mysql.rds_topology에 정보 자체가 없어 자동 등록이 안 되는 것을 코드 상으로 확인할 수 있었습니다.

Source(Writer) 와 Replica(Read Replica)로 접속하여 insert와 조회를 반복해서 테스트하였으며 switchover 수행시 로그 기준 타임라인은 다음과 같습니다.

  • 47분:00초 : 구 writer/reader로 INSERT 성공
  • 47분:01초 : (로그 없음 — 이 구간에 전환 발생)
  • 47분:02초 : 신규 green writer/reader로 INSERT 즉시 성공, 이후 실패 없음

실측 다운타임은 총 약 1-2초였고, 전체 ProxySQL 로그에서 확인되는 실질적인 에러는 "Hostgroup 1 has no servers available!" 단 한 줄뿐이었습니다. writer와 reader가 같은 시점에 동시에 전환됐고, BGD Status 정보도 AVAILABLE → ... → SWITCHOVER_COMPLETED → NONE까지 상태 정보를 정확하게 확인하였고 Switchover 진행 상태에 따라서 잘 처리하였습니다.

3.4 Aurora MySQL 개발 버전 테스트

진행하면서 같이 Aurora MySQL도 추가로 테스트를 해보았습니다. 테스트는 ProxySQL 공식 저장소의 PR #6044("feat: add AWS Aurora blue/green Deployment support") 브랜치를 기준으로 직접 빌드한 버전을 사용했습니다. 아직 개발진행중인 PR이고 아직 머지되지 않은 버전입니다.

blue/green 두 인스턴스(-01/-02)를 auto-discovery에 의존하지 않고 mysql_servers에 처음부터 정적으로 등록하고, mysql_aws_aurora_hostgroups·mysql_aws_rds_bgd_hostgroups에도 green_writer_hostgroup/green_reader_hostgroup을 명시적으로 등록한 뒤 실제 AWS Blue/Green Switchover를 수행했습니다.

INSERT 반복 실행 로그 기준 타임라인은 다음과 같습니다.

  • 35분:31초 마지막 정상 INSERT
  • 35분:32초~35분:33초 read-only 에러(errno=1290) 2회 — writer가 강등되는 정상 과정
  • 35분:33초~35분:54초(약 21초) 접속 자체가 완전히 끊기는 구간(write, read 모두 실패)
  • 35분:54초 새 writer/reader IP로 즉시 재개, 이후 실패 없음

테스트 시 write 다운타임은 총 약 22-23초였습니다. 아직 개발이 진행 중인 버전이다 보니, 몇 가지 부족한 부분도 함께 확인됐습니다. reader 쪽은 green reader를 사전에 등록해둔 덕분에 별도의 지연 없이 정상적으로 전환됐지만, writer 쪽 전환에 관여하는 매핑 로직에는 아직 구조적인 문제가 남아 있습니다. 개발 진행 중임으로 정식 출시시 지금보다 많은 변화나 개선이 있을 것으로 예상되며 정식 출시까지 기다려봐야할 것 같습니다.

4. Conclusion

AWS Blue/Green Deployments는 RDS의 버전 업그레이드나 여러 작업에 대해서 복제 인스턴스 생성 및 전환 방식을 통해 빠르게 적용하는 기능입니다.

Blue 와 Green 인스턴스간의 전환 시간은 BGD 기능이 출시된 이후에도 전환 시간을 감소시키기 위한 개선을 진행되었습니다. 그만큼 BGD에서 Blue 와 Green 인스턴스간의 매끄럽고 보다 적은 다운타임은 BGD 를 사용하는 부분에서 매우 중요한 부분이었습니다.

Switchover 를 진행하는데 있어서 RDS Proxy와 ProxySQL이 기능 지원을 하기 시작하였고 그에 따라서 사용하였을때 많은 개선점을 확인할 수 있었습니다.

RDS Proxy를 사용했을 때는 write 다운타임이 약 4초 수준에 그칠 정도로 다운타임이 크게 줄었고, 완전 접속 불가 구간 자체도 없었습니다.

ProxySQL은 v3.0.10부터 RDS for MySQL 대상으로 BGD를 정식 지원합니다. Source + Read Replica 구성으로 테스트한 결과 다운타임은 약 1-2초였고, 로그에 남은 에러도 한 줄뿐이었습니다.

RDS Proxy와 ProxySQL 모두 BGD Switchover 시 다운타임 소요가 기존에 비해 상당히 많이 줄어든 것을 확인할 수 있었으며 BGD를 통한 변경작업이나 업그레이드시에 RDS Proxy 또는 ProxySQL을 사용을 고려해보는 것도 좋은 방법이라고 생각됩니다.

Reference

연관된 다른 글

AWS RDS 블루-그린 배포를 통한 스토리지 볼륨 축소 - Shrink storage volumes
AWS RDS Blue/Green Deployment에서 새롭게 추가된 Storage 볼륨 축소 기능에 대해서 설명하고 있습니다.
PostgreSQL MVCC와 XID Wraparound - 튜플 가시성, XID 비교, VACUUM FREEZE의 동작 원리
PostgreSQL의 MVCC 동작 원리와 튜플 가시성, XID 비교, XID Wraparound, VACUUM FREEZE의 관계 내용을 다룹니다.
MySQL 8.4 LTS 변경 내역 - Changes in MySQL 8.4.0
포스팅 글에서는 MySQL 8.4 LTS 버전 출시에 관련된 내용과 8.4 LTS 버전에서 변경된 점에 대해서 다루고 있습니다.
MySQL 8 MHA and ProxySQL on RockyLinux 8 - 4번째 글
이번글은 RockyLinux 8 과 MySQL 8 환경에서 MHA 구성과 설정 그리고 ProxySQL을 연계하여 구성하는 내용에 대해서 기술되어 있습니다.

 

Tags:

You may also like...

Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
0
글에 대한 당신의 생각을 기다립니다. 댓글 의견 주세요!x