Aurora용 Amazon RDS 블루/그린 배포 개요

Amazon RDS 블루/그린 배포를 사용하면 프로덕션 환경에서 구현하기 전에 데이터베이스를 변경하고 테스트할 수 있습니다. 블루/그린 배포는 프로덕션 환경을 복사하는 스테이징 환경을 만듭니다. 블루/그린 배포에서는 블루 환경이 현재 프로덕션 환경입니다. 그린 환경은 스테이징 환경입니다. 스테이징 환경은 논리적 복제를 사용하여 현재 프로덕션 환경과 계속 동기화됩니다.

프로덕션 워크로드에 영향을 주지 않고 그린 환경에서 Aurora DB 클러스터를 변경할 수 있습니다. 예를 들어 메이저 또는 마이너 DB 엔진 버전을 업그레이드하거나 스테이징 환경에서 데이터베이스 파라미터를 변경할 수 있습니다. 그린 환경의 변경 사항을 철저하게 테스트할 수 있습니다. 준비가 되면 환경을 전환하여 그린 환경을 새로운 프로덕션 환경으로 승격할 수 있습니다. 전환은 일반적으로 1분도 걸리지 않으며 데이터 손실이 발생하지 않고 애플리케이션을 변경할 필요도 없습니다.

그린 환경은 프로덕션 환경 토폴로지의 복사본이므로, DB 클러스터와 DB 클러스터의 모든 DB 인스턴스가 배포 시 복사됩니다. 그린 환경에는 DB 클러스터 스냅샷, 성능 개선 도우미와 확장 모니터링 같은 DB 클러스터에서 사용하는 기능도 포함됩니다Aurora Serverless v2.

참고

블루/그린 배포는 Aurora MySQL 및 Aurora PostgreSQL에서 지원됩니다. Amazon RDS 가용성에 대해서는 Amazon RDS 사용 설명서의 데이터베이스 업데이트에 Amazon RDS 블루/그린 배포 사용을 참조하세요.

리전 및 버전 사용 가능 여부

기능 가용성 및 해당 지원은 각 데이터베이스 엔진의 특정 버전 및 AWS 리전 리전에 따라 다릅니다. 자세한 내용은 블루/그린 배포를 지원하는 리전 및 Aurora DB 엔진 단원을 참조하십시오.

Amazon RDS 블루/그린 배포 사용의 장점

Amazon RDS 블루/그린 배포를 사용하면 보안 패치를 최신 상태로 유지하고, 데이터베이스 성능을 개선할 수 있으며 짧고 예측 가능한 다운타임으로 최신 데이터베이스 기능을 채택할 수 있습니다. 블루/그린 배포를 통해 메이저 또는 마이너 엔진 버전 업그레이드와 같이 데이터베이스 업데이트로 인해 발생가능한 리스크 및 다운타임을 줄일 수 있습니다.

블루/그린 배포는 다음과 같은 장점을 제공합니다.

• 프로덕션 준비가 된 스테이징 환경을 쉽게 만들 수 있습니다.

• 데이터베이스 변경 사항을 프로덕션 환경에서 스테이징 환경으로 자동으로 복제합니다.

• 프로덕션 환경에 영향을 주지 않고 안전한 스테이징 환경에서 데이터베이스 변경 사항을 테스트합니다.

• 데이터베이스 패치 및 시스템 업데이트로 최신 상태를 유지하세요.

• 새로운 데이터베이스 기능을 구현하고 테스트합니다.

• 애플리케이션을 변경하지 않고도 스테이징 환경을 새 프로덕션 환경으로 전환합니다.

• 내장된 전환 가드레일을 사용하여 안전하게 전환합니다.

• 전환 중 데이터 손실이 발생하지 않습니다.

• 워크로드에 따라 대부분 1분 이내에 빠르게 전환합니다.

블루/그린 배포 워크플로우

Aurora DB 클러스터 업데이트에 블루/그린 배포를 사용한다면 다음 주요 단계를 완료하십시오.

1. 업데이트가 필요한 프로덕션 DB 클러스터를 식별합니다.

   다음 이미지에서는 프로덕션 DB 클러스터 예시를 확인할 수 있습니다.

   

2. 블루/그린 배포 생성 지침은 블루/그린 배포 생성 섹션을 참조하세요.

   다음 이미지는 1단계에서 설명하는 프로덕션 환경의 블루/그린 배포 예시입니다. 블루/그린 배포를 생성하는 동안, RDS는 Aurora DB 클러스터의 전체 토폴로지 및 구성을 복사하여 그린 환경을 만듭니다. 복사된 DB 클러스터 및 DB 인스턴스 이름 뒤에는 -green-random-characters가 추가됩니다. 이미지의 스테이징 환경에는 DB 클러스터(auroradb-green-abc123)가 있습니다. 또한 DB 클러스터에서는 DB 인스턴스 3개가 있습니다(auroradb-instance1-green-abc123, auroradb-instance2-green-abc123 및 auroradb-instance3-green-abc123).

   

   블루/그린 배포를 생성하는 도중 더 높은 DB 엔진 버전을 지정하고, 그린 환경에 있는 DB 클러스터에 다른 DB 클러스터 파라미터 그룹을 지정할 수 있습니다. DB 클러스터의 DB 인스턴스에 다른 DB 파라미터 그룹을 지정할 수 있습니다.

   또한 RDS는 블루 환경의 기본 DB 인스턴스에서 그린 환경의 기본 DB 인스턴스로의 복제를 구성합니다.

   중요

   Aurora MySQL 버전 3의 경우 블루/그린 배포를 생성하면 그린 환경의 DB 클러스터는 기본적으로 쓰기 작업을 허용합니다. read_only 파라미터를 1로 설정하고 클러스터를 재부팅하여 DB 클러스터를 읽기 전용으로 만드는 것이 좋습니다.

3. 스테이징 환경에 변경 사항을 적용합니다.

   예를 들어 데이터베이스의 스키마를 변경하거나 그린 환경에 있는 하나 이상의 DB 인스턴스에서 사용하는 DB 인스턴스 클래스를 변경할 수 있습니다.

   DB 클러스터 수정에 대한 자세한 내용은 Amazon Aurora DB 클러스터 수정 섹션을 참조하세요.

4. 스테이징 환경을 테스트합니다.

   테스트하는 동안에는 그린 환경의 데이터베이스를 읽기 전용으로 유지하는 것이 좋습니다. 복제 충돌이 발생할 수 있으므로 그린 환경에서 쓰기 작업을 사용 설정하세요. 전환 후 프로덕션 데이터베이스에 의도하지 않은 데이터가 저장될 수도 있습니다. Aurora MySQL에서 쓰기 작업을 활성화하려면 read_only 파라미터를 0으로 설정한 다음 DB 인스턴스를 재부팅합니다. Aurora PostgreSQL의 경우 default_transaction_read_only 파라미터를 세션 수준에서 off로 설정합니다.

5. 준비가 되면 전환하여 그린 환경을 새로운 프로덕션 환경으로 승격합니다. 지침은 블루/그린 배포 전환 섹션을 참조하세요.

   전환하면 다운타임이 발생하게 됩니다. 다운타임은 보통 1분 미만이지만 워크로드에 따라 더 길어질 수 있습니다.

   다음 이미지는 전환 이후의 DB 클러스터를 보여줍니다.

   

   전환 후에는 그린 환경의 Aurora DB 클러스터가 새로운 프로덕션 DB 클러스터가 됩니다. 현재 프로덕션 환경의 이름과 엔드포인트가 새로 승격된 프로덕션 환경에 할당되므로, 애플리케이션을 변경할 필요가 없습니다. 따라서 이제 프로덕션 트래픽이 새 프로덕션 환경으로 이동합니다. 이전 블루 환경의 DB 클러스터와 DB 인스턴스는 현재 이름에 -oldn이 추가됩니다(여기서 n은 숫자입니다). 예를 들어 블루 환경의 DB 인스턴스 이름이 auroradb-instance-1이라고 가정하겠습니다. 전환이 끝나면 DB 인스턴스 이름은 auroradb-instance-1-old1이 됩니다.

   이미지의 예시에서는 전환 중에 다음과 같은 변경 사항이 발생합니다.

   • 그린 환경 DB 클러스터 auroradb-green-abc123가 auroradb라는 프로덕션 DB 클러스터가 됩니다.

   • 이름이 auroradb-instance1-green-abc123인 그린 환경 DB 인스턴스가 이름이 auroradb-instance1인 프로덕션 DB 클러스터가 됩니다.

   • 이름이 auroradb-instance2-green-abc123인 그린 환경 DB 인스턴스가 이름이 auroradb-instance2인 프로덕션 DB 클러스터가 됩니다.

   • 이름이 auroradb-instance3-green-abc123인 그린 환경 DB 인스턴스가 이름이 auroradb-instance3인 프로덕션 DB 클러스터가 됩니다.

   • 이름이 auroradb인 블루 환경 DB 클러스터가 auroradb-old1이 됩니다.

   • 이름이 auroradb-instance1인 블루 환경 DB 인스턴스가 auroradb-instance1-old1이 됩니다.

   • 이름이 auroradb-instance2인 블루 환경 DB 인스턴스가 auroradb-instance2-old1이 됩니다.

   • 이름이 auroradb-instance3인 블루 환경 DB 인스턴스가 auroradb-instance3-old1이 됩니다.

6. 블루/그린 배포가 더 이상 필요하지 않다면 삭제해도 됩니다. 지침은 블루/그린 배포 삭제 섹션을 참조하세요.

   전환 후에도 이전 프로덕션 환경이 삭제되지 않으므로, 필요하다면 회귀 테스트에 사용할 수 있습니다.

블루/그린 배포 작업에 대한 액세스 권한 부여

사용자는 블루/그린 배포와 관련된 작업을 수행하는 데 필요한 권한이 있어야 합니다. 지정된 리소스에서 특정 API 태스크를 수행할 수 있는 권한을 사용자와 역할에게 부여하는 IAM 정책을 생성할 수 있습니다. 그런 다음 해당 권한이 필요한 IAM 권한 세트 또는 역할에 이러한 정책을 연결할 수 있습니다. 자세한 내용은 Amazon Aurora의 자격 증명 및 액세스 관리 단원을 참조하십시오.

블루/그린 배포를 만드는 사용자는 다음 RDS 작업을 수행할 권한이 있어야 합니다.

• rds:AddTagsToResource

• rds:CreateDBCluster

• rds:CreateDBInstance

• rds:CreateDBClusterEndpoint

블루/그린 배포로 전환하는 사용자는 다음 RDS 작업을 수행할 권한이 있어야 합니다.

• rds:ModifyDBCluster

• rds:PromoteReadReplicaDBCluster

블루/그린 배포를 삭제하는 사용자는 다음 RDS 작업을 수행할 권한이 있어야 합니다.

• rds:DeleteDBCluster

• rds:DeleteDBInstance

• rds:DeleteDBClusterEndpoint

Aurora는 사용자를 대신하여 스테이징 환경에서 리소스를 프로비저닝하고 수정합니다. 이러한 리소스에는 내부적으로 정의된 명명 규칙을 사용하는 DB 인스턴스가 포함됩니다. 따라서 연결된 IAM 정책에는 my-db-prefix-*와 같은 부분적인 리소스 이름 패턴이 포함될 수 없습니다. 와일드카드(*)만 지원됩니다. 일반적으로 와일드카드 대신 리소스 태그와 기타 지원되는 속성을 사용하여 이러한 리소스에 대한 액세스를 제어하는 것이 좋습니다. 자세한 내용은 Amazon RDS에 사용되는 작업, 리소스 및 조건 키를 참조하세요.

블루/그린 배포 관련 고려 사항

Amazon RDS는 각 리소스의 DbiResourceId 및 DbClusterResourceId를 사용하여 블루/그린 배포의 리소스를 추적합니다. 이 리소스 ID는 AWS 리전별로 고유한, 리소스의 변경 불가능한 식별자입니다.

다음과 같이 리소스 ID는 DB 클러스터 ID와 다릅니다.

블루/그린 배포로 전환하면 리소스 이름(클러스터 ID)이 변경되지만, 각 리소스는 동일한 리소스 ID를 유지합니다. 예를 들어 DB 클러스터 식별자는 블루 환경에서는 mycluster입니다. 전환이 끝나면 동일한 DB 인스턴스의 이름이 mycluster-old1으로 변경됩니다. 하지만 DB 클러스터의 리소스 ID는 전환 중에 변경되지 않습니다. 따라서 그린 리소스가 새 프로덕션 리소스로 승격되면, 관련 리소스 ID는 이전에 프로덕션에 있었던 블루 리소스 ID와 일치하지 않게 됩니다.

블루/그린 배포로 전환한 후에는, 리소스 ID를 프로덕션 리소스와 함께 사용한 통합형 기능 및 서비스를 위해 새로 승격된 프로덕션 리소스의 ID로 업데이트하는 것을 고려해 보십시오. 구체적으로는 다음 업데이트를 고려해 보십시오.

• RDS API 및 리소스 ID를 사용하여 필터링을 수행할 경우, 전환 후 필터링에 사용한 리소스 ID를 조정하세요.

• 리소스 감사에 CloudTrail을 사용한다면, 전환 후 새 리소스 ID를 추적하도록 CloudTrail의 소비자를 조정하십시오. 자세한 내용은 AWS CloudTrail에서 Amazon Aurora API 호출 모니터링 단원을 참조하십시오.

• 블루 환경의 리소스에 데이터베이스 활동 스트림을 사용한다면, 전환 후 새 스트림에 대한 데이터베이스 이벤트를 모니터링하도록 애플리케이션을 조정하십시오. 자세한 내용은 데이터베이스 활동 스트림을 지원하는 리전 및 Aurora DB 엔진 단원을 참조하십시오.

• Performance Insights API를 사용한다면, 전환 후 API 호출의 리소스 ID를 조정하십시오. 자세한 내용은 성능 개선 도우미를 통한 Amazon Aurora 모니터링 단원을 참조하십시오.

  전환 후 동일한 이름의 데이터베이스를 모니터링할 수 있지만, 전환 전의 데이터는 포함되지 않습니다.

• IAM 정책에서 리소스 ID를 사용한다면, 필요한 경우 새로 승격된 리소스의 리소스 ID를 추가해야 합니다. 자세한 내용은 Amazon Aurora의 자격 증명 및 액세스 관리 단원을 참조하십시오.

• DB 클러스터와 연결된 IAM 역할이 있는 경우 전환 후 해당 역할을 다시 연결해야 합니다. 연결된 역할은 그린 환경으로 자동 복사되지 않습니다.

• IAM 데이터베이스 인증을 사용하여 DB 클러스터를 인증하는 경우, 데이터베이스 액세스에 사용되는 IAM 정책의 Resource 요소 아래에 블루 데이터베이스와 그린 데이터베이스가 모두 나열되어 있는지 확인하세요. 이는 전환 후 그린 데이터베이스에 연결하기 위해 필요합니다. 자세한 내용은 IAM 데이터베이스 액세스를 위한 IAM 정책 생성 및 사용 단원을 참조하십시오.

• 블루/그린 배포의 일부였던 DB 클러스터의 수동 DB 클러스터 스냅샷을 복원하려면, 스냅샷을 촬영한 시간을 확인하여 올바른 DB 클러스터 스냅샷을 복원해야 합니다. 자세한 내용은 DB 클러스터 스냅샷에서 복원 단원을 참조하십시오.

• Amazon Aurora는 블루 환경에서 기본 Aurora 스토리지 볼륨을 복제하여 그린 환경을 만듭니다. 그린 클러스터 볼륨은 그린 환경에 대한 증분 변경만 저장합니다. 블루 환경의 DB 클러스터를 삭제하면 그린 환경의 기본 Aurora 스토리지 볼륨 크기가 최대 크기로 커집니다. 자세한 내용은 Aurora DB 클러스터에 대한 볼륨 복제 단원을 참조하십시오.

• 블루/그린 배포의 그린 환경에 있는 DB 인스턴스에 DB 인스턴스를 추가하면, 새 DB 인스턴스는 전환할 때 블루 환경의 읽기 전용 복제본을 대체하지 않습니다. 하지만 새 DB 인스턴스는 DB 클러스터에 유지되며 새 프로덕션 환경에서는 DB 인스턴스가 됩니다.

• 블루/그린 배포의 그린 환경에 있는 DB 클러스터에서 DB 인스턴스를 삭제하면, 블루/그린 배포에서 이를 대체할 새 DB 인스턴스를 만들 수 없습니다.

  삭제된 DB 인스턴스와 동일한 이름 및 ARN으로 새 DB 인스턴스를 생성하면, DbiResourceId가 다르기 때문에 그린 환경에 속하지 않게 됩니다.

  그린 환경의 DB 클러스터에서 DB 인스턴스를 삭제하면 다음과 같은 동작이 발생합니다.

  • 블루 환경에 이름이 같은 DB 인스턴스가 있는 경우, 이 인스턴스는 그린 환경의 DB 인스턴스로 전환되지 않습니다. 이 DB 인스턴스는 DB 인스턴스 이름에 -oldn을 추가하여 이름이 바뀌지 않습니다.

  • 블루 환경의 DB 인스턴스를 가리키는 모든 애플리케이션은 전환 후에도 동일한 DB 인스턴스를 계속 사용합니다.

블루/그린 배포 모범 사례

다음은 블루/그린 배포 모범 사례입니다.

일반 모범 사례

• 전환하기 전에 Aurora DB 클러스터를 철저하게 테스트합니다.

• 그린 환경에서 데이터베이스를 읽기 전용으로 유지합니다. 복제 충돌이 발생할 수 있으므로 그린 환경에서 쓰기 작업을 사용 설정할 때는 신중해야 합니다. 전환 후 프로덕션 데이터베이스에 의도하지 않은 데이터가 저장될 수도 있습니다.

• 블루/그린 배포를 사용하여 스키마 변경을 구현할 때는 복제와 호환되는 변경만 적용합니다.

  예를 들어 블루 배포에서 그린 배포로의 복제를 중단하지 않고 테이블 끝에 새 열을 추가할 수 있습니다. 그러나 열 이름 변경이나 테이블 이름 변경 같은 스키마 변경은 그린 배포로의 복제 중단을 유발합니다.

  복제 호환 변경 사항에 대한 자세한 내용은 MySQL 설명서의 소스 및 복제본에서 서로 다른 테이블 정의를 사용하는 복제 및 PostgreSQL 논리적 복제 설명서의 제한 사항을 참조하세요.

• 두 환경의 모든 연결에 클러스터 엔드포인트, 리더 엔드포인트 또는 사용자 지정 엔드포인트를 사용합니다. 정적 또는 제외 목록과 함께 인스턴스 엔드포인트나 사용자 지정 엔드포인트를 사용하지 않습니다.

• 블루/그린 배포로 전환할 때는 전환 모범 사례를 따르세요. 자세한 내용은 전환 모범 사례 단원을 참조하십시오.

Aurora PostgreSQL 모범 사례

• Aurora PostgreSQL 논리적 복제 라이트-스루 캐시를 모니터링하고 필요한 경우 캐시 버퍼를 조정합니다. 자세한 내용은 Aurora PostgreSQL 논리적 복제 라이트-스루 캐시 관리 단원을 참조하십시오.

• 데이터베이스에 사용 가능한 메모리가 충분할 경우 블루 환경에서 logical_decoding_work_mem DB 파라미터 값을 늘립니다. 이렇게 하면 디스크 디코딩이 줄어들고 대신 메모리가 사용됩니다. FreeableMemory CloudWatch 지표로 여유 메모리를 모니터링할 수 있습니다. 자세한 내용은 Amazon Aurora에 대한 Amazon CloudWatch 지표 단원을 참조하십시오.

• 블루/그린 배포를 생성하기 전에 모든 PostgreSQL 확장을 최신 버전으로 업데이트합니다. 자세한 내용은 PostgreSQL 확장 버전 업그레이드 단원을 참조하십시오.

• aws_s3 확장을 사용하는 경우 그린 환경이 생성된 후 IAM 역할을 통해 그린 DB 클러스터에 Amazon S3에 대한 액세스 권한을 부여해야 합니다. 이렇게 하면 전환 후에도 가져오기 및 내보내기 명령이 계속 작동합니다. 지침은 Amazon S3 버킷에 대한 액세스 권한 설정 섹션을 참조하세요.

• 그린 환경에 더 높은 엔진 버전을 지정하는 경우 모든 데이터베이스에서 ANALYZE 작업을 실행하여 pg_statistic 테이블을 새로 고칩니다. 옵티마이저 통계는 메이저 버전 업그레이드 중에 전송되지 않으므로 성능 문제를 방지하려면 모든 통계를 다시 생성해야 합니다. 메이저 버전 업그레이드 중 추가 모범 사례에 대해 알아보려면 메이저 버전 업그레이드를 수행하는 방법 섹션을 참조하세요.

• 데이터를 조작하기 위해 트리거를 소스에 사용하는 경우 트리거를 ENABLE REPLICA 또는 ENABLE ALWAYS로 구성하지 마세요. 이렇게 구성하면 복제 시스템이 변경 내용을 전파하고 트리거를 실행하므로 중복이 발생합니다.

• 트랜잭션이 오래 실행되면 심각한 복제 지연이 발생할 수 있습니다. 복제 지연을 줄이려면 다음과 같이 해 보세요.

  • 그린 환경이 블루 환경을 따라잡을 때까지 지연될 수 있는 장기 실행 트랜잭션을 줄이세요.

  • 블루/그린 배포를 생성하기 전에 사용량이 많은 테이블에서 수동 vacuum freeze 작업을 시작하세요.

  • PostgreSQL 버전 12 이상의 경우, 크거나 사용량이 많은 테이블에서 index_cleanup 파라미터를 비활성화하여 블루 데이터베이스의 일반 유지 관리 속도를 높이세요.

• 복제 속도가 느리면 발신자와 수신자가 자주 다시 시작되어 동기화가 지연될 수 있습니다. 이들의 활성 상태를 유지하려면 블루 환경에서는 wal_sender_timeout 파라미터를 0으로 설정하고 그린 환경에서는 wal_receiver_timeout 파라미터를 0으로 설정하여 시간 초과를 비활성화하세요.

블루/그린 배포 관련 제한 사항

블루/그린 배포에는 다음과 같은 제한 사항이 적용됩니다.

주제

• 블루/그린 배포 관련 일반 제한 사항
• 블루/그린 배포를 위한 PostgreSQL 확장 제한
• 블루/그린 배포 변경 관련 제한 사항
• 블루/그린 배포를 위한 PostgreSQL 논리적 복제 제한

블루/그린 배포 관련 일반 제한 사항

블루/그린 배포에는 다음과 같은 일반 제한 사항이 적용됩니다.

• Aurora MySQL 버전 2.08 및 2.09는 업그레이드 소스 또는 대상 버전으로 지원되지 않습니다.

• 블루/그린 배포의 일부인 클러스터는 중지 및 시작이 불가능합니다.

• 블루/그린 배포의 경우 AWS Secrets Manager에서 마스터 사용자 암호 관리를 지원하지 않습니다.

• 역추적이 활성화된 Aurora MySQL 소스 DB 클러스터에서 블루/그린 배포를 생성하는 경우 역추적 지원 없이 그린 DB 클러스터가 생성됩니다. 블루/그린 배포에 필요한 이진 로그(binlog) 복제본에서는 역추적이 작동하지 않기 때문입니다. 자세한 내용은 Aurora DB 클러스터 역추적 단원을 참조하십시오.

  블루 DB 클러스터를 강제로 역추적하려고 하면 블루/그린 배포가 중단되고 전환이 차단됩니다.

• Aurora MySQL의 경우 소스 DB 클러스터에는 이름이 tmp인 데이터베이스가 포함될 수 없습니다. 이 이름을 가진 데이터베이스는 그린 환경으로 복사되지 않습니다.

• Aurora PostgreSQL의 경우, 블루 DB 클러스터에서 rds.logically_replicate_unlogged_tables 파라미터가 1로 설정되어 있지 않으면 로깅되지 않은 테이블이 그린 환경으로 복제되지 않습니다. 블루/그린 배포를 생성한 후에는 로깅되지 않은 테이블에서 발생할 수 있는 복제 오류를 방지하기 위해 이 파라미터 값을 수정하지 않는 것이 좋습니다.

• Aurora PostgreSQL의 경우 블루 환경 DB 클러스터는 자체 관리형 논리적 소스(게시자) 또는 복제본(구독자)이 될 수 없습니다. Aurora MySQL의 경우 블루 환경 DB 클러스터는 외부 binlog 복제본이 될 수 없습니다.

• 전환 중에는 블루 및 그린 환경을 Amazon Redshift와 제로 ETL로 통합할 수 없습니다. 먼저 통합을 삭제하고 전환한 다음 통합을 다시 생성해야 합니다.

• 블루/그린 배포를 생성할 때는 그린 환경에서 Event Scheduler(event_scheduler 파라미터)를 비활성화해야 합니다. 이렇게 하면 그린 환경에서 이벤트가 생성되어 불일치가 발생하는 것을 방지할 수 있습니다.

• 블루 DB 클러스터에 정의된 Aurora Auto Scaling 정책은 그린 환경으로 복사되지 않습니다.

• 블루/그린 배포는 MySQL용 AWS JDBC 드라이버를 지원하지 않습니다. 자세한 내용은 GitHub의 Known Limitations를 참조하세요.

• 블루/그린 배포는 다음 기능에는 지원되지 않습니다.

  • Amazon RDS 프록시

  • 리전 간 읽기 전용 복제본

  • Aurora Serverless v1 DB 클러스터

  • Aurora 글로벌 데이터베이스의 일부인 DB 클러스터

  • Babelfish for Aurora PostgreSQL

  • AWS CloudFormation

블루/그린 배포를 위한 PostgreSQL 확장 제한

PostgreSQL 확장에는 다음과 같은 제한 사항이 적용됩니다.

• 블루/그린 배포를 만들 때는 블루 환경에서 pg_partman 확장을 비활성화해야 합니다. 확장은 블루 환경에서 그린 환경으로의 논리적 복제를 중단하는 CREATE TABLE과 같은 DDL 작업을 수행합니다.

• 블루/그린 배포를 생성한 후에는 모든 그린 데이터베이스에서 pg_cron 확장을 비활성화한 상태로 유지해야 합니다. 확장에는 슈퍼유저로 실행되고 그린 환경의 읽기 전용 설정을 우회하는 백그라운드 작업자가 있어 복제 충돌이 발생할 수 있습니다.

• 블루 환경에서 동일한 계획을 캡처하는 경우 프라이머리프라이머리 키 충돌을 방지하려면 모든 그린 데이터베이스에서 apg_plan_mgmt 확장의 apg_plan_mgmt.capture_plan_baselines 파라미터를 off로 설정해야 합니다. 자세한 내용은 Aurora PostgreSQL 쿼리 계획 관리 개요 단원을 참조하십시오.

  Aurora 복제본에서 실행 계획을 캡처하려면 apg_plan_mgmt.create_replica_plan_capture 함수를 호출할 때 블루 DB 클러스터 엔드포인트를 제공해야 합니다. 이렇게 하면 전환 후에도 계획 캡처가 계속 작동합니다. 자세한 내용은 복제본에서 Aurora PostgreSQL 실행 계획 캡처 단원을 참조하십시오.

• 블루 DB 클러스터가 외부 데이터 래퍼(FDW) 확장의 외부 서버로 구성된 경우 IP 주소 대신 클러스터 엔드포인트 이름을 사용해야 합니다. 이렇게 하면 전환 후에도 구성이 계속 작동합니다.

• 블루/그린 배포를 만들 때는 블루 환경에서 pglogical 및 pg_active 확장을 비활성화해야 합니다. 그린 환경을 새로운 프로덕션 환경으로 승격한 후 확장 기능을 다시 활성화할 수 있습니다. 또한 블루 데이터베이스는 외부 인스턴스의 논리적 구독자가 될 수 없습니다.

• pgAudit 확장을 사용하는 경우, 해당 확장은 블루 및 그린 DB 인스턴스 모두에 대한 사용자 지정 DB 파라미터 그룹의 공유 라이브러리(shared_preload_libraries)에 남아 있어야 합니다. 자세한 내용은 pgAudit 확장 설정 단원을 참조하십시오.

블루/그린 배포 변경 관련 제한 사항

블루/그린 배포에서의 변경에는 다음과 같은 제한 사항이 적용됩니다.

• 암호화되지 않은 DB 클러스터는 암호화된 DB 클러스터로 변경할 수 없습니다.

• 암호화된 DB 클러스터는 암호화되지 않은 DB 클러스터로 변경할 수 없습니다.

• 블루 환경 DB 클러스터를 대응하는 그린 환경 DB 클러스터로 변경할 수 없습니다.

• 블루 환경과 그린 환경의 리소스는 동일한 AWS 계정에 있어야 합니다.

• 블루 환경에 Aurora Auto Scaling 정책이 포함되어 있는 경우 이러한 정책은 그린 환경으로 복사되지 않습니다. 그린 환경에 정책을 수동으로 다시 추가해야 합니다.

블루/그린 배포를 위한 PostgreSQL 논리적 복제 제한

블루/그린 배포에서는 논리적 복제를 사용하여 스테이징 환경을 프로덕션 환경과 동기화된 상태로 유지합니다. PostgreSQL에는 논리적 복제와 관련된 몇 가지 제한 사항이 있으며, 이로 인해 Aurora PostgreSQL DB 클러스터에 대한 블루/그린 배포를 생성할 때 제한이 적용됩니다.

다음 표에는 Aurora PostgreSQL의 블루/그린 배포에 적용되는 논리적 복제 제한 사항이 설명되어 있습니다.

제한 사항	설명
CREATE TABLE 및 CREATE SCHEMA와 같은 데이터 정의 언어(DDL) 문은 블루 환경에서 그린 환경으로 복제되지 않습니다.	Aurora가 블루 환경에서 DDL 변경을 감지하면 그린 데이터베이스는 복제 성능 저하 상태로 전환됩니다. 블루 환경의 DDL 변경 사항을 그린 환경으로 복제할 수 없음을 알리는 이벤트가 수신됩니다. 블루/그린 배포와 모든 그린 데이터베이스를 삭제한 다음 다시 생성해야 합니다. 이렇게 하지 않으면 블루/그린 배포를 전환할 수 없습니다.
시퀀스 객체에 대한 NEXTVAL 작업은 블루 환경과 그린 환경 간에 동기화되지 않습니다.	전환 중에 Aurora는 그린 환경의 시퀀스 값을 증가시켜 블루 환경의 시퀀스 값과 일치하도록 합니다. 수천 개의 시퀀스가 있는 경우 전환이 지연될 수 있습니다.
블루 환경에서 큰 객체를 만들거나 수정해도 그린 환경에는 복제되지 않습니다.	Aurora가 블루 환경에서 pg_largeobject 시스템 테이블에 저장된 대형 객체의 생성 또는 수정을 감지하면 그린 데이터베이스는 복제 성능 저하 상태로 전환됩니다. Aurora는 블루 환경의 대규모 객체 변경 사항을 그린 환경에 복제할 수 없음을 알리는 이벤트를 생성합니다. 블루/그린 배포와 모든 그린 데이터베이스를 삭제한 다음 다시 생성해야 합니다. 이렇게 하지 않으면 블루/그린 배포를 전환할 수 없습니다.
그린 환경에서는 구체화된 뷰가 자동으로 새로 고쳐지지 않습니다.	블루 환경에서 구체화된 뷰를 새로 고쳐도 그린 환경에서는 새로 고쳐지지 않습니다. 전환 후에는 구체화된 뷰의 새로 고침을 예약할 수 있습니다.
프라이머리프라이머리 키가 없는 테이블에서는 UPDATE 및 DELETE 작업이 허용되지 않습니다.	블루/그린 배포를 생성하기 전에 DB 클러스터의 모든 테이블에 프라이머리프라이머리 키가 있는지 확인하세요.

자세한 내용은 PostgreSQL 논리적 복제 설명서의 제한 사항을 참조하세요.