# Amazon RDS 블루/그린 배포 모범 사례
다음은 블루/그린 배포 모범 사례입니다.
**Topics**
+ [블루/그린 배포 일반 모범 사례](#blue-green-deployments-best-practices-general)
+ [블루/그린 배포에 대한 RDS for MySQL 모범 사례](#blue-green-deployments-best-practices-mysql)
+ [블루/그린 배포에 대한 RDS for MySQL 모범 사례](#blue-green-deployments-best-practices-agd)
+ [블루/그린 배포를 위한 PostgreSQL 복제 방법](blue-green-deployments-replication-type.md)
## 블루/그린 배포 일반 모범 사례
블루/그린 배포를 만들 때 다음 일반 모범 사례를 고려하세요.
+ 전환하기 전에 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)을 참조하세요.
**참고**
이 제한 사항은 물리적 복제를 사용하는 RDS for PostgreSQL 블루/그린 배포에는 적용되지 않습니다. 자세한 내용은 [물리적 복제를 사용하는 블루/그린 배포에 대한 RDS for PostgreSQL 제한 사항](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-physical) 섹션을 참조하세요.
+ 블루/그린 배포를 생성한 후 필요하다면 지연 로딩을 처리합니다. 전환하기 전에 데이터 로드가 완료되었는지 확인합니다. 자세한 내용은 [블루/그린 배포를 위한 지연 로딩 및 스토리지 초기화](blue-green-deployments-creating.md#blue-green-deployments-creating-lazy-loading) 섹션을 참조하세요.
+ 블루/그린 배포로 전환할 때는 전환 모범 사례를 따르세요. 자세한 내용은 [전환 모범 사례](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices) 섹션을 참조하세요.
## 블루/그린 배포에 대한 RDS for MySQL 모범 사례
RDS for MySQL DB 인스턴스에서 블루/그린 배포를 만들 때 다음 모범 사례를 고려하세요.
+ 복제에 최적화되지 않은 MyISAM 같은 비트랜잭션 스토리지 엔진 사용은 자제하시기 바랍니다.
+ 이진 로그 복제용 읽기 전용 복제본 및 그린 환경을 최적화합니다. DB 엔진에서 지원하는 경우 GTID, 병렬 및 충돌 방지 복제를 활성화하여 블루/그린 배포를 생성하기 전에 데이터 일관성과 내구성을 보장합니다. 자세한 내용은 [GTID 기반 복제 사용](mysql-replication-gtid.md) 섹션을 참조하세요.
+ 그린 환경에 복제본 지연이 발생하는 경우 다음을 고려하세요.
+ 그린 DB 파라미터 그룹에서 `innodb_flush_log_at_trx_commit` 파라미터를 일시적으로 `2`으로 설정합니다. 복제가 최신 상태로 동기화된 후 전환하기 전에 `1`의 기본값으로 되돌립니다. 임시 파라미터 값에서 예기치 않은 종료 또는 충돌이 발생하는 경우 탐지되지 않은 데이터 손상을 방지하기 위해 그린 환경을 다시 빌드합니다.
+ 쓰기 지연 시간을 줄이고 복제 처리량을 개선하기 위해 그린 다중 AZ DB 인스턴스를 일시적으로 단일 AZ DB 인스턴스로 변경합니다. 전환 직전에 다중 AZ를 다시 활성화합니다.
## 블루/그린 배포에 대한 RDS for MySQL 모범 사례
위에 나열된 일반 및 엔진별 모범 사례 외에도 RDS for MySQL DB 인스턴스에 대한 다음 모범 사례를 고려하세요.
+ 다음 CloudWatch 지표를 모니터링하여 프로덕션 환경에서 활동이 적은 기간을 식별합니다.
+ `DatabaseConnections`
+ `ActiveTransactions`
계획된 유지 관리 기간 동안 또는 활동이 적은 기간 동안 블루/그린 전환을 예약합니다.
+ 블루/그린 전환 기간은 워크로드와 보조 리전 수에 따라 달라집니다. 블루/그린 전환을 시작하면 서비스가 계속하기 전에 복제본 지연이 0에 도달할 때까지 기다립니다. 전환을 시작하기 전에 복제본 지연을 확인하는 것이 좋습니다.
+ 그린 환경의 기본 파라미터 이외의 DB 파라미터 또는 DB 클러스터 파라미터 그룹을 사용하려는 경우 블루/그린 배포를 시작하기 전에 모든 보조 리전에서 동일한 이름으로 원하는 파라미터 그룹을 생성합니다.
### 블루/그린 배포 모범 사례에 대한 RDS for PostgreSQL 모범 사례
RDS for PostgreSQL DB 인스턴스에서 블루/그린 배포를 만들 때 다음 모범 사례를 고려하세요.
**Topics**
+ [블루/그린 배포에 대한 RDS for PostgreSQL 일반 모범 사례](#blue-green-deployments-best-practices-postgres-general)
+ [물리적 복제를 사용하는 블루/그린 배포에 대한 RDS for PostgreSQL 모범 사례](#blue-green-deployments-best-practices-postgres-physical)
+ [논리적 복제를 사용하는 블루/그린 배포에 대한 RDS for PostgreSQL 모범 사례](#blue-green-deployments-best-practices-postgres-logical)
#### 블루/그린 배포에 대한 RDS for PostgreSQL 일반 모범 사례
RDS for PostgreSQL DB 인스턴스에서 블루/그린 배포를 만들 때 다음 일반 모범 사례를 고려하세요.
+ 블루/그린 배포를 생성하기 전에 모든 PostgreSQL 확장을 최신 버전으로 업데이트합니다. 자세한 내용은 [RDS for PostgreSQL 데이터베이스에서 PostgreSQL 확장 업그레이드](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md) 섹션을 참조하세요.
+ 트랜잭션이 오래 실행되면 심각한 복제 지연이 발생할 수 있습니다. 복제 지연을 줄이려면 다음과 같이 해 보세요.
+ 그린 환경이 블루 환경을 따라잡을 때까지 지연될 수 있는 장기 실행 트랜잭션을 줄이세요.
+ 그린 환경이 블루 환경을 따라잡을 때까지 블루 환경의 대량 작업을 줄이세요.
+ 블루/그린 배포를 생성하기 전에 사용량이 많은 테이블에서 수동 vacuum freeze 작업을 시작하세요.
+ PostgreSQL 버전 12 이상의 경우, 크거나 사용량이 많은 테이블에서 `index_cleanup` 파라미터를 비활성화하여 블루 데이터베이스의 일반 유지 관리 속도를 높이세요. 자세한 내용은 [테이블에 최대한 신속하게 Vacuum을 실행하는 방법](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing) 섹션을 참조하세요.
**참고**
Vacuum 중에 인덱스 정리를 정기적으로 건너뛰면 인덱스 팽창이 발생하여 스캔 성능이 저하될 수 있습니다. 블루/그린 배포를 사용하는 동안에만 이 접근 방식을 사용하는 것이 가장 좋습니다. 배포가 완료되면 정기적인 인덱스 유지 관리 및 정리를 재개하는 것이 좋습니다.
+ 복제 속도가 느리면 발신자와 수신자가 자주 다시 시작되어 동기화가 지연될 수 있습니다. 이들의 활성 상태를 유지하려면 블루 환경에서는 `wal_sender_timeout` 파라미터를 `0`으로 설정하고 그린 환경에서는 `wal_receiver_timeout` 파라미터를 `0`으로 설정하여 시간 초과를 비활성화하세요.
+ 미리 쓰기 로그(WAL) 세그먼트가 블루 환경에서 제거되지 않도록 하려면 PostgreSQL 버전 13 이하에서 `wal_keep_segments` 파라미터를 15625로 설정하세요. 버전 14 이상에서는 사용 가능한 스토리지 공간이 충분하면 `wal_keep_size` 파라미터를 1TiB로 설정하세요.
#### 물리적 복제를 사용하는 블루/그린 배포에 대한 RDS for PostgreSQL 모범 사례
물리적 복제를 사용해 Amazon RDS는 소스 DB 인스턴스의 읽기 전용 복제본을 만듭니다. 관련 파라미터, 모니터링, 조정 및 문제 해결은 [Amazon RDS for PostgreSQL의 읽기 전용 복제본 작업](USER_PostgreSQL.Replication.ReadReplicas.md) 섹션을 참조하세요.
블루/그린 배포가 논리적 복제 대신 물리적 복제를 사용하는 상황에 대한 설명은 [블루/그린 배포를 위한 PostgreSQL 복제 방법](blue-green-deployments-replication-type.md) 섹션을 참조하세요.
#### 논리적 복제를 사용하는 블루/그린 배포에 대한 RDS for PostgreSQL 모범 사례
논리적 복제를 사용하는 블루/그린 배포를 만들 때 다음 모범 사례를 고려하세요. 블루/그린 배포가 물리적 복제 대신 논리적 복제를 사용하는 상황에 대한 설명은 [블루/그린 배포를 위한 PostgreSQL 복제 방법](blue-green-deployments-replication-type.md) 섹션을 참조하세요.
+ 데이터베이스에 사용 가능한 메모리가 충분할 경우 블루 환경에서 `logical_decoding_work_mem` DB 파라미터 값을 늘립니다. 이렇게 하면 디스크 디코딩이 줄어들고 대신 메모리가 사용됩니다. 자세한 내용은 [PostgreSQL 설명서](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM)를 참조하세요.
+ `ReplicationSlotDiskUsage` CloudWatch 지표를 사용하여 디스크에 기록되는 트랜잭션 오버플로를 모니터링할 수 있습니다. 이 지표는 복제 슬롯의 디스크 사용량에 대한 인사이트를 제공하므로 트랜잭션 데이터가 메모리 용량을 초과하고 디스크에 저장되는 시점을 식별하는 데 도움이 됩니다. `FreeableMemory` CloudWatch 지표로 여유 메모리를 모니터링할 수 있습니다. 자세한 내용은 [Amazon RDS에 대한 Amazon CloudWatch 지표](rds-metrics.md#rds-cw-metrics-instance) 섹션을 참조하세요.
+ RDS for PostgreSQL 버전 14 이상에서는 `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)` 시스템 뷰를 사용하여 논리적 오버플로 파일의 크기를 모니터링할 수 있습니다.
+ `aws_s3` 확장을 사용하는 경우 그린 환경이 만들어진 후 IAM 역할을 통해 그린 DB 인스턴스에 Amazon S3에 대한 액세스 권한을 부여합니다. 이렇게 하면 전환 후에도 가져오기 및 내보내기 명령이 계속 작동합니다. 지침은 [Amazon S3 버킷에 대한 액세스 권한 설정](postgresql-s3-export-access-bucket.md) 섹션을 참조하세요.
+ UPDATE 및 DELETE 문 성능을 검토하고 WHERE 절에서 사용되는 열에 인덱스를 생성하여 이러한 쿼리를 최적화할 수 있는지 평가합니다. 이렇게 하면 그린 환경에서 작업을 재생할 때 성능이 향상될 수 있습니다.
+ 트리거를 사용하는 경우 이름이 'rds'로 시작하는 `pg_catalog.pg_publication`, `pg_catalog.pg_subscription` 및 `pg_catalog.pg_replication_slots` 객체를 만들고, 업데이트하고, 삭제하는 데 트리거가 방해가 되지 않는지 확인하세요.
+ 그린 환경에 더 높은 엔진 버전을 지정하는 경우 모든 데이터베이스에서 `ANALYZE` 작업을 실행하여 `pg_statistic` 테이블을 새로 고칩니다. 옵티마이저 통계는 메이저 버전 업그레이드 중에 전송되지 않으므로 성능 문제를 방지하려면 모든 통계를 다시 생성해야 합니다. 메이저 버전 업그레이드 중 추가 모범 사례에 대해 알아보려면 [RDS for PostgreSQL에 대한 메이저 버전 업그레이드를 수행하는 방법](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md) 섹션을 참조하세요.
+ 데이터를 조작하기 위해 트리거를 소스에 사용하는 경우 트리거를 `ENABLE REPLICA` 또는 `ENABLE ALWAYS`로 구성하지 마세요. 이렇게 구성하면 복제 시스템이 변경 내용을 전파하고 트리거를 실행하므로 중복이 발생합니다.