블루/그린 배포 전환

전환은 그린 환경에 있는 DB 클러스터를 자체 DB 인스턴스와 함께 프로덕션 DB 클러스터로 승격합니다. 전환하기 전에는 프로덕션 트래픽이 블루 환경의 클러스터로 라우팅됩니다. 전환한 후에는 프로덕션 트래픽이 그린 환경의 DB 클러스터로 라우팅됩니다.

블루/그린 배포로의 전환은 블루/그린 배포 내에서 그린 DB 클러스터를 승격하는 것과 다릅니다. 작업 메뉴에서 승격을 선택하여 그린 DB 클러스터를 수동으로 승격하는 경우 블루 환경과 그린 환경 간의 복제가 중단되고 블루/그린 배포가 잘못된 구성 상태로 전환됩니다.

전환 제한 시간

30초에서 3,600초(1시간) 사이의 전환 제한 시간을 지정할 수 있습니다. 전환이 지정된 기간보다 오래 걸린다면, 모든 변경 사항이 롤백되고 어느 환경도 변경되지 않습니다. 기본 제한 시간은 300초(5분)입니다.

전환 가드레일

전환을 시작하면 Amazon RDS는 몇 가지 기본 검사를 실행하여 블루 및 그린 환경이 전환 준비가 되었는지 테스트합니다. 이러한 검사를 전환 가드레일이라고 합니다. 이러한 전환 가드레일은 환경이 준비되지 않았다면 전환이 진행되지 않게 합니다. 따라서 예상보다 긴 다운타임을 방지하고, 전환이 시작되면 발생할 수 있는 블루 및 그린 환경 간의 데이터 손실을 방지할 수 있습니다.

Amazon RDS는 그린 환경에서 다음 가드레일 검사를 실행합니다.

Amazon RDS는 블루 환경에서 다음 가드레일 검사를 실행합니다.

전환 작업

블루/그린 배포로 전환하면 RDS는 다음 작업을 수행합니다.

Amazon EventBridge를 사용하여 전환 상태를 모니터링할 수 있습니다. 자세한 내용은 블루/그린 배포 이벤트 단원을 참조하십시오.

블루 환경에서 태그를 구성했다면 이러한 태그는 전환 중에 새 프로덕션 환경으로 복사됩니다. 태그에 대한 자세한 내용은 Amazon Aurora 및 Amazon RDS 리소스에 태그 지정 단원을 참조하세요.

어떤 이유로든 전환이 시작된 후 종료되기 전에 중지되면, 모든 변경 사항이 롤백되고 두 환경 모두 변경되지 않습니다.

전환 모범 사례

전환하기 전에 다음 작업을 완료하여 모범 사례를 준수하는 것이 좋습니다.

전환 전 CloudWatch 지표 확인

블루/그린 배포를 전환하기 전에 Amazon CloudWatch 내에서 다음 지표를 확인하는 것이 좋습니다.

이러한 지표에 대한 자세한 내용은 Amazon Aurora에 대한 Amazon CloudWatch 지표 섹션을 참조하세요.

전환 전 복제 지연 모니터링

블루/그린 배포를 전환하기 전에 가동 중지 시간을 줄이기 위해 그린 데이터베이스의 복제 지연이 0에 가까운지 확인합니다.

블루/그린 배포로의 전환

AWS Management Console, AWS CLI 또는 RDS API를 사용하여 블루/그린 배포로 전환할 수 있습니다.

aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --switchover-timeout 600

aws rds switchover-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --switchover-timeout 600

전환 후

전환한 후에는 이전 블루 환경의 DB 클러스터 및 DB 인스턴스가 유지됩니다. 이러한 리소스에는 표준 요금이 적용됩니다. 블루와 그린 환경 간의 복제 및 바이너리 로깅이 중지됩니다.

RDS는 블루 환경의 DB 클러스터 및 DB 인스턴스의 현재 이름에 -oldn을 추가하여 이름을 변경합니다(n은 숫자입니다). DB 클러스터는 강제로 읽기 전용 상태가 됩니다. DB 클러스터에서 read_only 파라미터를 비활성화하더라도 블루/그린 배포를 삭제하기 전까지는 읽기 전용으로 유지됩니다. RDS는 그린 환경 -newn에서 DB 클러스터 및 DB 인스턴스의 이름을 지정합니다.

블루/그린 배포 리소스를 삭제하면 RDS는 -oldn 및 -newn 리소스를 유지합니다.

소비자를 위한 상위 노드 업데이트

Aurora MySQL 블루/그린 배포로 전환한 후, 블루 DB 클러스터에 전환 이전의 외부 복제본 또는 이진 로그 소비자가 있었던 경우, 전환 후에 상위 노드를 업데이트해야 복제 연속성을 유지할 수 있습니다.

전환 후 이전에 그린 환경에 있었던 라이터 DB 인스턴스는 마스터 로그 파일 이름 및 마스터 로그 위치가 포함된 이벤트를 내보냅니다. 예:

aws rds describe-events --output json --source-type db-instance --source-identifier db-instance-identifier

{
    "Events": [
...
        {
            "SourceIdentifier": "db-instance-identifier",
            "SourceType": "db-instance",
            "Message": "Binary log coordinates in green environment after switchover:
             file mysql-bin-changelog.000003 and position 804",
            "EventCategories": [],
            "Date": "2023-11-10T01:33:41.911Z",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:db-instance-identifier"
        }
    ]
}

먼저 소비자 또는 복제본이 이전 블루 환경의 모든 이진 로그를 적용했는지 확인하세요. 그런 다음 제공된 이진 로그 좌표를 사용하여 소비자에 대한 적용을 재개하세요. 예를 들어, EC2에서 MySQL 복제본을 실행하는 경우 CHANGE MASTER TO 명령을 사용할 수 있습니다.

CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=804;