블루/그린 배포 관련 제한 사항 및 고려 사항 - Amazon Aurora
제한 사항고려 사항

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

Amazon RDS에서 블루/그린 배포를 하려면 복제 슬롯, 리소스 관리, 인스턴스 크기 조정, 데이터베이스 성능에 미치는 잠재적 영향과 같은 요소를 신중하게 고려해야 합니다. 다음 섹션은 데이터베이스 환경의 가동 중지 시간을 최소화하고, 원활한 전환을 보장하고, 효과적으로 관리할 수 있도록 배포 전략을 최적화하는 데 도움이 되는 지침을 제공합니다.

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

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

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

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

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

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

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

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

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

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

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

  • 블루 DB 클러스터를 해당하는 그린 DB 클러스터보다 높은 엔진 버전으로 변경할 수 없습니다.

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

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

    • Amazon RDS 프록시

    • 리전 간 읽기 전용 복제본

    • Aurora Serverless v1 DB 클러스터

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

    • AWS CloudFormation

블루/그린 배포에 대한 Aurora MySQL 제한 사항

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

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

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

  • 블루 DB 클러스터는 외부 binlog 복제본이 될 수 없습니다.

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

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

블루/그린 배포에 대한 Aurora PostgreSQL 제한 사항

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

  • 11.21 이상, 12.16 이상, 13.12 이상, 14.9 이상, 15.4 이상, 16.1 이상 버전의 Auroa PostgreSQL은 업그레이드 소스 및 대상 버전으로 지원됩니다. 하위 버전의 경우 지원되는 버전으로 마이너 버전 업그레이드를 수행할 수 있습니다.

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

  • 블루 DB 클러스터는 자체 관리형 논리적 소스(게시자) 또는 복제본(구독자)일 수 없습니다.

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

  • 블루/그린 배포에서는 각 데이터베이스에 논리적 복제 슬롯이 필요합니다. 데이터베이스 수가 늘어나면 리소스 오버헤드가 증가하고, 특히 DB 클러스터 규모가 충분히 조정되지 않은 경우 복제 지연이 발생할 수 있습니다. 영향은 데이터베이스 워크로드 및 연결 수와 같은 요인에 따라 달라집니다. 이를 완화하려면 DB 인스턴스 클래스 규모를 조정하거나 소스 클러스터의 데이터베이스 수를 줄이는 것이 좋습니다.

  • 블루/그린 배포를 만들 때는 블루 환경에서 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 실행 계획 캡처 단원을 참조하십시오.

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

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

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

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

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

제한 사항 설명
CREATE TABLE 및 CREATE SCHEMA와 같은 데이터 정의 언어(DDL) 문은 블루 환경에서 그린 환경으로 복제되지 않습니다.

Aurora가 블루 환경에서 DDL 변경을 감지하면 그린 데이터베이스는 복제 성능 저하 상태로 전환됩니다.

블루 환경의 DDL 변경 사항을 그린 환경으로 복제할 수 없음을 알리는 이벤트가 수신됩니다. 블루/그린 배포와 모든 그린 데이터베이스를 삭제한 다음 다시 생성해야 합니다. 이렇게 하지 않으면 블루/그린 배포를 전환할 수 없습니다.
시퀀스 객체에 대한 NEXTVAL 작업은 블루 환경과 그린 환경 간에 동기화되지 않습니다.

전환 중에 Aurora는 그린 환경의 시퀀스 값을 증가시켜 블루 환경의 시퀀스 값과 일치하도록 합니다. 수천 개의 시퀀스가 있는 경우 전환이 지연될 수 있습니다.
블루 환경에서 큰 객체를 만들거나 수정해도 그린 환경에는 복제되지 않습니다.

Aurora가 블루 환경에서 pg_largeobject 시스템 테이블에 저장된 대형 객체의 생성 또는 수정을 감지하면 그린 데이터베이스는 복제 성능 저하 상태로 전환됩니다.

Aurora는 블루 환경의 대규모 객체 변경 사항을 그린 환경에 복제할 수 없음을 알리는 이벤트를 생성합니다. 블루/그린 배포와 모든 그린 데이터베이스를 삭제한 다음 다시 생성해야 합니다. 이렇게 하지 않으면 블루/그린 배포를 전환할 수 없습니다.

그린 환경에서는 구체화된 뷰가 자동으로 새로 고쳐지지 않습니다.

블루 환경에서 구체화된 뷰를 새로 고쳐도 그린 환경에서는 새로 고쳐지지 않습니다. 전환 후에는 REFRESH MATERIALIZED VIEW 명령을 사용하여 수동으로 새로 고치거나 새로 고침 일정을 예약할 수 있습니다.

프라이머리프라이머리 키가 없는 테이블에서는 UPDATE 및 DELETE 작업이 허용되지 않습니다.

블루/그린 배포를 생성하기 전에 DB 클러스터의 모든 테이블에 프라이머리프라이머리 키가 있는지 확인하세요.

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

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

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 호출 모니터링 단원을 참조하십시오.

  • 블루 환경의 리소스에 데이터베이스 활동 스트림을 사용한다면, 전환 후 새 스트림에 대한 데이터베이스 이벤트를 모니터링하도록 애플리케이션을 조정하십시오. 자세한 내용은 데이터베이스 활동 스트림을 지원하는 리전 및 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 인스턴스를 계속 사용합니다.