Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
RDS DB 인스턴스를 단일 AZ 배포에서 다중 AZ 배포로 변경하거나 다중 AZ 배포에서 단일 AZ 배포로 변경하면 어떻게 됩니까?
Amazon Relational Database Service(Amazon RDS) DB 인스턴스를 단일 AZ 배포에서 다중 AZ 배포로 변경하면 어떻게 되는지 알고 싶습니다. 또는 인스턴스를 다중 AZ 배포에서 단일 AZ 배포로 변경하면 어떻게 되는지 알고 싶습니다.
해결 방법
사용 사례에 맞는 배포 유형 선택
배포 유형을 변경하기 전에 다중 AZ 배포와 단일 AZ 배포 간의 다음 차이점을 검토하십시오.
- 단일 AZ 구성은 RDS DB 인스턴스와 Amazon Elastic Block Store(Amazon EBS) 스토리지 볼륨을 하나의 가용 영역에 배포합니다.
- 다중 AZ 구성은 인스턴스와 EBS 스토리지 볼륨을 두 가용 영역에 배포합니다.
- 다중 AZ 배포를 사용하는 경우 Amazon RDS는 데이터의 대기 사본을 유지 관리합니다. Amazon RDS는 인프라 장애를 감지하고 자동으로 복구하므로 데이터베이스 작업을 신속하게 재개할 수 있습니다.
- 단일 AZ 배포를 사용하는 경우 계획된 중단이나 계획되지 않은 중단 중에 특정 시점 복구(PITR) 작업을 시작해야 할 수 있습니다. PITR 작업을 완료하는 데 몇 시간이 걸릴 수 있습니다. 최근 복원 가능 시간 이후에 발생하는 데이터 업데이트는 사용할 수 없으므로 추가 가동 중지 시간이 발생할 수 있습니다.
- 다중 AZ 배포의 경우 Amazon RDS는 자동 백업 기간 동안 보조 인스턴스에서 DB 스냅샷과 자동 백업을 만듭니다. Amazon RDS는 Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for Oracle, Amazon RDS for PostgreSQL 데이터베이스 엔진의 보조 인스턴스에서 백업을 가져오기 때문에 백업 프로세스에서는 기본 인스턴스의 I/O 활동을 일시 중단하지 않습니다. Amazon RDS for SQL Server의 경우 백업 프로세스에서 I/O 활동이 잠시 중단됩니다.
- 단일 AZ 배포의 경우 백업 프로세스로 인해 몇 초에서 몇 분까지 지속되는 짧은 I/O 중단이 발생할 수 있습니다. 시간은 인스턴스의 크기와 클래스에 따라 다릅니다.
- 다중 AZ 배포의 경우 Amazon RDS는 운영 체제(OS) 유지 관리 및 조정 작업을 보조 인스턴스에 먼저 적용합니다. Amazon RDS는 보조 인스턴스를 기본 인스턴스로 승격한 다음, 이전 기본 인스턴스에 대한 유지 관리 또는 수정을 수행합니다. 이전 기본 인스턴스가 새 대기 인스턴스가 됩니다. 따라서 특정 OS 패치 또는 조정 작업 중에 가동 중지 시간이 최소화됩니다.
- 조정 작업 중에는 단일 AZ 인스턴스를 사용할 수 없습니다.
참고: 한 배포 유형에서 다른 배포 유형으로 변경할 때 인스턴스에 가동 중지 시간이 발생하지 않습니다.
배포 유형을 다중 AZ에서 단일 AZ로 수정
인스턴스를 다중 AZ 배포에서 단일 AZ 배포로 변경하면 Amazon RDS는 보조 인스턴스와 볼륨만 삭제합니다. 수정은 기본 인스턴스에 영향을 주지 않습니다.
배포 유형을 단일 AZ에서 다중 AZ로 수정
단일 AZ 배포에서 다중 AZ 배포로 인스턴스를 변경하면 Amazon RDS가 인스턴스 볼륨의 스냅샷을 만듭니다. Amazon RDS는 스냅샷을 사용하여 다른 가용 영역에 새 볼륨을 만듭니다. 새 볼륨은 즉시 사용할 수 있습니다.
그러나 지연 로딩으로 인해 수정 프로세스 중 및 이후에 쓰기 지연 시간이 증가할 수 있습니다. 이는 인스턴스가 백그라운드에서 Amazon Simple Storage Service(Amazon S3)의 새 볼륨 데이터를 로드하기 때문에 발생합니다. 자세한 내용은 DB 인스턴스로 복원을 참조하십시오.
발생하는 지연 시간은 볼륨 유형, 워크로드, 인스턴스 및 볼륨 크기를 기반으로 합니다. 따라서 프로덕션 인스턴스를 수정하기 전에 테스트 인스턴스를 수정하는 것이 좋습니다. 유지 관리 기간이나 처리량이 적은 기간에 인스턴스를 수정하는 것도 모범 사례입니다.
로드 기간과 쓰기 지연 시간을 줄이려면 다음 단계를 완료하십시오.
- 인스턴스의 스토리지 유형을 프로비저닝된 초당 입출력 작업량(IOPS)으로 변경합니다. 워크로드에 필요한 것보다 훨씬 높은 양의 IOPS를 프로비저닝합니다.
참고: 인스턴스가 사용자 지정 파라미터 그룹을 사용하는 경우 스토리지 유형을 변경하면 가동 중지 시간이 발생할 수 있습니다. - 배포 유형을 변경하지 않은 경우 인스턴스를 다중 AZ 배포로 수정합니다.
- 인스턴스에서 장애 조치를 시작하여 새 가용 영역이 기본 가용 영역인지 확인합니다.
- 인스턴스에서 전체 데이터 덤프를 실행합니다. 또는 가장 활발한 테이블에서 전체 테이블 스캔 쿼리를 실행하여 데이터를 볼륨에 빠르게 로드합니다.
- Amazon CloudWatch의 WriteLatency 지표를 검토하여 쓰기 지연 시간이 정상 수준으로 돌아오는지 확인합니다.
- 인스턴스의 스토리지 유형 또는 IOPS를 이전 구성으로 다시 변경합니다.
참고: 스토리지 유형을 다시 변경해도 가동 중지 시간이 발생하지 않습니다.
단일 AZ 배포에서 다중 AZ 배포로 인스턴스를 변경하면 Amazon RDS는 다른 가용 영역에 동일한 구성의 대기 인스턴스를 만듭니다. 대기 인스턴스는 추가 비용이 발생할 수 있습니다. 또한 다중 AZ 배포는 동기식 복제를 사용하므로 단일 AZ 배포에 비해 쓰기 속도가 약간 느립니다.
