Amazon RDS Blue/Green 배포를 사용한 Amazon Aurora PostgreSQL 업그레이드에 대한 롤백 전략 구현

이 글은 AWS Database Blog에 게시된 Implement a rollback strategy for Amazon Aurora PostgreSQL upgrades using Amazon RDS Blue/Green deployments by Chirag Dave, Kovan Chandra, Daxeshkumar Patel, Kamal Singh, and Jinesh Shah를 한국어 번역 및 편집하였습니다.

Amazon Aurora PostgreSQL-Compatible Edition은 고성능과 가용성을 위해 설계된 완전 관리형 관계형 데이터베이스 엔진입니다. 관리형 Blue/Green 배포를 지원하여 업데이트 중 다운타임을 줄이고 위험을 최소화합니다. Blue/Green 배포는 논리적 복제를 통해 완전 관리형 스테이징 환경을 구축하여, 프로덕션 변경 사항을 안전하게 배포하고 테스트할 수 있도록 지원합니다. Blue 환경은 현재 프로덕션 데이터베이스를 나타내며, Green 환경은 애플리케이션 엔드포인트를 수정하지 않고도 필요한 업데이트 또는 변경 사항을 포함할 수 있는 환경을 나타냅니다. 이러한 접근 방식은 엔진 버전 업그레이드나 시스템 패치와 같은 업데이트와 관련된 위험과 다운타임을 최소화합니다. 검증이 완료되면 그린 환경을 프로덕션 환경으로 원활하게 승격시켜 애플리케이션 엔드포인트를 변경하지 않고 유지할 수 있습니다.

비프로덕션 환경에서 철저한 계획을 수립해 테스트를 수행하더라도 버전 업그레이드 후 예상치 못한 문제가 발생할 수 있습니다. 예를 들어, 새로운 스키마 변경은 스테이징 환경에서는 완벽하게 작동하지만 실제 데이터 패턴의 차이나 테스트 과정에서 검증되지 않은 애플리케이션 쿼리로 인해 프로덕션 환경에서 오류가 발생할 수 있습니다. 또한 실제 트래픽 및 워크로드로 인해 성능 저하가 발생할 수도 있습니다. 이러한 경우 서비스 안정성을 신속하게 복원하기 위해 롤백 계획을 수립하는 것이 중요합니다. 관리형 Blue/Green 배포 기능에는 현재 기본 롤백 기능이 포함되어 있지 않지만, 버전 관리를 위한 대체 솔루션을 구현할 수 있습니다.

이 게시물에서는 Amazon RDS Blue/Green 배포 전환 후 최신 버전과의 동기화를 유지하기 위해 자체 관리형 논리적 복제를 사용하여 롤백 클러스터를 수동으로 설정하는 방법을 보여줍니다. 롤백 클러스터는 원래 버전으로 되돌려야 할 때 백업 옵션으로 사용할 수 있습니다.

솔루션 개요

다음 다이어그램은 이 솔루션에 대한 전체적인(high-level) 워크플로우를 보여줍니다.

전환 전에는 두 개의 클러스터가 있습니다.

Blue 클러스터 – 이전 프로덕션 데이터베이스 클러스터
Green 클러스터 – Blue 클러스터에서 미러링 및 동기화된 스테이징 환경

전환 후에는 세 개의 클러스터가 있습니다.

이전 Blue 클러스터 – 이전 프로덕션 클러스터
새 Blue 클러스터 – 워크로드가 실행될 새 버전의 프로덕션 클러스터(이전 Green 클러스터)
Blue Prime(롤백) 클러스터 – 이전 Blue 클러스터의 복제본이며 새 Blue 클러스터 데이터와 동기화됨(롤백 클러스터로 사용됨)

워크플로우 단계는 다음과 같습니다.

Blue/Green 배포 생성
Blue 클러스터의 트래픽을 중지하고 그린 클러스터로 전환 수행
Blue/Green 배포 삭제
이전 Blue 클러스터를 복제하여 Blue Prime(롤백) 클러스터 생성
새 Blue 클러스터에서 Blue Prime(롤백) 클러스터로의 논리적 복제 설정
새 Blue 클러스터로의 트래픽 시작

이 게시물에서는 Amazon Aurora PostgreSQL-Compatible Edition의 주요 버전을 15.10에서 16.6으로 업그레이드하는 과정을 시뮬레이션합니다.

제한 사항

Aurora 관리형 Blue/Green 배포는 DDL 복제, 시퀀스, 구체화된 뷰 갱신, 대용량 객체 생성 또는 수정, 기본 키가 없는 테이블의 데이터 업데이트 및 삭제를 수행하지 않습니다. 자세한 내용은 Blue/Green 배포에 대한 제한 사항 및 고려 사항을 참조하세요.
Aurora 관리형 Blue/Green 배포는 전환 후 기본 클러스터 엔드포인트를 자동으로 관리하지만, 이전 버전으로 롤백해야 하는 경우 애플리케이션 또는 DNS 수준에서 엔드포인트 변경 사항을 처리해야 합니다.
롤백 클러스터를 설정하면 추가 다운타임이 발생합니다.

사전 요구 사항

솔루션을 구현하려면 다음 구성 요소가 필요합니다.

Blue/Green 배포 지원 – 이전 Aurora 클러스터 버전이 Blue/Green 배포를 지원하는지 확인합니다. 자세한 내용은 “데이터베이스 업데이트에 Amazon RDS 블루/그린 배포 사용” 및 “Amazon Aurora PostgreSQL 및 Amazon RDS for PostgreSQL의 새로운 완전 관리형 Blue/Green 배포“를 참조하세요.
소스 데이터베이스 클러스터(이 게시물의 Aurora PostgreSQL v15)에서 논리적 복제를 활성화합니다.
필요한 경우 Blue/Green 배포를 지원하는 버전으로 일회성 마이너 버전 업그레이드를 수행합니다.
AWS CLI

참고 : 논리적 복제 매개변수를 활성화하려면 작성자 인스턴스를 재부팅해야 합니다. 자세한 내용은 “Aurora PostgreSQL DB 클러스터에서 논리적 복제 사용“을 참조하십시오.

새로운 버전 데이터베이스에 대한 클러스터 매개변수 그룹: 새로운 버전에서 이전 버전으로의 논리적 복제를 설정할 예정이므로 새로운 버전(Aurora PostgreSQL 16)에 논리적 복제가 활성화되어 있는지 확인해야 합니다. 다음 AWS CLI 명령은 클러스터 매개변수 그룹을 생성하고 논리적 복제 매개변수를 활성화합니다.

aws rds create-db-cluster-parameter-group \
--db-cluster-parameter-group-name pg16-blue-green \
--db-parameter-group-family aurora-postgresql16 \
--description "Parameter group that contains logical replication settings for Aurora PG 16"

aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name pg16-blue-green \
--parameters "ParameterName='rds.logical_replication',ParameterValue=1,ApplyMethod=pending-reboot"

Aurora 복제 기능을 이해하려면 “Amazon Aurora DB 클러스터의 볼륨 복제“를 참조하세요.

Blue/Green 배포 생성

Amazon RDS Blue/Green 배포는 AWS의 관리형 서비스입니다. 백그라운드에서 Blue 환경의 리소스를 생성하여 Green 환경으로 미러링하고, 엔진 네이티브 논리적 복제를 사용하여 Blue 환경의 DML 변경 사항을 Green 환경으로 복제합니다.

AWS 명령줄 인터페이스(AWS CLI)에서 다음 명령을 사용하여 RDS Blue/Green 배포를 생성할 수 있습니다. 여기서 소스는 소스 프로덕션 데이터베이스의 Amazon 리소스 이름(ARN)입니다. 다음 RDS 콘솔 스크린샷은 논리적 복제가 활성화된 기존 클러스터(Blue 클러스터)를 보여줍니다.

다음 명령을 사용하여 Amazon Aurora PostgreSQL 버전 16에서 Green 클러스터를 사용하여 Blue/Green 배포를 생성합니다. Green 클러스터는 이전에 논리적 복제를 활성화해 둔 파라미터 그룹에 연결되어야 합니다.

aws rds create-blue-green-deployment \
--blue-green-deployment-name my-blue-green-deployment \
--source arn:aws:rds:{REGION}:{ACCOUNT_NUMBER}:cluster:{CLUSTER_ID} \
--target-engine-version 16.6 \
--target-db-cluster-parameter-group-name pg16-blue-green

모든 인스턴스를 사용할 수 있게 되면 Blue 및 Green 클러스터가 모두 연결된 Blue/Green 배포가 이루어집니다.

트래픽 중지 후 전환 수행

Green 클러스터를 승격하려면 전환(switchover) 작업을 시작해야 합니다. 전환을 시작하기 전에 Blue 클러스터의 데이터베이스 트래픽을 중지하여 Blue Prime(롤백) 클러스터 생성 중 데이터 일관성을 유지하십시오. VPC 보안 그룹을 사용하여 인바운드 및 아웃바운드 데이터베이스 트래픽을 차단할 수 있습니다. 전환이 완료된 후 RDS Blue/Green 배포에서 업데이트된 레이블을 확인하십시오.

aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier {BG_RESOURCE_ID} \
--switchover-timeout "300"

Blue/Green 배포 삭제

Blue Prime(롤백) 클러스터를 구성하기 전에 Blue/Green 배포를 삭제해야 합니다. RDS Blue/Green 배포를 삭제하면 클러스터가 관리형 환경에서 해제되고 Amazon RDS Blue/Green 배포에서 생성된 복제 슬롯, 게시, 구독 및 논리적 복제 구성 요소와 같은 객체가 삭제됩니다.

aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier {BG_RESOURCE_ID}\
--no-delete-target

다음 스크린샷에서 볼 수 있듯이 이제 우리는 두 개의 독립적인 클러스터인 apg-blue-green-demo(v16.6)와 apg-blue-green-demo-old1(v15.10)을 가지고 있습니다.

새 Blue를 복제하여 Blue Prime(롤백) 클러스터 생성

규정 준수 및 감사 목적으로 원본 Blue 클러스터를 유지해야 할 수 있습니다. 롤백 클러스터를 설정하려면 다음을 수행합니다.

이전 Blue 클러스터를 복제하여 자체 관리형 Blue Prime(롤백) 클러스터를 생성합니다.
클러스터가 준비되면 복제된 클러스터에서 간단한 읽기 전용 쿼리를 실행하여 클러스터 및 데이터 접근성을 확인합니다.
롤백이 필요할 경우 DNS 또는 애플리케이션 엔드포인트 업데이트를 위해 Blue Prime(롤백) 클러스터 엔드포인트를 문서화합니다.

aws rds restore-db-cluster-to-point-in-time \
--db-cluster-identifier "apg15-blue-prime" \
--restore-type copy-on-write \
--use-latest-restorable-time \
--source-db-cluster-identifier "apg-blue-green-demo-old1" \
--db-subnet-group-name "{DB_SUBNET}" \
--vpc-security-group-ids "{VPC_SECUITY_GROUP}" \
--db-cluster-parameter-group-name "pg15-blue-green"

aws rds create-db-instance \
--db-instance-identifier "apg15-blue-prime" \
--db-instance-class "db.r6g.large" \
--db-cluster-identifier "apg15-blue-prime" \
--engine "aurora-postgresql" \
--engine-version "15.10"

다음 스크린샷에서 볼 수 있듯이 롤백 대상으로 사용될 새로 복원된 클러스터 ‘apg15-blue-prime’을 만들었습니다.

Blue Prime(롤백) 클러스터 설정

Blue Prime 복제본 생성을 완료한 후, 새 Blue 클러스터(게시자, publisher)에서 Blue Prime 클러스터(구독자, subscriber)로 자체 관리형 논리적 복제를 구성합니다. 데이터 동기화 문제를 방지하기 위해 쓰기 작업 및 스키마 변경은 허용되지 않습니다.

1. 새 Blue 클러스터(게시자, publisher)에서 클러스터 엔드포인트를 사용하여 데이터베이스에 연결하고 새 게시를 생성합니다.

CREATE PUBLICATION publication_name FOR ALL TABLES;

중요: 각 테이블에 복제 ID(예: 기본 키 또는 고유 키)가 있는지 확인하세요. 동일한 클러스터에 여러 데이터베이스가 있는 경우, 새로 승격된 프로덕션 클러스터(새로운 Blue)의 각 데이터베이스에 대해 다음 단계를 반복하세요.

2. 새로운 Blue 클러스터(게시자, publisher)의 클러스터 엔드포인트에 연결하고 다음 명령을 통해 ‘pgoutput’ 플러그인을 사용하여 복제 슬롯을 만듭니다.

SELECT pg_create_logical_replication_slot('replication_slot_name', 'pgoutput');

3. Blue Prime 클러스터(구독자, subscriber)에서 다음 명령을 사용하여 데이터를 복사하거나 새 슬롯을 만들지 않고 새 구독을 만듭니다.

CREATE SUBSCRIPTION subscription_name
CONNECTION 'postgres://admin_user_name:admin_user_password@source_instance_URL/database' PUBLICATION publication_name
WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = 'replication_slot_name');

이 코드에는 아래 파라미터들이 필요합니다.

subscription_name – 구독 이름입니다.
admin_user_name – rds_superuser 권한이 있는 관리자의 이름입니다.
admin_user_password – 관리자와 연결된 비밀번호입니다.
source_instance_URL – 게시 서버 인스턴스의 URL입니다.
database – 구독 서버가 연결할 데이터베이스입니다.
publication_name – 게시 서버 이름입니다.
replication_slot_name – 2단계에서 생성한 복제 슬롯의 이름입니다.

중요: Blue Prime 클러스터의 모든 게시(1단계)에 대해 이 작업을 반복해야 합니다.

4. Blue Prime 클러스터에서 다음 명령을 사용하여 구독을 활성화합니다.

ALTER SUBSCRIPTION subscription_name ENABLE;

중요: Blue Prime 클러스터의 모든 구독에 대해 이 활동을 반복해야 합니다.

논리적 복제 설정을 완료하고 새로운 Blue에서 Blue Prime 클러스터로의 데이터 흐름을 확인한 후, 이전 클러스터 엔드포인트를 사용하여 새로운 Blue 클러스터로의 트래픽을 재개할 수 있습니다. Amazon RDS 관리형 Blue/Green 배포는 DNS 변경 사항을 자동으로 처리하므로 애플리케이션에서 동일한 엔드포인트를 사용할 수 있습니다.

Blue Prime 클러스터로 롤백

Blue Prime 클러스터(이전 버전)로 롤백해야 하는 경우 다음 단계를 따르세요.

전환 중 데이터 무결성을 유지하기 위해 애플리케이션 트래픽을 중단합니다(Amazon Aurora VPC 보안 그룹을 사용하여 수신 트래픽을 차단할 수 있습니다).
Blue Prime 클러스터 엔드포인트를 가리키도록 애플리케이션 또는 DNS 레코드를 업데이트합니다.
Blue Prime 클러스터에서 구독을 삭제합니다.
해당하는 경우 시퀀스 값을 수동으로 업데이트합니다.

Blue Prime 클러스터가 더 이상 관리형 서비스에 속하지 않으므로 이 전환은 자동으로 수행되지 않습니다. 실행 중 오류를 최소화하기 위해 롤백 작업에 대한 문서 또는 자동화 스크립트를 생성하는 것이 좋습니다.

이 전략은 롤백 옵션을 제공하지만 Blue Prime 클러스터 설정 시 추가적인 다운타임이 발생합니다. 이는 이 접근 방식을 구현할 때 고려해야 할 사항이며, 프로덕션으로 전환하기 전에 스테이징 단계에서 철저하게 테스트하는 것이 좋습니다.

정리

운영 환경의 경우, 모든 애플리케이션이 성공적으로 전환되었는지 확인하는 동시에 새로운 Blue Prime 클러스터를 유지 관리해야 합니다. 두 환경을 동시에 유지하면 새 인프라에서 일관되지 않거나 예기치 않게 작동하는 경우 롤백할 수 있습니다. 규정 준수를 위해 이전 Blue 클러스터를 백업한 후, 비용을 절감하기 위해 클러스터를 삭제할 수 있습니다. 삭제될 때까지 모든 클러스터에 대한 요금이 부과됩니다.

테스트 목적으로 이러한 리소스를 생성한 경우, 추가 요금이 발생하지 않도록 모든 클러스터(Blue, Green, Blue Prime)를 삭제해야 합니다. 데이터베이스 클러스터를 정리하려면 다음 단계를 완료하세요.

결론

이 게시물에서는 Amazon RDS Blue/Green 배포를 사용하여 데이터베이스 버전 업그레이드를 수행할 때 롤백 전략을 만드는 방법을 설명했습니다. 안전성을 높이기 위해 논리적 복제를 롤백 전략으로 구성했습니다. Blue/Green 배포는 미러링되고 동기화된 데이터베이스 스테이징 버전 생성, 가드레일 검사 수행, 전환 수행, DNS 변경 자동화와 같은 여러 복잡한 작업을 자동으로 처리합니다. 그러나 프로덕션 데이터베이스 변경에는 애플리케이션 비호환성과 같은 위험이 수반될 수 있습니다. 롤백 클러스터를 구성하면 업그레이드 후 문제가 발생할 경우 신속하게 복구할 수 있는 안전성을 확보할 수 있습니다. 문제가 해결될 때까지 이전 프로덕션 버전으로 되돌릴 수 있습니다.

프로덕션 워크로드를 전환하기 전에 프로덕션 수준의 부하에서 새 데이터베이스 버전에 대해 애플리케이션을 철저히 테스트하십시오. 애플리케이션이 완벽하게 호환되고 성능이 안정적으로 유지되는지 확인하십시오. 이렇게 하면 Blue/Green 배포 전환 후 애플리케이션 문제 또는 성능 저하 가능성이 크게 줄어듭니다. 이 롤백 전략을 구현하기 전에 RDS 관리형 Blue/Green 배포의 작동 방식과 기능을 살펴보는 것이 좋습니다.

AWS 기술 블로그