Amazon RDS 블루/그린 배포 모범 사례 - Amazon Relational Database Service
블루/그린 배포 일반 모범 사례블루/그린 배포에 대한 RDS for MySQL 모범 사례블루/그린 배포 모범 사례에 대한 RDS for PostgreSQL 모범 사례

Amazon RDS 블루/그린 배포 모범 사례

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

블루/그린 배포 일반 모범 사례

블루/그린 배포를 만들 때 다음 일반 모범 사례를 고려하세요.

  • 전환하기 전에 DB 인스턴스를 철저하게 테스트합니다.

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

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

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

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

    참고

    이 제한 사항은 물리적 복제를 사용하는 RDS for PostgreSQL 블루/그린 배포에는 적용되지 않습니다. 자세한 내용은 물리적 복제를 사용하는 블루/그린 배포에 대한 RDS for PostgreSQL 제한 사항 섹션을 참조하세요.

  • 블루/그린 배포를 생성한 후 필요하다면 지연 로딩을 처리합니다. 전환하기 전에 데이터 로드가 완료되었는지 확인합니다. 자세한 내용은 블루/그린 배포를 위한 지연 로딩 및 스토리지 초기화 섹션을 참조하세요.

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

블루/그린 배포에 대한 RDS for MySQL 모범 사례

RDS for MySQL DB 인스턴스에서 블루/그린 배포를 만들 때 다음 모범 사례를 고려하세요.

  • 복제에 최적화되지 않은 MyISAM 같은 비트랜잭션 스토리지 엔진 사용은 자제하시기 바랍니다.

  • 이진 로그 복제용 읽기 전용 복제본 및 그린 환경을 최적화합니다. DB 엔진에서 지원하는 경우 GTID, 병렬 및 충돌 방지 복제를 활성화하여 블루/그린 배포를 생성하기 전에 데이터 일관성과 내구성을 보장합니다. 자세한 내용은 GTID 기반 복제 사용 섹션을 참조하세요.

  • 그린 환경에 복제본 지연이 발생하는 경우 다음을 고려하세요.

    • 그린 DB 파라미터 그룹에서 innodb_flush_log_at_trx_commit 파라미터를 일시적으로 2으로 설정합니다. 복제가 최신 상태로 동기화된 후 전환하기 전에 1의 기본값으로 되돌립니다. 임시 파라미터 값에서 예기치 않은 종료 또는 충돌이 발생하는 경우 탐지되지 않은 데이터 손상을 방지하기 위해 그린 환경을 다시 빌드합니다.

    • 쓰기 지연 시간을 줄이고 복제 처리량을 개선하기 위해 그린 다중 AZ DB 인스턴스를 일시적으로 단일 AZ DB 인스턴스로 변경합니다. 전환 직전에 다중 AZ를 다시 활성화합니다.

블루/그린 배포 모범 사례에 대한 RDS for PostgreSQL 모범 사례

RDS for PostgreSQL DB 인스턴스에서 블루/그린 배포를 만들 때 다음 모범 사례를 고려하세요.

블루/그린 배포에 대한 RDS for PostgreSQL 일반 모범 사례

RDS for PostgreSQL DB 인스턴스에서 블루/그린 배포를 만들 때 다음 일반 모범 사례를 고려하세요.

  • 블루/그린 배포를 생성하기 전에 모든 PostgreSQL 확장을 최신 버전으로 업데이트합니다. 자세한 내용은 RDS for PostgreSQL 데이터베이스에서 PostgreSQL 확장 업그레이드 섹션을 참조하세요.

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

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

    • 그린 환경이 블루 환경을 따라잡을 때까지 블루 환경의 대량 작업을 줄이세요.

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

    • PostgreSQL 버전 12 이상의 경우, 크거나 사용량이 많은 테이블에서 index_cleanup 파라미터를 비활성화하여 블루 데이터베이스의 일반 유지 관리 속도를 높이세요. 자세한 내용은 테이블에 최대한 신속하게 Vacuum을 실행하는 방법 섹션을 참조하세요.

      참고

      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의 읽기 전용 복제본 작업 섹션을 참조하세요.

블루/그린 배포가 논리적 복제 대신 물리적 복제를 사용하는 상황에 대한 설명은 섹션을 참조하세요.

논리적 복제를 사용하는 블루/그린 배포에 대한 RDS for PostgreSQL 모범 사례

논리적 복제를 사용하는 블루/그린 배포를 만들 때 다음 모범 사례를 고려하세요. 블루/그린 배포가 물리적 복제 대신 논리적 복제를 사용하는 상황에 대한 설명은 섹션을 참조하세요.

  • 데이터베이스에 사용 가능한 메모리가 충분할 경우 블루 환경에서 logical_decoding_work_mem DB 파라미터 값을 늘립니다. 이렇게 하면 디스크 디코딩이 줄어들고 대신 메모리가 사용됩니다. 자세한 내용은 PostgreSQL 설명서를 참조하세요.

    • ReplicationSlotDiskUsage CloudWatch 지표를 사용하여 디스크에 기록되는 트랜잭션 오버플로를 모니터링할 수 있습니다. 이 지표는 복제 슬롯의 디스크 사용량에 대한 인사이트를 제공하므로 트랜잭션 데이터가 메모리 용량을 초과하고 디스크에 저장되는 시점을 식별하는 데 도움이 됩니다. FreeableMemory CloudWatch 지표로 여유 메모리를 모니터링할 수 있습니다. 자세한 내용은 Amazon RDS에 대한 Amazon CloudWatch 지표 섹션을 참조하세요.

    • RDS for PostgreSQL 버전 14 이상에서는 pg_stat_replication_slots 시스템 뷰를 사용하여 논리적 오버플로 파일의 크기를 모니터링할 수 있습니다.

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

  • UPDATE 및 DELETE 문 성능을 검토하고 WHERE 절에서 사용되는 열에 인덱스를 생성하여 이러한 쿼리를 최적화할 수 있는지 평가합니다. 이렇게 하면 그린 환경에서 작업을 재생할 때 성능이 향상될 수 있습니다.

  • 트리거를 사용하는 경우 이름이 'rds'로 시작하는 pg_catalog.pg_publication, pg_catalog.pg_subscription 및 pg_catalog.pg_replication_slots 객체를 만들고, 업데이트하고, 삭제하는 데 트리거가 방해가 되지 않는지 확인하세요.

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

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