Amazon RDS를 위한 고가용성(다중 AZ) - Amazon Relational Database Service

Amazon RDS를 위한 고가용성(다중 AZ)

Amazon RDS는 다중 AZ 배포를 사용해 DB 인스턴스에 고가용성과 장애 조치 기능을 지원합니다. Amazon RDS는 다양한 기술을 이용해 장애 조치 지원을 제공합니다. MariaDB, MySQL, Oracle 및 PostgreSQL DB 인스턴스용 다중 AZ 배포는 Amazon의 장애 조치 기술을 사용합니다. SQL Server DB 인스턴스는 SQL Server 데이터베이스 미러링(DBM) 또는 상시 가동 가용성 그룹(AG)을 사용합니다. 다중 AZ에 대한 SQL Server 버전 지원에 대한 자세한 내용은 Amazon RDS for Microsoft SQL Server의 다중 AZ 배포 섹션을 참조하세요.

다중 AZ 배포에서 Amazon RDS는 자동으로 서로 다른 가용 영역에 동기식 예비 복제본을 프로비저닝하고 유지합니다. 기본 DB 인스턴스는 가용 영역에서 예비 복제본으로 동기식으로 복제되어 데이터 이중화를 제공하고 I/O 중지를 제거하며 시스템 백업 시 지연 시간 스파이크를 최소화합니다. DB 인스턴스를 고가용성으로 실행하면 계획된 시스템 유지 관리 중 가용성을 향상시킬 수 있으며, 데이터베이스에 DB 인스턴스 오류 및 가용 영역 중단이 일어나는 것을 방지할 수 있습니다. 가용 영역에 대한 자세한 정보는 리전, 가용 영역 및 로컬 영역 단원을 참조하십시오.

참고

고가용성 기능은 읽기 전용 시나리오의 확장 솔루션이 아니므로 예비 복제본을 사용하여 읽기 트래픽을 지원할 수 없습니다. 읽기 전용 트래픽을 지원하려면 대신에 읽기 복제본을 사용합니다. 자세한 내용은 읽기 전용 복제본 작업 섹션을 참조하세요.


            고가용성 시나리오

RDS 콘솔을 사용하여 DB 인스턴스 생성 시 다중 AZ를 지정함으로써 간편하게 다중 AZ 배포를 생성할 수 있습니다. 콘솔을 사용하여 DB 인스턴스를 수정하고 다중 AZ 옵션을 지정함으로써 기존 DB 인스턴스를 다중 AZ 배포로 변환할 수 있습니다. 또한 AWS CLI 또는 Amazon RDS API를 사용하여 다중 AZ 배포를 지정할 수도 있습니다. create-db-instance 또는 modify-db-instance CLI 명령을 사용하거나 CreateDBInstance 또는 ModifyDBInstance API 작업을 사용합니다.

RDS 콘솔에 예비 복제본(보조 AZ라고 함)의 가용 영역이 표시됩니다. 또한 describe-db-instances CLI 명령 또는 DescribeDBInstances API 작업을 사용하여 보조 AZ를 찾을 수도 있습니다.

다중 AZ 배포를 사용하는 DB 인스턴스는 동기식 데이터 복제 발생으로 인해 단일 AZ 배포에 비해 쓰기 및 커밋 지연 시간이 길어질 수 있습니다. AWS는 가용 영역 간 지연 시간이 짧은 네트워크 연결을 제공하도록 설계되었지만 배포가 예비 복제본으로 장애 조치될 경우 지연 시간이 변경될 수 있습니다. 프로덕션 워크로드의 경우, 빠르고 일관된 성능을 구현하도록 프로비저닝된 IOPS에 최적화된 프로비저닝된 IOPS 및 DB 인스턴스 클래스를 사용하는 것이 좋습니다. DB 인스턴스 클래스에 대한 자세한 내용은 DB 인스턴스 클래스 섹션을 참조하십시오.

다중 AZ 배포가 되도록 DB 인스턴스 수정

단일 AZ 배포에 DB 인스턴스가 있고 이 배포를 다중 AZ 배포로 수정하는 경우(Amazon Aurora 이외의 엔진의 경우) Amazon RDS에서는 여러 단계를 수행합니다. 우선 Amazon RDS는 배포에서 기본 DB 인스턴스의 스냅샷을 캡처한 후 이 스냅샷을 또 다른 가용 영역으로 복원합니다. 그런 다음 Amazon RDS는 기본 DB 인스턴스와 새 인스턴스 간에 동기식 복제를 설정합니다.

DB 인스턴스 수정에 대한 자세한 내용은 Amazon RDS DB 인스턴스 수정 단원을 참조하십시오.

중요

이 작업을 통해 단일 AZ에서 다중 AZ로 변환할 때 다운타임을 방지할 수 있지만 다중 AZ로 변환하는 동안 또는 변환한 후 성능에 영향을 미칠 수 있습니다. 이 영향은 쓰기 집약적인 대규모 DB 인스턴스의 경우 상당할 수 있습니다.

DB 인스턴스에 다중 AZ를 활성화하기 위해 RDS는 기본 DB 인스턴스의 EBS 볼륨 스냅샷을 캡처하여 새로 생성된 예비 복제본에서 복원한 다음 두 볼륨을 동기화합니다. 기존 EBS 스냅샷을 이용해 생성한 새 볼륨은 백그라운드에 느리게 로드됩니다. 이 기능을 사용하면 스냅샷에서 대용량 볼륨을 신속하게 복원할 수 있지만 수정이 완료된 동안 그리고 완료된 후 지연 시간이 추가될 수 있습니다. 자세한 내용은 Amazon EC2 설명서의 스냅샷에서 Amazon EBS 볼륨 복원을 참조하십시오.

수정이 완료되면 Amazon RDS는 과정 완료를 표시하는 이벤트(RDS-EVENT-0025)를 트리거합니다. Amazon RDS 이벤트를 모니터링할 수 있습니다. 이벤트에 대한 자세한 정보는 Amazon RDS 이벤트 알림 서비스 사용 단원을 참조하십시오.

Amazon RDS 장애 조치 프로세스

다중 AZ를 활성화한 경우, DB 인스턴스에 계획되거나 계획되지 않은 중단이 발생하면 Amazon RDS는 자동으로 다른 가용 영역에 있는 예비 복제본으로 전환합니다. 장애 조치가 완료되는 데 소요되는 시간은 기본 DB 인스턴스를 사용할 수 없게 된 시점의 데이터베이스 활동 및 기타 조건에 따라 달라집니다. 장애 조치에 소요되는 시간은 일반적으로 60–120초입니다. 그러나 트랜잭션의 규모가 크거나 복구 프로세스가 복잡한 경우 장애 조치에 소요되는 시간이 증가할 수 있습니다. 장애 조치가 완료되면 RDS 콘솔에 새 가용 영역이 반영되는 데 시간이 더 걸릴 수 있습니다.

참고

DB 인스턴스를 재부팅할 때 장애 조치를 수동으로 강제할 수 있습니다. 자세한 내용은 DB 인스턴스 재부팅 섹션을 참조하세요.

Amazon RDS는 자동으로 장애 조치를 취하여 관리자의 개입 없이 데이터베이스 작업을 신속하게 재개할 수 있도록 합니다. 다음 표에 설명된 조건 중 하나가 발생하면 기본 DB 인스턴스는 자동으로 예비 복제본으로 전환됩니다. 이 장애 조치 이유는 이벤트 로그에서 확인할 수 있습니다.

장애 조치 이유 설명
RDS 데이터베이스 인스턴스 기반의 운영 체제가 오프라인 작업에서 패치되고 있습니다.

OS 패치 또는 보안 업데이트를 위한 유지 관리 기간 동안 장애 조치가 트리거되었습니다.

자세한 내용은 DB 인스턴스 유지 관리 섹션을 참조하세요.

RDS 다중 AZ 인스턴스의 기본 호스트가 비정상입니다. 다중 AZ 배포에서 손상된 기본 DB 인스턴스를 감지하여 장애 조치했습니다.
네트워크 연결 손실로 인해 RDS 다중 AZ 인스턴스의 기본 호스트에 연결할 수 없습니다.

RDS 모니터링이 기본 DB 인스턴스에 대한 네트워크 연결 실패를 감지하여 장애 조치를 트리거했습니다.

RDS 인스턴스를 고객이 수정했습니다.

RDS DB 인스턴스 수정 때문에 장애 조치가 트리거되었습니다.

자세한 내용은 Amazon RDS DB 인스턴스 수정 섹션을 참조하세요.

RDS 다중 AZ 기본 인스턴스가 사용 중이며 응답하지 않습니다.

기본 DB 인스턴스가 응답하지 않습니다. 다음을 수행하는 것이 좋습니다.

이러한 권장 사항에 대한 자세한 내용은 Amazon RDS 모니터링 개요Amazon RDS의 모범 사례 단원을 참조하세요.

RDS 다중 AZ 인스턴스의 기본 호스트 기반의 스토리지 볼륨에 오류가 발생했습니다. 다중 AZ 배포에서 기본 DB 인스턴스의 스토리지 문제를 감지하여 장애 조치했습니다.
사용자가 DB 인스턴스의 장애 조치를 요청했습니다.

사용자가 DB 인스턴스를 재부팅하고 장애 조치를 사용하여 재부팅을 선택했습니다.

자세한 내용은 DB 인스턴스 재부팅 섹션을 참조하세요.

몇 가지 방법을 통해 다중 AZ DB 인스턴스에 장애 조치가 취해졌는지 확인할 수 있습니다.

  • 장애 조치가 시작되었음을 이메일이나 SMS를 통해 알리도록 DB 이벤트 구독을 설정할 수 있습니다. 이벤트에 대한 자세한 내용은 단원을 참조하십시오Amazon RDS 이벤트 알림 서비스 사용

  • Amazon RDS 콘솔 또는 API 작업을 사용하여 DB 이벤트를 확인할 수 있습니다.

  • Amazon RDS 콘솔 및 API 작업을 통해 다중 AZ 배포의 현재 상태를 확인할 수 있습니다.

장애 조치, 복구 시간 절감 및 기타 Amazon RDS 모범 사례에 대한 자세한 정보는 Amazon RDS의 모범 사례 단원을 참조하십시오.

DNS 이름 조회를 위한 JVM TTL 설정

장애 조치 메커니즘은 DB 인스턴스의 Domain Name System(DNS) 레코드가 예비 DB 인스턴스를 가리키도록 자동으로 변경합니다. 그 결과 DB 인스턴스의 기존 연결을 모두 재설정해야 합니다. Java 가상 머신(JVM) 환경에서 Java DNS 캐싱 메커니즘이 작동하는 방식 때문에 JVM 설정을 다시 구성해야 할 수 있습니다.

JVM은 DNS 이름 조회를 캐시합니다. JVM은 호스트 이름을 IP 주소로 확인하는 경우 Time-To-Live(TTL)라고 하는 지정된 기간 동안 IP 주소를 캐시합니다.

AWS 리소스는 간헐적으로 변경되는 DNS 이름 항목을 사용하므로 TTL 값을 60초 이하로 하여 JVM을 구성하는 것이 좋습니다. 이렇게 하면 리소스의 IP 주소가 변경될 때 애플리케이션이 DNS를 다시 쿼리하여 리소스의 새 IP 주소를 수신하고 사용할 수 있습니다.

일부 Java 구성에서는 JVM이 재시작될 때까지 DNS 항목을 새로 고치지 않도록 JVM 기본 TTL이 설정됩니다. 따라서 애플리케이션이 여전히 실행되는 동안 AWS 리소스의 IP 주소가 변경되는 경우 JVM을 수동으로 재시작하여 캐시된 IP 정보가 새로 고쳐질 때까지는 해당 리소스를 사용할 수 없습니다. 이 경우 캐시된 IP 정보를 정기적으로 새로 고치도록 JVM의 TTL을 설정하는 것이 중요합니다.

참고

기본 TTL은 JVM 버전과 보안 관리자 설치 여부에 따라 다를 수 있습니다. 대부분의 JVM은 60초 미만의 기본 TTL을 제공합니다. 이러한 JVM을 사용 중이며 보안 관리자는 사용하지 않는 경우 이 주제의 나머지 내용을 무시해도 좋습니다. Oracle의 보안 관리자에 대한 자세한 내용은 Oracle 설명서의 The Security Manager를 참조하십시오.

JVM의 TTL을 수정하려면 networkaddress.cache.ttl 속성 값을 설정합니다. 필요에 따라 다음 방법 중 하나를 사용합니다.

  • JVM을 사용하는 모든 애플리케이션에 대해 전역적으로 속성 값을 설정하려면 networkaddress.cache.ttl 파일에서 $JAVA_HOME/jre/lib/security/java.security을 설정합니다.

    networkaddress.cache.ttl=60
  • 애플리케이션에만 로컬로 속성을 설정하려면 네트워크 연결이 설정되기 전에 애플리케이션의 초기화 코드에서 networkaddress.cache.ttl을 설정합니다.

    java.security.Security.setProperty("networkaddress.cache.ttl" , "60");