# Amazon Aurora 블루/그린 배포 개요
Amazon Aurora 블루/그린 배포를 사용하면 프로덕션 환경에서 구현하기 전에 데이터베이스를 변경하고 테스트할 수 있습니다. *블루/그린 배포*는 프로덕션 환경을 복사하는 스테이징 환경을 만듭니다. 블루/그린 배포에서는 *블루 환경*이 현재 프로덕션 환경입니다. *그린 환경*은 스테이징 환경이며 현재 프로덕션 환경과 동기화된 상태를 유지합니다.
프로덕션 워크로드에 영향을 주지 않고 그린 환경에서 Aurora DB 클러스터를 변경할 수 있습니다. 예를 들어 메이저 또는 마이너 DB 엔진 버전을 업그레이드하거나 스테이징 환경에서 데이터베이스 파라미터를 변경할 수 있습니다. 그린 환경의 변경 사항을 철저하게 테스트할 수 있습니다. 준비가 되면 환경을 *전환*하여 그린 환경을 새로운 프로덕션 환경으로 전환할 수 있습니다. 전환은 일반적으로 1분도 걸리지 않으며 데이터 손실이 발생하지 않고 애플리케이션을 변경할 필요도 없습니다.
그린 환경은 프로덕션 환경 토폴로지의 복사본이므로, DB 클러스터와 DB 클러스터의 모든 DB 인스턴스가 배포 시 복사됩니다. 그린 환경에는 DB 클러스터 스냅샷, 성능 개선 도우미와 확장 모니터링 같은 DB 클러스터에서 사용하는 기능도 포함됩니다Aurora Serverless v2.
**참고**
Aurora MySQL, Aurora PostgreSQL 및 Aurora Global Database에 대해 블루/그린 배포가 지원됩니다. Amazon RDS 가용성에 대해서는 *Amazon RDS 사용 설명서*의 [Amazon RDS 블루/그린 배포 개요](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html)를 참조하세요.
**Topics**
+ [리전 및 버전 사용 가능 여부](#blue-green-deployments-region-version-availability)
+ [Amazon RDS 블루/그린 배포 사용의 장점](#blue-green-deployments-benefits)
+ [블루/그린 배포 워크플로우](#blue-green-deployments-major-steps)
+ [Amazon Aurora 블루/그린 배포 작업에 대한 액세스 권한 부여](blue-green-deployments-authorizing-access.md)
+ [Amazon Aurora 블루/그린 배포 관련 제한 사항 및 고려 사항](blue-green-deployments-considerations.md)
+ [Amazon Aurora 블루/그린 배포 모범 사례](blue-green-deployments-best-practices.md)
## 리전 및 버전 사용 가능 여부
기능 가용성 및 해당 지원은 각 데이터베이스 엔진의 특정 버전 및 AWS 리전 리전에 따라 다릅니다. 자세한 내용은 [블루/그린 배포를 지원하는 리전 및 Aurora DB 엔진](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md) 섹션을 참조하세요.
## Amazon RDS 블루/그린 배포 사용의 장점
Amazon RDS 블루/그린 배포를 사용하면 보안 패치를 최신 상태로 유지하고, 데이터베이스 성능을 개선할 수 있으며 짧고 예측 가능한 다운타임으로 최신 데이터베이스 기능을 채택할 수 있습니다. 블루/그린 배포를 통해 메이저 또는 마이너 엔진 버전 업그레이드와 같이 데이터베이스 업데이트로 인해 발생가능한 리스크 및 다운타임을 줄일 수 있습니다.
블루/그린 배포는 다음과 같은 장점을 제공합니다.
+ 프로덕션 준비가 된 스테이징 환경을 쉽게 만들 수 있습니다.
+ 데이터베이스 변경 사항을 프로덕션 환경에서 스테이징 환경으로 자동으로 복제합니다.
+ 프로덕션 환경에 영향을 주지 않고 안전한 스테이징 환경에서 데이터베이스 변경 사항을 테스트합니다.
+ 데이터베이스 패치 및 시스템 업데이트로 최신 상태를 유지하세요.
+ 새로운 데이터베이스 기능을 구현하고 테스트합니다.
+ 애플리케이션을 변경하지 않고도 스테이징 환경을 새 프로덕션 환경으로 전환합니다.
+ 내장된 전환 가드레일을 사용하여 안전하게 전환합니다.
+ 전환 중 데이터 손실이 발생하지 않습니다.
+ 워크로드에 따라 대부분 1분 이내에 빠르게 전환합니다.
## 블루/그린 배포 워크플로우
Aurora DB 클러스터 업데이트에 블루/그린 배포를 사용한다면 다음 주요 단계를 완료하십시오.
1. 업데이트가 필요한 프로덕션 DB 클러스터를 식별합니다.
다음 이미지에서는 프로덕션 DB 클러스터 예시를 확인할 수 있습니다.
![\[블루/그린 배포의 프로덕션(블루) Aurora DB 클러스터\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-blue-environment-aurora.png)
1. 블루/그린 배포 생성 지침은 [Amazon Aurora에서 블루/그린 배포 생성](blue-green-deployments-creating.md) 섹션을 참조하세요.
다음 이미지는 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**).
![\[Amazon Aurora용 블루/그린 배포\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-aurora.png)
블루/그린 배포를 생성하는 도중 더 높은 DB 엔진 버전을 지정하고, 그린 환경에 있는 DB 클러스터에 다른 DB 클러스터 파라미터 그룹을 지정할 수 있습니다. DB 클러스터의 DB 인스턴스에 다른 DB 파라미터 그룹을 지정할 수 있습니다.
또한 RDS는 블루 환경의 기본 DB 인스턴스에서 그린 환경의 기본 DB 인스턴스로의 복제를 구성합니다.
**중요**
Aurora MySQL 버전 3의 경우 블루/그린 배포를 생성하면 그린 환경의 DB 클러스터는 기본적으로 쓰기 작업을 허용하지 않습니다. 그러나 이는 Aurora 마스터 사용자를 비롯하여 `CONNECTION_ADMIN` 권한이 있는 사용자에게 적용되지 않습니다. 이 권한이 있는 사용자는 `read_only` 동작을 재정의할 수 있습니다. 자세한 내용은 [역할 기반 권한 모델](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model) 섹션을 참조하세요.
1. 스테이징 환경에 변경 사항을 적용합니다.
예를 들어 그린 환경에 있는 하나 이상의 DB 인스턴스에서 사용하는 DB 인스턴스 클래스를 변경할 수 있습니다.
DB 클러스터 수정에 대한 자세한 내용은 [Amazon Aurora DB 클러스터 수정](Aurora.Modifying.md) 섹션을 참조하세요.
1. 스테이징 환경을 테스트합니다.
테스트하는 동안에는 그린 환경의 데이터베이스를 읽기 전용으로 유지하는 것이 좋습니다. 복제 충돌이 발생할 수 있으므로 그린 환경에서 쓰기 작업을 사용 설정하세요. 전환 후 프로덕션 데이터베이스에 의도하지 않은 데이터가 저장될 수도 있습니다. Aurora MySQL에서 쓰기 작업을 활성화하려면 `read_only` 파라미터를 `0`으로 설정한 다음 DB 인스턴스를 재부팅합니다. Aurora PostgreSQL의 경우 `default_transaction_read_only` 파라미터를 세션 수준에서 `off`로 설정합니다.
1. 준비가 되면 전환하여 그린 환경을 새로운 프로덕션 환경으로 전환합니다. 지침은 [Amazon Aurora에서 블루/그린 배포 전환](blue-green-deployments-switching.md) 섹션을 참조하세요.
전환하면 다운타임이 발생하게 됩니다. 다운타임은 보통 1분 미만이지만 워크로드에 따라 더 길어질 수 있습니다.
다음 이미지는 전환 이후의 DB 클러스터를 보여 줍니다.
![\[Amazon Aurora 블루/그린 배포로 전환한 후의 DB 클러스터 및 DB 인스턴스\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switchover-aurora.png)
전환 후에는 그린 환경의 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`이 됩니다.
1. 블루/그린 배포가 더 이상 필요하지 않다면 삭제해도 됩니다. 지침은 [Amazon Aurora에서 블루/그린 배포 삭제](blue-green-deployments-deleting.md) 섹션을 참조하세요.
전환 후에도 이전 프로덕션 환경이 삭제되지 않으므로, 필요하다면 회귀 테스트에 사용할 수 있습니다.
# Amazon Aurora 블루/그린 배포 작업에 대한 액세스 권한 부여
사용자는 블루/그린 배포와 관련된 작업을 수행하는 데 필요한 권한이 있어야 합니다. 지정된 리소스에서 특정 API 태스크를 수행할 수 있는 권한을 사용자와 역할에게 부여하는 IAM 정책을 생성할 수 있습니다. 그런 다음 해당 권한이 필요한 IAM 권한 세트 또는 역할에 이러한 정책을 연결할 수 있습니다. 자세한 내용은 [Amazon Aurora의 자격 증명 및 액세스 관리](UsingWithRDS.IAM.md) 섹션을 참조하세요.
블루/그린 배포를 만드는 사용자는 다음 RDS 작업을 수행할 권한이 있어야 합니다.
+ `rds:CreateBlueGreenDeployment`
+ `rds:AddTagsToResource`
+ `rds:CreateDBCluster`
+ `rds:CreateDBInstance`
+ `rds:CreateDBClusterEndpoint`
블루/그린 배포로 전환하는 사용자는 다음 RDS 작업을 수행할 권한이 있어야 합니다.
+ `rds:SwitchoverBlueGreenDeployment`
+ `rds:ModifyDBCluster`
+ `rds:PromoteReadReplicaDBCluster`
블루/그린 배포를 삭제하는 사용자는 다음 RDS 작업을 수행할 권한이 있어야 합니다.
+ `rds:DeleteBlueGreenDeployment`
+ `rds:DeleteDBCluster`
+ `rds:DeleteDBInstance`
+ `rds:DeleteDBClusterEndpoint`
Aurora는 사용자를 대신하여 스테이징 환경에서 리소스를 프로비저닝하고 수정합니다. 이러한 리소스에는 내부적으로 정의된 명명 규칙을 사용하는 DB 인스턴스가 포함됩니다. 따라서 연결된 IAM 정책에는 `my-db-prefix-*`와 같은 부분적인 리소스 이름 패턴이 포함될 수 없습니다. 와일드카드(\$1)만 지원됩니다. 일반적으로 와일드카드 대신 리소스 태그와 기타 지원되는 속성을 사용하여 이러한 리소스에 대한 액세스를 제어하는 것이 좋습니다. 자세한 내용은 [Amazon RDS에 사용되는 작업, 리소스 및 조건 키](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html)를 참조하세요.
## Aurora Global Database 블루/그린 배포에 대한 추가 권한
Aurora Global Database 클러스터에 대한 블루/그린 배포를 생성할 때 사용자는 위에 나열된 권한 외에도 글로벌 클러스터 토폴로지를 관리하는 작업을 수행하려면 다음 권한이 필요합니다.
블루/그린 배포를 만드는 사용자는 다음 RDS 작업을 수행할 권한이 있어야 합니다.
+ `rds:CreateGlobalCluster`
블루/그린 배포로 전환하는 사용자는 다음 RDS 작업을 수행할 권한이 있어야 합니다.
+ `rds:ModifyGlobalCluster`
+ `rds:PromoteReadReplicaDBCluster`
블루/그린 배포를 삭제하는 사용자는 다음 RDS 작업을 수행할 권한이 있어야 합니다.
+ `rds:DeleteGlobalCluster`
# Amazon Aurora 블루/그린 배포 관련 제한 사항 및 고려 사항
Amazon RDS에서 블루/그린 배포를 하려면 복제 슬롯, 리소스 관리, 인스턴스 크기 조정, 데이터베이스 성능에 미치는 잠재적 영향과 같은 요소를 신중하게 고려해야 합니다. 다음 섹션은 데이터베이스 환경의 가동 중지 시간을 최소화하고, 원활한 전환을 보장하고, 효과적으로 관리할 수 있도록 배포 전략을 최적화하는 데 도움이 되는 지침을 제공합니다.
**Topics**
+ [블루/그린 배포 관련 제한 사항](#blue-green-deployments-limitations)
+ [블루/그린 배포에 대한 Aurora Global Database 제한 사항](#blue-green-deployments-limitations-agd)
+ [블루/그린 배포 관련 고려 사항](#blue-green-deployments-consider)
## 블루/그린 배포 관련 제한 사항
블루/그린 배포에는 다음과 같은 제한 사항이 적용됩니다.
**Topics**
+ [블루/그린 배포 관련 일반 제한 사항](#blue-green-deployments-limitations-general)
+ [블루/그린 배포에 대한 Aurora MySQL 제한 사항](#blue-green-deployments-limitations-mysql)
+ [블루/그린 배포에 대한 Aurora PostgreSQL 제한 사항](#blue-green-deployments-limitations-postgres-logical)
### 블루/그린 배포 관련 일반 제한 사항
블루/그린 배포에는 다음과 같은 일반 제한 사항이 적용됩니다.
+ 블루/그린 배포의 일부인 클러스터는 중지 및 시작이 불가능합니다.
+ 블루/그린 배포의 경우 AWS Secrets Manager에서 마스터 사용자 암호 관리를 지원하지 않습니다.
+ 블루 DB 클러스터를 강제로 역추적하려고 하면 블루/그린 배포가 중단되고 전환이 차단됩니다.
+ 전환 중에는 블루 및 그린 환경을 Amazon Redshift와 제로 ETL로 통합할 수 없습니다. 먼저 통합을 삭제하고 전환한 다음 통합을 다시 생성해야 합니다.
+ 블루/그린 배포를 생성할 때는 그린 환경에서 Event Scheduler(`event_scheduler` 파라미터)를 비활성화해야 합니다. 이렇게 하면 그린 환경에서 이벤트가 생성되어 불일치가 발생하는 것을 방지할 수 있습니다.
+ 블루 DB 클러스터에 구성된 오토 스케일링 정책은 그린 환경으로 복사되지 않습니다. 처음에 블루 또는 그린 환경에 설정되었는지와 관계없이 전환 후 다시 구성해야 합니다.
+ 암호화되지 않은 DB 클러스터는 암호화된 DB 클러스터로 변경할 수 없습니다. 더욱이 암호화된 DB 클러스터는 암호화되지 않은 DB 클러스터로 변경할 수 없습니다.
+ 블루 DB 클러스터를 해당하는 그린 DB 클러스터보다 높은 엔진 버전으로 변경할 수 없습니다.
+ 블루 환경과 그린 환경의 리소스는 동일한 AWS 계정에 있어야 합니다.
+ 블루/그린 배포는 다음 기능에는 지원되지 않습니다.
+ Amazon RDS Proxy
+ 리전 간 읽기 전용 복제본
+ Aurora Serverless v1 DB 클러스터
+ CloudFormation
### 블루/그린 배포에 대한 Aurora MySQL 제한 사항
Aurora MySQL 블루/그린 배포에는 다음과 같은 제한 사항이 적용됩니다.
+ 소스 DB 클러스터에는 이름이 `tmp`인 데이터베이스가 포함될 수 없습니다. 이 이름을 가진 데이터베이스는 그린 환경으로 복사되지 않습니다.
+ 블루 DB 클러스터는 외부 binlog 복제본이 될 수 없습니다.
+ 역추적이 설정된 소스 DB 클러스터가 활성화된 경우 역추적 지원 없이 그린 DB 클러스터가 생성됩니다. 블루/그린 배포에 필요한 이진 로그(binlog) 복제본에서는 역추적이 작동하지 않기 때문입니다. 자세한 내용은 [Aurora DB 클러스터 역추적](AuroraMySQL.Managing.Backtrack.md) 섹션을 참조하세요.
+ 블루/그린 배포는 MySQL용 AWS JDBC 드라이버를 지원하지 않습니다. 자세한 내용은 GitHub의 [Known Limitations](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations)를 참조하세요.
### 블루/그린 배포에 대한 Aurora PostgreSQL 제한 사항
다음 제한 사항은 Aurora PostgreSQL 블루/그린 배포에 적용됩니다.
+ 블루 DB 클러스터에서 `rds.logically_replicate_unlogged_tables` 파라미터가 `1`로 설정되지 않은 경우 [로깅되지 않은](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED) 표는 그린 환경으로 복제되지 않습니다. 블루/그린 배포를 생성한 후에는 로깅되지 않은 테이블에서 발생할 수 있는 복제 오류를 방지하기 위해 이 파라미터 값을 수정하지 마세요.
+ 블루 DB 클러스터는 논리적 소스(게시자) 또는 복제본(구독자)일 수 없습니다.
+ 블루 DB 클러스터가 외부 데이터 래퍼(FDW) 확장의 외부 서버로 구성된 경우 IP 주소 대신 클러스터 엔드포인트 이름을 사용해야 합니다. 이렇게 하면 전환 후에도 구성이 계속 작동합니다.
+ 블루/그린 배포에서는 각 데이터베이스에 논리적 복제 슬롯이 필요합니다. 데이터베이스 수가 늘어나면 리소스 오버헤드가 증가하고, 특히 DB 클러스터 규모가 충분히 조정되지 않은 경우 복제 지연이 발생할 수 있습니다. 영향은 데이터베이스 워크로드 및 연결 수와 같은 요인에 따라 달라집니다. 이를 완화하려면 DB 인스턴스 클래스 규모를 조정하거나 소스 클러스터의 데이터베이스 수를 줄이는 것이 좋습니다.
+ 블루/그린 배포는 Babelfish for Aurora PostgreSQL 버전 15.7 이상 15 버전 및 16.3 이상 16 버전에서만 지원됩니다.
+ Aurora 복제본에서 실행 계획을 캡처하려면 `apg_plan_mgmt.create_replica_plan_capture` 함수를 호출할 때 블루 DB 클러스터 엔드포인트를 제공해야 합니다. 이렇게 하면 전환 후에도 계획 캡처가 계속 작동합니다. 자세한 내용은 [복제본에서 Aurora PostgreSQL 실행 계획 캡처](AuroraPostgreSQL.QPM.Plancapturereplicas.md) 섹션을 참조하세요.
+ 그린 환경의 논리적 복제 [적용 프로세스](https://www.postgresql.org/docs/current/logical-replication-architecture.html)는 단일 스레드입니다. 블루 환경이 대량의 쓰기 트래픽을 생성하는 경우 그린 환경이 따라가지 못할 수 있습니다. 이로 인해 복제 지연 또는 실패가 발생할 수 있으며, 특히 쓰기 처리량이 지속적으로 높은 워크로드의 경우 더욱 그렇습니다. 워크로드를 철저히 테스트해야 합니다. 메이저 버전 업그레이드와 대용량 쓰기 워크로드 처리가 필요한 시나리오의 경우 [AWS Database Migration Service(AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html) 또는 [자체 관리형 논리적 복제](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.MajorVersionUpgrade.html)를 사용하는 등의 대체 접근 방식을 고려합니다.
+ Aurora에 대한 블루/그린 배포 중에는 파티셔닝된 테이블에 새 파티션을 생성할 수 없습니다. 새 파티션을 생성하려면 블루 환경에서 그린 환경으로 복제되지 않는 `CREATE TABLE` 등의 데이터 정의 언어(DDL) 작업이 필요합니다. 그러나 기존에 파티셔닝된 테이블과 해당 데이터는 그린 환경에 복제됩니다.
+ PostgreSQL 확장에는 다음과 같은 제한 사항이 적용됩니다.
+ 블루/그린 배포를 만들 때는 블루 환경에서 `pg_partman` 확장을 비활성화해야 합니다. 확장은 블루 환경에서 그린 환경으로의 논리적 복제를 중단하는 `CREATE TABLE`과 같은 DDL 작업을 수행합니다.
+ 블루/그린 배포를 생성한 후에는 모든 그린 데이터베이스에서 `pg_cron` 확장을 비활성화한 상태로 유지해야 합니다. 확장에는 슈퍼유저로 실행되고 그린 환경의 읽기 전용 설정을 우회하는 백그라운드 작업자가 있어 복제 충돌이 발생할 수 있습니다.
+ 블루 환경에서 동일한 계획을 캡처하는 경우 프라이머리프라이머리 키 충돌을 방지하려면 모든 그린 데이터베이스에서 `apg_plan_mgmt` 확장의 `apg_plan_mgmt.capture_plan_baselines` 파라미터를 `off`로 설정해야 합니다. 자세한 내용은 [Aurora PostgreSQL 쿼리 계획 관리 개요](AuroraPostgreSQL.Optimize.overview.md) 섹션을 참조하세요.
+ 블루/그린 배포를 만들 때는 블루 환경에서 `pglogical` 및 `pgactive` 확장을 비활성화해야 합니다. 그린 환경을 새로운 프로덕션 환경으로 전환한 후 확장 기능을 다시 활성화할 수 있습니다. 또한 블루 데이터베이스는 외부 인스턴스의 논리적 구독자가 될 수 없습니다.
+ `pgAudit` 확장을 사용하는 경우, 해당 확장은 블루 및 그린 DB 인스턴스 모두에 대한 사용자 지정 DB 파라미터 그룹의 공유 라이브러리(`shared_preload_libraries`)에 남아 있어야 합니다. 자세한 내용은 [pgAudit 확장 설정](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md) 섹션을 참조하세요.
#### 블루/그린 배포의 논리적 복제 관련 제한 사항
PostgreSQL에는 논리적 복제와 관련된 몇 가지 제한 사항이 있으며, 이로 인해 Aurora PostgreSQL DB 클러스터에 대한 블루/그린 배포를 생성할 때 제한이 적용됩니다.
다음 표에는 Aurora PostgreSQL의 블루/그린 배포에 적용되는 논리적 복제 제한 사항이 설명되어 있습니다. 자세한 내용은 PostgreSQL 논리적 복제 설명서의 [제한 사항](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)을 참조하세요.
| 제한 사항 | 설명 |
| --- | --- |
| CREATE TABLE 및 CREATE SCHEMA와 같은 데이터 정의 언어(DDL) 문은 블루 환경에서 그린 환경으로 복제되지 않습니다. | Aurora가 블루 환경에서 DDL 변경을 감지하면 그린 데이터베이스는 **복제 성능 저하** 상태로 전환됩니다. 블루/그린 배포와 모든 그린 데이터베이스를 삭제한 다음 다시 생성해야 합니다. |
| GRANT 및 REVOKE와 같은 데이터 제어 언어(DCL) 문은 블루 환경에서 그린 환경으로 복제되지 않습니다. | Aurora이 블루 환경에서 DCL 문 실행 시도를 감지하면 경고 메시지가 표시됩니다. 블루/그린 배포 프로세스의 제한 사항이므로 이 동작을 변경하는 데 사용할 수 있는 구성 또는 API는 없습니다. |
| 시퀀스 객체에 대한 NEXTVAL 작업은 블루 환경과 그린 환경 간에 동기화되지 않습니다. | 전환 중에 Aurora는 그린 환경의 시퀀스 값을 증가시켜 블루 환경의 시퀀스 값과 일치하도록 합니다. 수천 개의 시퀀스가 있는 경우 전환이 지연될 수 있습니다. |
| 블루 환경의 대형 객체는 그린 환경에 복제되지 않습니다. 여기에는 기존 대형 객체와 블루/그린 배포 프로세스 중에 새로 생성되거나 수정된 대형 객체가 모두 포함됩니다. | Aurora**가 블루 환경에서 `pg_largeobject` 시스템 테이블에 저장된 대형 객체의 생성 또는 수정을 감지하면 그린 데이터베이스는 복제 성능 저하** 상태로 전환됩니다. 블루/그린 배포와 모든 그린 데이터베이스를 삭제한 다음 다시 생성해야 합니다. |
| 구체화된 뷰를 새로 고치면 복제가 중단됩니다. | 블루 환경에서 구체화된 뷰를 새로 고치면 그린 환경에 대한 복제가 중단됩니다. 블루 환경에서 구체화된 뷰를 새로 고치지 마세요. 전환 후에는 [REFRESH MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html) 명령을 사용하여 수동으로 새로 고치거나 새로 고침 일정을 예약할 수 있습니다. |
| 프라이머리프라이머리 키가 없는 테이블에서는 UPDATE 및 DELETE 작업이 허용되지 않습니다. | 블루/그린 배포를 생성하기 전에 모든 테이블에 프라이머리 키가 있거나 `REPLICA IDENTITY FULL`을 사용하는지 확인하세요. 그러나 프라이머리 키 또는 고유 키가 없는 경우 `REPLICA IDENTITY FULL`만 사용합니다. 복제 성능에 영향을 미치기 때문입니다. 자세한 내용은 [PostgreSQL 설명서](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)를 참조하세요. |
## 블루/그린 배포에 대한 Aurora Global Database 제한 사항
위에 명시된 일반 및 엔진별 제한 외에도 Aurora Global Database의 블루/그린 배포에는 다음과 같은 제한 사항이 적용됩니다.
+ 모든 작업은 글로벌 데이터베이스의 라이터 클러스터와 동일한 리전에서 시작해야 합니다.
+ 글로벌 전환 또는 글로벌 장애 조치를 수행하면 활성 블루/그린 배포가 무효화됩니다. 블루-그린 배포는 삭제하고 새 기본 리전에서 다시 생성해야 합니다.
+ Aurora PostgreSQL의 경우 프로덕션 환경에서 글로벌 쓰기 전달을 활성화하고 블루/그린 배포를 생성하는 경우 그린 클러스터에서 쓰기 전달이 비활성화됩니다. 그린 환경이 새 프로덕션 환경이 될 때 블루/그린 전환 후에만 그린 환경에서 활성화됩니다. 전환 후에는 `-old1` 클러스터에서 쓰기 전달이 비활성화됩니다.
+ 블루/그린 배포를 생성한 후 글로벌 데이터베이스의 토폴로지로를 수정하면 활성 블루/그린 배포가 무효화됩니다. 블루-그린 배포는 새 기본 리전에서 삭제하고 다시 생성해야 합니다.
+ 자동 스냅샷은 원래 이전 블루 환경에서 구성된 백업 보존 일수에 따라 보존됩니다. 이전 블루 클러스터의 자동 스냅샷은 그린으로 복사되지 않습니다.
+ 글로벌 장애 조치는 블루/그린 전환 중에는 지원되지만 블루/그린 전환 중에는 지원되지 않습니다.
+ 그린 환경의 DB 클러스터 및 DB 파라미터 그룹이 이름이 동일한 모든 보조 리전에 있는지 확인합니다. 리전의 파라미터 그룹을 사용할 수 없는 경우 리전의 기본 파라미터 그룹이 사용됩니다.
+ 블루/그린 배포 전환 중에 글로벌 데이터베이스 멤버에서 RDS 프록시를 사용하지 마세요.
## 블루/그린 배포 관련 고려 사항
Amazon RDS는 각 리소스의 `DbiResourceId` 및 `DbClusterResourceId`를 사용하여 블루/그린 배포의 리소스를 추적합니다. 이 리소스 ID는 AWS 리전별로 고유한, 리소스의 변경 불가능한 식별자입니다.
*리소스* ID는 DB *클러스터*** ID와 다릅니다. 각 항목은 RDS 콘솔의 데이터베이스 구성에 나열되어 있습니다.
블루/그린 배포로 전환하면 리소스 이름(클러스터 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 호출 모니터링](logging-using-cloudtrail.md) 섹션을 참조하세요.
+ 블루 환경의 리소스에 데이터베이스 활동 스트림을 사용한다면, 전환 후 새 스트림에 대한 데이터베이스 이벤트를 모니터링하도록 애플리케이션을 조정하십시오. 자세한 내용은 [데이터베이스 활동 스트림을 지원하는 리전 및 Aurora DB 엔진](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md) 섹션을 참조하세요.
+ Performance Insights API를 사용한다면, 전환 후 API 호출의 리소스 ID를 조정하십시오. 자세한 내용은 [성능 개선 도우미를 통한 Amazon Aurora 모니터링](USER_PerfInsights.md) 섹션을 참조하세요.
전환 후 동일한 이름의 데이터베이스를 모니터링할 수 있지만, 전환 전의 데이터는 포함되지 않습니다.
+ IAM 정책에서 리소스 ID를 사용한다면, 필요한 경우 새로 전환된 리소스의 리소스 ID를 추가해야 합니다. 자세한 내용은 [Amazon Aurora의 자격 증명 및 액세스 관리](UsingWithRDS.IAM.md) 섹션을 참조하세요.
+ DB 클러스터와 연결된 IAM 역할이 있는 경우 전환 후 해당 역할을 다시 연결해야 합니다. 연결된 역할은 그린 환경으로 자동 복사되지 않습니다.
+ [IAM 데이터베이스 인증](UsingWithRDS.IAMDBAuth.md)을 사용하여 DB 클러스터를 인증하는 경우, 데이터베이스 액세스에 사용되는 IAM 정책의 `Resource` 요소 아래에 블루 데이터베이스와 그린 데이터베이스가 모두 나열되어 있는지 확인하세요. 이는 전환 후 그린 데이터베이스에 연결하기 위해 필요합니다. 자세한 내용은 [IAM 데이터베이스 액세스를 위한 IAM 정책 생성 및 사용](UsingWithRDS.IAMDBAuth.IAMPolicy.md) 섹션을 참조하세요.
+ 블루/그린 배포의 일부였던 DB 클러스터의 수동 DB 클러스터 스냅샷을 복원하려면, 스냅샷을 촬영한 시간을 확인하여 올바른 DB 클러스터 스냅샷을 복원해야 합니다. 자세한 내용은 [DB 클러스터 스냅샷에서 복원](aurora-restore-snapshot.md) 섹션을 참조하세요.
+ 전환한 후에는 블루 환경의 체크포인트가 그린 환경에서 유효하지 않기 때문에 AWS Database Migration Service(AWS DMS) 복제 작업을 재개할 수 없습니다. 복제를 계속하려면 새 체크포인트로 DMS 작업을 다시 만들어야 합니다.
+ Amazon Aurora는 블루 환경에서 기본 Aurora 스토리지 볼륨을 복제하여** 그린 환경을 만듭니다. 그린 클러스터 볼륨은 그린 환경에 대한 증분 변경만 저장합니다. 블루 환경의 DB 클러스터를 삭제하면 그린 환경의 기본 Aurora 스토리지 볼륨 크기가 최대 크기로 커집니다. 자세한 내용은 [Aurora DB 클러스터에 대한 볼륨 복제](Aurora.Managing.Clone.md) 섹션을 참조하세요.
+ 블루/그린 배포의 그린 환경에 있는 DB 인스턴스에 DB 인스턴스를 추가하면, 새 DB 인스턴스는 전환할 때 블루 환경의 읽기 전용 복제본을 대체하지 않습니다. 하지만 새 DB 인스턴스는 DB 클러스터에 유지되며 새 프로덕션 환경에서는 DB 인스턴스가 됩니다.
+ 블루/그린 배포의 그린 환경에 있는 DB 클러스터에서 DB 인스턴스를 삭제하면, 블루/그린 배포에서 이를 대체할 새 DB 인스턴스를 만들 수 없습니다.
삭제된 DB 인스턴스와 동일한 이름 및 ARN으로 새 DB 인스턴스를 생성하면, `DbiResourceId`가 다르기 때문에 그린 환경에 속하지 않게 됩니다.
그린 환경의 DB 클러스터에서 DB 인스턴스를 삭제하면 다음과 같은 동작이 발생합니다.
+ 블루 환경에 이름이 같은 DB 인스턴스가 있는 경우, 이 인스턴스는 그린 환경의 DB 인스턴스로 전환되지 않습니다. 이 DB 인스턴스는 DB 인스턴스 이름에 `-oldn`을 추가하여 이름이 바뀌지 않습니다.
+ 블루 환경의 DB 인스턴스를 가리키는 모든 애플리케이션은 전환 후에도 동일한 DB 인스턴스를 계속 사용합니다.
+ 액세스 제어 또는 운영 관리에 리소스 태그를 사용하는 경우 전환될 때까지 블루 환경과 그린 환경 간에 태그 변경이 동기화되지 않는다는 점을 이해해야 합니다. 블루/그린 배포를 생성하면 블루 환경의 태그가 그린 환경으로 복사됩니다. 생성 후에는 두 환경 중 하나에 대한 태그 수정이 자동으로 동기화되지 않습니다. 전환 중에 파란색 환경 태그는 그린 환경의 모든 태그를 대체합니다. 블루/그린 배포를 생성하기 전에 블루 환경에 필요한 모든 태그를 적용하거나 전환 후 새 프로덕션 환경에 필요한 태그를 다시 적용합니다. 태그에 대한 자세한 내용은 [Amazon Aurora 및Amazon RDS 리소스에 태그 지정](USER_Tagging.md) 섹션을 참조하세요.
# Amazon Aurora 블루/그린 배포 모범 사례
다음은 블루/그린 배포 모범 사례입니다.
**Topics**
+ [블루/그린 배포 일반 모범 사례](#blue-green-deployments-best-practices-general)
+ [블루/그린 배포에 대한 Aurora MySQL 모범 사례](#blue-green-deployments-best-practices-mysql)
+ [블루/그린 배포 모범 사례에 대한 Aurora PostgreSQL 모범 사례](#blue-green-deployments-best-practices-postgres)
+ [블루/그린 배포에 대한 Aurora Global Database 모범 사례](#blue-green-deployments-best-practices-agd)
## 블루/그린 배포 일반 모범 사례
블루/그린 배포를 만들 때 다음 일반 모범 사례를 고려하세요.
+ 전환하기 전에 Aurora DB 클러스터를 철저하게 테스트합니다.
+ 그린 환경에서 데이터베이스를 읽기 전용으로 유지합니다. 복제 충돌이 발생할 수 있으므로 그린 환경에서 쓰기 작업을 사용 설정할 때는 신중해야 합니다. 전환 후 프로덕션 데이터베이스에 의도하지 않은 데이터가 저장될 수도 있습니다.
+ 블루/그린 배포를 사용하여 스키마 변경을 구현할 때는 복제와 호환되는 변경만 적용합니다.
예를 들어 블루 배포에서 그린 배포로의 복제를 중단하지 않고 테이블 끝에 새 열을 추가할 수 있습니다. 그러나 열 이름 변경이나 테이블 이름 변경 같은 스키마 변경은 그린 배포로의 복제 중단을 유발합니다.
복제 호환 변경 사항에 대한 자세한 내용은 MySQL 설명서의 [소스 및 복제본에서 서로 다른 테이블 정의를 사용하는 복제](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) 및 PostgreSQL 논리적 복제 설명서의 [제한 사항](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)을 참조하세요.
+ 두 환경의 모든 연결에 클러스터 엔드포인트, 리더 엔드포인트 또는 사용자 지정 엔드포인트를 사용합니다. 정적 또는 제외 목록과 함께 인스턴스 엔드포인트나 사용자 지정 엔드포인트를 사용하지 않습니다.
+ 블루/그린 배포로 전환할 때는 전환 모범 사례를 따르세요. 자세한 내용은 [전환 모범 사례](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices) 섹션을 참조하세요.
## 블루/그린 배포에 대한 Aurora MySQL 모범 사례
Aurora MySQL DB 클러스터에서 블루/그린 배포를 만들 때 다음 모범 사례를 고려하세요.
+ 그린 환경에 복제본 지연이 발생하는 경우 다음을 고려하세요.
+ 필요하지 않은 경우 이진 로그 보존을 비활성화하거나 복제가 회수될 때까지 일시적으로 비활성화합니다. 이렇게 하려면 `binlog_format` DB 클러스터 파라미터를 `0`으로 다시 설정하고 그린 라이터 DB 인스턴스를 재부팅합니다.
+ 그린 DB 파라미터 그룹에서 `innodb_flush_log_at_trx_commit` 파라미터를 일시적으로 `0`으로 설정합니다. 복제가 최신 상태로 동기화된 후 전환하기 전에 `1`의 기본값으로 되돌립니다. 임시 파라미터 값에서 예기치 않은 종료 또는 충돌이 발생하는 경우 탐지되지 않은 데이터 손상을 방지하기 위해 그린 환경을 다시 빌드합니다. 자세한 내용은 [로그 버퍼를 플러시하는 빈도 구성](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush) 섹션을 참조하세요.
## 블루/그린 배포 모범 사례에 대한 Aurora PostgreSQL 모범 사례
Aurora PostgreSQL DB 클러스터에서 블루/그린 배포를 만들 때 다음 모범 사례를 고려하세요.
+ Aurora PostgreSQL 논리적 복제 라이트-스루 캐시를 모니터링하고 필요한 경우 캐시 버퍼를 조정합니다. 자세한 내용은 [Aurora PostgreSQL 논리적 복제 라이트-스루 캐시 모니터링](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache) 섹션을 참조하세요.
+ 블루 환경에서 `logical_decoding_work_mem` DB 파라미터의 값을 늘립니다. 이렇게 하면 디스크 디코딩이 줄어들고 대신 메모리가 사용됩니다. 자세한 내용은 [논리적 디코딩을 위한 작업 메모리 조정](AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.md#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem) 섹션을 참조하세요.
+ `ReplicationSlotDiskUsage` CloudWatch 지표를 사용하여 디스크에 기록되는 트랜잭션 오버플로를 모니터링할 수 있습니다. 이 지표는 복제 슬롯의 디스크 사용량에 대한 인사이트를 제공하므로 트랜잭션 데이터가 메모리 용량을 초과하고 디스크에 저장되는 시점을 식별하는 데 도움이 됩니다. `FreeableMemory` CloudWatch 지표로 여유 메모리를 모니터링할 수 있습니다. 자세한 내용은 [Amazon Aurora에 대한 인스턴스 수준 지표](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances) 섹션을 참조하세요.
+ Aurora PostgreSQL 버전 14 이상에서는 `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)` 시스템 뷰를 사용하여 논리적 오버플로 파일의 크기를 모니터링할 수 있습니다.
+ 블루/그린 배포를 생성하기 전에 모든 PostgreSQL 확장을 최신 버전으로 업데이트합니다. 자세한 내용은 [PostgreSQL 확장 버전 업그레이드](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md) 섹션을 참조하세요.
+ `aws_s3` 확장을 사용하는 경우 그린 환경이 만들어진 후 IAM 역할을 통해 그린 DB 클러스터에 Amazon S3에 대한 액세스 권한을 부여합니다. 이렇게 하면 전환 후에도 가져오기 및 내보내기 명령이 계속 작동합니다. 지침은 [Amazon S3 버킷에 대한 액세스 권한 설정](postgresql-s3-export-access-bucket.md) 섹션을 참조하세요.
+ 그린 환경에 더 높은 엔진 버전을 지정하는 경우 모든 데이터베이스에서 `ANALYZE` 작업을 실행하여 `pg_statistic` 테이블을 새로 고칩니다. 옵티마이저 통계는 메이저 버전 업그레이드 중에 전송되지 않으므로 성능 문제를 방지하려면 모든 통계를 다시 생성해야 합니다. 메이저 버전 업그레이드 중 추가 모범 사례에 대해 알아보려면 [메이저 버전 업그레이드 수행](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md) 섹션을 참조하세요.
+ 데이터를 조작하기 위해 트리거를 소스에 사용하는 경우 트리거를 `ENABLE REPLICA` 또는 `ENABLE ALWAYS`로 구성하지 마세요. 이렇게 구성하면 복제 시스템이 변경 내용을 전파하고 트리거를 실행하므로 중복이 발생합니다.
+ 트랜잭션이 오래 실행되면 심각한 복제 지연이 발생할 수 있습니다. 복제 지연을 줄이려면 다음과 같이 해 보세요.
+ 그린 환경이 블루 환경을 따라잡을 때까지 지연될 수 있는 장기 실행 트랜잭션 및 하위 트랜잭션을 줄이세요.
+ 그린 환경이 블루 환경을 따라잡을 때까지 블루 환경의 대량 작업을 줄이세요.
+ 블루/그린 배포를 생성하기 전에 사용량이 많은 테이블에서 수동 vacuum freeze 작업을 시작하세요. 지침은 [수동 vacuum freeze 수행](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.html)을 참조하세요.
+ PostgreSQL 버전 12 이상에서는 크거나 사용량이 많은 테이블에서 `index_cleanup` 파라미터를 비활성화하여 블루 데이터베이스의 정기 유지 관리의 효율성을 개선하세요. 자세한 내용은 [테이블에 최대한 신속하게 vacuum 실행](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing)을 참조하세요.
**참고**
Vacuum 중에 인덱스 정리를 정기적으로 건너뛰면 인덱스 팽창이 발생하여 스캔 성능이 저하될 수 있습니다. 블루/그린 배포를 사용하는 동안에만 이 접근 방식을 사용하는 것이 가장 좋습니다. 배포가 완료되면 정기적인 인덱스 유지 관리 및 정리를 재개하는 것이 좋습니다.
+ 블루 및 그린 DB 인스턴스가 워크로드에 비해 크기가 작으면 복제 지연이 발생할 수 있습니다. DB 인스턴스가 인스턴스 유형에 대한 리소스 제한에 도달하지 않는지 확인합니다. 자세한 내용은 [Amazon CloudWatch 지표를 사용한 Aurora PostgreSQL의 리소스 사용량 분석](AuroraPostgreSQL_AnayzeResourceUsage.md) 섹션을 참조하세요.
+ 복제 속도가 느리면 발신자와 수신자가 자주 다시 시작되어 동기화가 지연될 수 있습니다. 이들의 활성 상태를 유지하려면 블루 환경에서는 `wal_sender_timeout` 파라미터를 `0`으로 설정하고 그린 환경에서는 `wal_receiver_timeout` 파라미터를 `0`으로 설정하여 시간 초과를 비활성화하세요.
+ UPDATE 및 DELETE 문 성능을 검토하고 WHERE 절에서 사용되는 열에 인덱스를 생성하여 이러한 쿼리를 최적화할 수 있는지 평가합니다. 이렇게 하면 그린 환경에서 작업을 재생할 때 성능이 향상될 수 있습니다. 자세한 내용은 [대기를 생성하는 쿼리에 대한 술어 필터 확인](apg-waits.iodatafileread.md#apg-waits.iodatafileread.actions.filters) 섹션을 참조하세요.
+ 트리거를 사용하는 경우 이름이 'rds'로 시작하는 `pg_catalog.pg_publication`, `pg_catalog.pg_subscription` 및 `pg_catalog.pg_replication_slots` 객체를 만들고, 업데이트하고, 삭제하는 데 트리거가 방해가 되지 않는지 확인하세요.
+ 소스 DB 클러스터에서 Babelfish를 활성화한 경우 다음 파라미터는 그린 환경의 대상 DB 클러스터 파라미터 그룹에서 소스 DB 클러스터 파라미터 그룹과 동일한 설정을 가져야 합니다.
+ rds.babelfish\$1status
+ babelfishpg\$1tds.tds\$1default\$1numeric\$1precision
+ babelfishpg\$1tds.tds\$1default\$1numeric\$1scale
+ babelfishpg\$1tsql.default\$1locale
+ babelfishpg\$1tsql.migration\$1mode
+ babelfishpg\$1tsql.server\$1collation\$1name
이런 파라미터에 대한 자세한 내용은 [Babelfish용 DB 클러스터 파라미터 그룹 설정](babelfish-configuration.md) 섹션을 참조하세요.
## 블루/그린 배포에 대한 Aurora Global Database 모범 사례
위에 나열된 일반 및 엔진별 모범 사례 외에도 Aurora Global Database에 대한 다음 모범 사례를 고려하세요.
+ 다음 CloudWatch 지표를 모니터링하여 프로덕션 환경에서 활동이 적은 기간을 식별합니다.
+ `DatabaseConnections`
+ `ActiveTransactions`
계획된 유지 관리 기간 동안 또는 활동이 적은 기간 동안 블루/그린 전환을 예약합니다.
+ 블루/그린 전환 기간은 워크로드와 보조 리전 수에 따라 달라집니다. 블루/그린 전환을 시작하면 서비스가 계속하기 전에 복제본 지연이 0에 도달할 때까지 기다립니다. 전환을 시작하기 전에 복제본 지연을 확인하는 것이 좋습니다.
+ 그린 환경의 기본 파라미터 이외의 DB 파라미터 또는 DB 클러스터 파라미터 그룹을 사용하려는 경우 블루/그린 배포를 시작하기 전에 모든 보조 리전에서 동일한 이름으로 원하는 파라미터 그룹을 생성합니다.