단일 AZ Amazon RDS 인스턴스를 다중 AZ 인스턴스로 또는 그 반대로 변환하면 어떤 영향이 있습니까?

최종 업데이트 날짜: 2022년 5월 19일

단일 AZ Amazon Relational Database Service(Amazon RDS) DB 인스턴스를 다중 AZ 인스턴스로 전환할 때의 영향을 알고 싶습니다.

-또는-

다중 AZ Amazon RDS DB 인스턴스를 단일 AZ 인스턴스로 전환할 때의 영향을 알고 싶습니다.

간략한 설명

단일 AZ 설정에서는 하나의 Amazon RDS DB 인스턴스와 하나 이상의 Amazon Elastic Block Store(Amazon EBS) 스토리지 볼륨이 하나의 가용 영역에 배포됩니다. 다중 AZ 구성에서는 DB 인스턴스와 EBS 스토리지 볼륨이 두 개의 가용 영역에 배포됩니다.

인스턴스에서 다중 AZ를 활성화하면 Amazon RDS는 동기식 스토리지 복제를 사용하여 데이터의 중복되고 일관된 예비 사본을 유지 관리합니다. Amazon RDS는 다중 AZ 배포에 대한 가장 일반적인 인프라 장애 시나리오를 탐지한 후 자동으로 복구합니다. 이 검색 및 복구는 가능한 빨리 데이터베이스 작업을 재개할 수 있도록 수행됩니다. 자세한 내용은 Amazon RDS용 고가용성(다중 AZ)을 참조하세요.

DB 인스턴스를 단일 AZ 배포에서 다중 AZ 배포로 또는 그 반대로 전환하려면 Amazon RDS 인스턴스 수정을 참조하세요.

해결 방법

단일 AZ 인스턴스 수정이 다중 AZ 인스턴스에 미치는 영향

단일 AZ 인스턴스를 다중 AZ로 수정하면 인스턴스에 가동 중단이 발생하지 않습니다. 수정 중에 Amazon RDS는 인스턴스 볼륨의 스냅샷을 생성합니다. 그런 다음 이 스냅샷은 다른 가용 영역에 새 볼륨을 생성하는 데 사용됩니다. 이러한 새 볼륨은 즉시 사용할 수 있지만 일부 성능 문제가 발생할 수 있습니다. 이러한 영향은 새 볼륨의 데이터가 여전히 Amazon Simple Storage Service(Amazon S3)에서 로드되고 있기 때문에 발생합니다. 그때까지는 DB 인스턴스가 백그라운드에서 데이터를 계속 로드합니다. 지연 로딩이라고 하는 이 프로세스는 쓰기 대기 시간을 늘리고 조절 중 및 조절 후에 성능에 영향을 줄 수 있습니다.

성능에 미치는 영향의 수준은 볼륨 유형, 워크로드, 인스턴스 및 볼륨 크기에 따라 달라집니다. 이러한 영향은 작업 피크 시간 동안 쓰기 집약적인 대규모 DB 인스턴스에 상당한 영향을 줄 수 있습니다. 따라서 프로덕션 환경에서 이러한 수정 사항을 실행하기 전에 테스트 인스턴스에 미치는 영향을 테스트하는 것이 좋습니다. 유지 관리 또는 처리량이 적은 기간에 이 수정을 완료하는 것도 모범 사례입니다.

로딩 시간 단축

로딩의 지속 시간과 영향을 사전에 줄이려면 다음을 수행합니다.

  1. DB 인스턴스의 스토리지 유형을 프로비저닝된 IOPS로 변경합니다. 워크로드에 필요한 것보다 훨씬 많은 양의 IOPS를 프로비저닝해야 합니다.
    참고: 인스턴스에서 사용자 지정 파라미터 그룹을 사용하는 경우 이 단계로 인해 잠시 중단 시간이 발생할 수 있습니다.
  2. 인스턴스를 다중 AZ로 변경합니다.
  3. 인스턴스에서 장애 조치를 시작하여 새 AZ가 기본 AZ인지 확인합니다.
  4. 인스턴스에서 데이터 전체 비우기를 실행합니다. 또는 가장 활성화된 테이블에서 전체 테이블 스캔 쿼리를 실행하여 데이터를 볼륨으로 신속하게 로드할 수 있습니다.
  5. Amazon CloudWatch에서 WriteLatency 지표를 검토하여 쓰기 대기 시간이 정상 수준으로 돌아갔는지 확인합니다.
  6. 인스턴스의 스토리지 유형 또는 IOPS를 이전 구성으로 다시 변경합니다.
    참고: 이 단계에는 가동 중지 시간이 필요하지 않습니다.

인스턴스가 이미 다중 AZ인 경우 대기 시간 감소

인스턴스를 다중 AZ로 이미 수정한 경우 대기 시간을 줄이려면 다음을 수행합니다.

  1. 인스턴스에서 장애 조치를 시작하여 새 AZ가 기본 AZ인지 확인합니다.
  2. DB 인스턴스의 스토리지 유형을 프로비저닝된 IOPS로 변경합니다. 워크로드에 필요한 것보다 훨씬 많은 양의 IOPS를 프로비저닝해야 합니다.
    참고: 이 단계에는 가동 중지 시간이 필요하지 않습니다.
  3. 인스턴스에서 데이터 전체 비우기를 실행합니다. 또는 가장 활성화된 테이블에서 전체 테이블 스캔 쿼리를 실행하여 데이터를 볼륨으로 신속하게 로드할 수 있습니다.

  4. Amazon CloudWatch에서 WriteLatency 지표를 검토하여 쓰기 대기 시간이 정상 수준으로 돌아갔는지 확인합니다.

  5. 인스턴스의 스토리지 유형 또는 IOPS를 이전 구성으로 다시 변경합니다.
    참고: 이 단계에는 가동 중지 시간이 필요하지 않습니다.

DB 인스턴스를 단일 AZ에서 다중 AZ로 변환하면 다른 가용 영역에 동일한 구성으로 새 인스턴스가 생성됩니다. 이로 인해 추가 비용이 발생합니다. 또한 다중 AZ는 동기식 복제를 사용하기 때문에 단일 AZ의 쓰기 작업보다 쓰기 속도가 약간 느립니다.

다중 AZ 인스턴스 수정이 단일 AZ 인스턴스에 미치는 영향

인스턴스를 다중 AZ에서 단일 AZ로 변경할 때 인스턴스에 가동 중지 시간이 발생하지 않습니다. 수정하는 동안 Amazon RDS는 보조 인스턴스와 볼륨만 삭제하며 기본 인스턴스는 영향을 받지 않습니다.

다음은 인스턴스를 다중 AZ에서 단일 AZ 배포로 수정하기 전에 고려해야 할 몇 가지 사항입니다.

  • 다중 AZ 배포를 사용하면 Amazon RDS가 DB 인스턴스의 계획된 또는 예상치 못한 중단이 발생하는 동안 다른 가용 영역에 있는 예비 복제본으로 자동 전환됩니다. 그러나 단일 AZ 인스턴스에서는 특정 시점으로 복원 작업을 시작해야 할 수 있습니다. 이 작업은 완료하는 데 몇 시간이 걸릴 수 있습니다. 가장 최근에 복원 가능한 시간 이후에 발생한 데이터 업데이트는 사용할 수 없습니다. 따라서 장애가 발생할 경우 단일 AZ 인스턴스에서 추가 가동 중단이 발생할 수 있습니다.
  • 다중 AZ 인스턴스에서는 자동 백업 기간 동안 보조 인스턴스에서 자동 백업이 생성됩니다. Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for Oracle 및 Amazon RDS for PostgreSQL의 경우 다중 AZ 배포를 백업하는 동안 기본 인스턴스에서 백업이 수행되므로 기본 인스턴스에서 I/O 작업이 일시 중단되지 않습니다. Amazon RDS for SQL Server의 경우 다중 AZ 배포를 위해 백업하는 동안 I/O 작업이 잠시 중단됩니다. 단일 AZ DB 인스턴스의 백업 프로세스를 수행하면 몇 초에서 몇 분까지 지속될 수 있는 짧은 I/O 일시 중단이 발생합니다. 시간은 DB 인스턴스의 크기와 클래스에 따라 다릅니다.
  • 다중 AZ 배포에서는 운영 체제 유지 관리가 보조 인스턴스에 우선 적용됩니다. 보조 인스턴스가 기본 인스턴스로 승격된 다음 새 예비 인스턴스인 이전 기본 인스턴스에서 유지 관리가 수행됩니다. 따라서 다중 AZ 인스턴스의 특정 OS 패치 중 가동 중지 시간이 최소화됩니다.
  • 다중 AZ 인스턴스를 크기 조정하는 경우, 가동 중단이 최소화됩니다. 이는 보조 인스턴스가 먼저 수정되기 때문입니다. 보조 인스턴스가 기본 인스턴스로 승격됩니다. 그런 다음 이전 현재는 보조 인스턴스인 기존의 기본 인스턴스가 수정됩니다. 크기 조정 작업 중에는 단일 AZ 인스턴스를 사용할 수 없게 됩니다.

이 문서가 도움이 되었나요?


결제 또는 기술 지원이 필요합니까?