# 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\_stat\_replication\_slots](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\_status
+ babelfishpg\_tds.tds\_default\_numeric\_precision
+ babelfishpg\_tds.tds\_default\_numeric\_scale
+ babelfishpg\_tsql.default\_locale
+ babelfishpg\_tsql.migration\_mode
+ babelfishpg\_tsql.server\_collation\_name
이런 파라미터에 대한 자세한 내용은 [Babelfish용 DB 클러스터 파라미터 그룹 설정](babelfish-configuration.md) 섹션을 참조하세요.
## 블루/그린 배포에 대한 Aurora Global Database 모범 사례
위에 나열된 일반 및 엔진별 모범 사례 외에도 Aurora Global Database에 대한 다음 모범 사례를 고려하세요.
+ 다음 CloudWatch 지표를 모니터링하여 프로덕션 환경에서 활동이 적은 기간을 식별합니다.
+ `DatabaseConnections`
+ `ActiveTransactions`
계획된 유지 관리 기간 동안 또는 활동이 적은 기간 동안 블루/그린 전환을 예약합니다.
+ 블루/그린 전환 기간은 워크로드와 보조 리전 수에 따라 달라집니다. 블루/그린 전환을 시작하면 서비스가 계속하기 전에 복제본 지연이 0에 도달할 때까지 기다립니다. 전환을 시작하기 전에 복제본 지연을 확인하는 것이 좋습니다.
+ 그린 환경의 기본 파라미터 이외의 DB 파라미터 또는 DB 클러스터 파라미터 그룹을 사용하려는 경우 블루/그린 배포를 시작하기 전에 모든 보조 리전에서 동일한 이름으로 원하는 파라미터 그룹을 생성합니다.