다중 AZ DB 인스턴스 배포 - Amazon Relational Database Service
다중 AZ DB 인스턴스 배포가 되도록 DB 인스턴스 수정Amazon RDS 장애 조치 프로세스

다중 AZ DB 인스턴스 배포

Amazon RDS는 단일 대기 DB 인스턴스와 함께 다중 AZ 배포를 사용하여 DB 인스턴스에 대한 고가용성 및 장애 조치 지원을 제공합니다. 이러한 유형의 배포를 다중 AZ DB 인스턴스 배포라고 합니다. Amazon RDS는 다양한 기술을 통해 장애 조치 지원을 제공합니다. MariaDB, MySQL, Oracle, RDS Custom for SQL Server DB인스턴스용 다중 AZ 배포는 Amazon의 장애 조치 기술을 사용합니다. Microsoft SQL Server DB 인스턴스는 SQL Server 데이터베이스 미러링(DBM) 또는 상시 가동 가용성 그룹(AG)을 사용합니다. 다중 AZ에 대한 SQL Server 버전 지원에 대한 자세한 내용은 Amazon RDS for Microsoft SQL Server의 다중 AZ 배포 섹션을 참조하세요. RDS Custom for SQL Server로 다중 AZ 작업을 수행하는 방법에 대한 내용은 RDS Custom for SQL Server에 대한 다중 AZ 배포 구성 및 관리 섹션을 참조하세요.

다중 AZ DB 인스턴스 배포에서 Amazon RDS는 자동으로 서로 다른 가용 영역에 동기식 대기 복제본을 프로비저닝하고 유지합니다. 프라이머리 DB 인스턴스는 전체 가용 영역에서 대기 복제본으로 동기식으로 복제되어 시스템 백업 중에 데이터 이중화를 제공하고 대기 시간 급증을 최소화합니다. DB 인스턴스를 고가용성으로 실행하면 계획된 시스템 유지 관리 중 가용성을 높일 수 있습니다. 또한, DB 인스턴스 오류 및 가용 영역 중단이 일어나지 않도록 방지할 수 있습니다. 가용 영역에 대한 자세한 내용은 리전, 가용 영역 및 로컬 영역 단원을 참조하세요.

참고

고가용성 옵션은 읽기 전용 시나리오에서는 확장 솔루션이 아닙니다. 대기 복제본을 사용하여 읽기 트래픽을 처리할 수 없습니다. 읽기 전용 트래픽을 처리하려면 대신 다중 AZ DB 클러스터 또는 읽기 전용 복제본을 사용해야 합니다. 다중 AZ DB 클러스터에 대한 자세한 내용은 다중 AZ DB 클러스터 배포 섹션을 참조하세요. 읽기 전용 복제본에 대한 자세한 내용은 DB 인스턴스 읽기 전용 복제본 작업을 참조하세요.

고가용성 시나리오

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

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

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

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

단일 AZ 배포에 DB 인스턴스가 있고 이를 다중 AZ DB 인스턴스 배포(Amazon Aurora 이외의 엔진용)로 수정하는 경우 Amazon RDS는 다음과 같은 몇 가지 작업을 수행합니다.

  1. 기본 DB 인스턴스의 Amazon Elastic Block Store(EBS) 볼륨의 스냅샷을 만듭니다.

  2. 스냅샷에서 스탠바이 복제본용 새 볼륨을 생성합니다. 이러한 볼륨은 백그라운드에서 초기화되며 데이터가 완전히 초기화된 후에 최대 볼륨 성능이 달성됩니다.

  3. 기본 복제본과 대기 복제본의 볼륨 간의 동기 블록 수준 복제를 켭니다.

중요

스냅샷을 사용하여 대기 인스턴스를 생성하면 단일 AZ에서 다중 AZ로 변환할 때 가동 중지 시간을 피할 수 있지만 다중 AZ로 변환하는 동안과 후에 성능에 영향을 미칠 수 있습니다. 이는 쓰기 대기 시간에 민감한 워크로드에 상당한 영향을 미칠 수 있습니다.

이 기능을 사용하면 스냅샷에서 대용량 볼륨을 신속하게 복원할 수 있지만, 이로 인해 동기식 복제로 인해 I/O 작업의 지연 시간이 상당히 증가할 수 있습니다. 이러한 지연 시간은 데이터베이스 성능에 영향을 줄 수 있습니다. 모범 사례로서 프로덕션 DB 인스턴스에서는 다중 AZ 변환을 수행하지 않는 것이 좋습니다.

현재 민감한 워크로드를 처리하는 DB 인스턴스의 성능 영향을 피하려면 읽기 전용 복제본을 만들고 읽기 전용 복제본에서 백업을 활성화해야 합니다. 읽기 전용 복제본을 다중 AZ로 변환하고 읽기 전용 복제본의 볼륨(두 AZ 모두에서)에 데이터를 로드하는 쿼리를 실행합니다. 그러면 복제본이 기본 DB 인스턴스로 승격됩니다. 자세한 내용은 DB 인스턴스 읽기 전용 복제본 작업 단원을 참조하십시오.

다중 AZ DB 인스턴스 배포가 되도록 DB 인스턴스 수정하는 방법은 2가지가 있습니다.

RDS 콘솔을 사용하여 다중 AZ DB 인스턴스 배포로 변환

RDS 콘솔을 사용하여 DB 인스턴스를 다중 AZ DB 인스턴스 배포로 변환할 수 있습니다.

콘솔만 사용하여 변환을 완료할 수 있습니다. AWS CLI 또는 RDS API를 사용하려면 다중 AZ DB 인스턴스 배포가 되도록 DB 인스턴스 수정의 지침을 따르십시오.

RDS 콘솔을 사용하여 다중 AZ DB 인스턴스 배포로 변환하려면

  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 탐색 창에서 데이터베이스를 선택한 다음 변경하려는 DB 인스턴스를 선택합니다.

  3. Actions(작업)에서 Convert to Multi-AZ deployment(다중 AZ 배포로 변환)를 선택합니다.

  4. 확인 페이지에서 Apply immediately(즉시 적용)을 선택하여 변경 사항을 즉시 적용합니다. 이 옵션을 선택하면 다운타임이 발생하지 않지만 성능이 영향을 받을 수 있습니다. 다음 유지 관리 기간에 업데이트를 적용하도록 선택할 수도 있습니다. 자세한 내용은 수정 일정 설정 단원을 참조하십시오.

  5. Convert to Multi-AZ(다중 AZ로 변환)를 선택합니다.

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

다음과 같은 방법으로 다중 AZ DB 인스턴스 배포가 되도록 DB 인스턴스를 수정할 수 있습니다.

  • RDS 콘솔을 사용하여 DB 인스턴스를 수정하고 Multi-AZ deployment(다중 AZ 배포)를 Yes(예)로 설정합니다.

  • AWS CLI를 사용하여 modify-db-instance 명령을 호출하고 --multi-az 옵션을 설정합니다.

  • RDS API를 사용하여 ModifyDBInstance 작업을 호출하고 MultiAZ 파라미터를 true로 설정합니다.

DB 인스턴스 수정에 대한 자세한 내용은 Amazon RDS DB 인스턴스 수정 단원을 참조하세요. 수정이 완료되면 Amazon RDS는 과정 완료를 표시하는 이벤트(RDS-EVENT-0025)를 트리거합니다. Amazon RDS 이벤트를 모니터링할 수 있습니다. 이벤트에 대한 자세한 내용은 Amazon RDS 이벤트 알림 작업 단원을 참조하세요.

Amazon RDS 장애 조치 프로세스

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

참고

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

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

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

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

자세한 내용은 DB 인스턴스 유지 관리 섹션을 참조하세요.
RDS 다중 AZ 인스턴스의 기본 호스트가 비정상입니다. 다중 AZ DB 인스턴스 배포에서 손상된 프라이머리 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 인스턴스를 재부팅하고 장애 조치를 사용하여 재부팅을 선택했습니다.

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

다음 단계에 따라 다중 AZ DB 인스턴스가 장애 조치를 수행했는지 확인할 수 있습니다.

  • 장애 조치가 시작되었음을 이메일 또는 SMS로 사용자에게 알리도록 DB 이벤트 구독을 설정합니다. 이벤트에 대한 자세한 내용은 Amazon RDS 이벤트 알림 작업 단원을 참조하세요.

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

  • RDS 콘솔 또는 API 작업을 사용하여 다중 AZ DB 인스턴스 배포의 현재 상태를 확인합니다.

장애 조치, 복구 시간 절감 및 기타 Amazon RDS 모범 사례에 대한 자세한 내용은 Amazon RDS의 모범 사례 단원을 참조하세요.

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

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

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

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

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

networkaddress.cache.ttl 속성 값을 검색하여 JVM 기본 TTL을 가져올 수 있습니다.


String ttl = java.security.Security.getProperty("networkaddress.cache.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");