Amazon RDS용 Multi-AZ DB 인스턴스 장애 조치

Amazon RDS용 Multi-AZ DB 인스턴스 장애 조치

Multi-AZ DB 인스턴스에 계획되었든 예상치 못했든 인프라 결함으로 중단이 발생하면, Amazon RDS가 자동으로 다른 가용 영역의 standby 복제본으로 전환해요. 장애 조치는 보통 60~120초 안에 완료되고, 관리를 위한 수동 개입이 필요 없답니다.

출처: 문서

본문

Multi-AZ DB 인스턴스에 인프라 결함으로 인한 계획되었거나 예상치 못한 중단이 발생하면, Amazon RDS는 자동으로 다른 가용 영역의 standby 복제본으로 전환해요.

장애 조치가 완료되는 데 걸리는 시간은 기본 DB 인스턴스를 사용할 수 없게 된 시점의 데이터베이스 활동과 기타 조건에 따라 달라져요. 장애 조치 시간은 일반적으로 60~120초예요. 하지만 대규모 트랜잭션이나 긴 복구 과정은 장애 조치 시간을 늘릴 수 있어요. 장애 조치가 완료된 후에도 RDS 콘솔에 새 가용 영역이 반영되는 데 추가 시간이 걸릴 수 있어요.

참고

Multi-AZ DB 인스턴스를 재부팅할 때 수동으로 장애 조치를 강제할 수 있어요. 자세한 내용은 DB 인스턴스 재부팅을 참고하세요.

Amazon RDS는 장애 조치를 자동으로 처리하므로 관리 개입 없이 데이터베이스 작업을 최대한 빨리 재개할 수 있어요. 다음 표에 설명된 조건 중 하나가 발생하면 기본 DB 인스턴스가 자동으로 standby 복제본으로 전환돼요. 이러한 장애 조치 이유를 이벤트 로그에서 확인할 수 있어요.

장애 조치 이유 설명
The operating system underlying the RDS database instance is being patched in an offline operation. OS 패치 또는 보안 업데이트를 위한 유지 관리 창 동안 장애 조치가 트리거됐어요. 자세한 내용은 DB 인스턴스 유지 관리를 참고하세요.
The primary host of the RDS Multi-AZ instance is unhealthy. Multi-AZ DB 인스턴스 배포가 손상된 기본 DB 인스턴스를 감지하고 장애 조치했어요.
The primary host of the RDS Multi-AZ instance is unreachable due to loss of network connectivity. RDS 모니터링이 기본 DB 인스턴스에 대한 네트워크 연결 불가 실패를 감지하고 장애 조치를 트리거했어요.
The RDS instance was modified by customer. RDS DB 인스턴스 수정이 장애 조치를 트리거했어요. 자세한 내용은 Amazon RDS DB 인스턴스 수정을 참고하세요.
The RDS Multi-AZ primary instance is busy and unresponsive. 기본 DB 인스턴스가 응답하지 않아요. 다음을 수행할 것을 권장해요. - 과도한 CPU, 메모리 또는 스왑 공간 사용에 대해 이벤트와 CloudWatch 로그를 검사하세요. 자세한 내용은 Amazon RDS 이벤트 알림 사용 및 Amazon RDS 이벤트에서 트리거되는 규칙 생성을 참고하세요. - 적절한 DB 인스턴스 클래스를 사용하고 있는지 워크로드를 평가하세요. 자세한 내용은 DB 인스턴스 클래스를 참고하세요. - 실시간 운영 체제 지표에 Enhanced Monitoring을 사용하세요. 자세한 내용은 Enhanced Monitoring으로 OS 지표 모니터링을 참고하세요. - DB 인스턴스 성능에 영향을 주는 문제를 분석하려면 Performance Insights를 사용하세요. 자세한 내용은 Amazon RDS의 Amazon CloudWatch Database Insights로 DB 부하 모니터링을 참고하세요. 이러한 권장 사항에 대한 자세한 내용은 Amazon RDS 모니터링 도구 및 Amazon RDS 모범 사례를 참고하세요.
The storage volume underlying the primary host of the RDS Multi-AZ instance experienced a failure. Multi-AZ DB 인스턴스 배포가 기본 DB 인스턴스의 스토리지 문제를 감지하고 장애 조치했어요.
The user requested a failover of the DB instance. DB 인스턴스를 재부팅하고 Reboot with failover를 선택했어요. 자세한 내용은 DB 인스턴스 재부팅을 참고하세요.

Multi-AZ DB 인스턴스가 장애 조치되었는지 확인하려면 다음을 수행할 수 있어요.

  • DB 이벤트 구독을 설정해 장애 조치가 시작되었을 때 이메일이나 SMS로 알림을 받는다. 이벤트에 대한 자세한 내용은 Amazon RDS 이벤트 알림 사용을 참고하세요.
  • RDS 콘솔 또는 API 작업으로 DB 이벤트를 조회한다.
  • RDS 콘솔 또는 API 작업으로 Multi-AZ DB 인스턴스 배포의 현재 상태를 확인한다.

장애 조치에 대응하는 방법, 복구 시간을 줄이는 방법, 기타 Amazon RDS 모범 사례에 대한 내용은 Amazon RDS 모범 사례를 참고하세요.

DNS 이름 조회의 JVM TTL 설정

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

JVM은 DNS 이름 조회를 캐시해요. JVM이 호스트 이름을 IP 주소로 확인할 때, TTL(time-to-live)이라고 알려진 지정된 기간 동안 IP 주소를 캐시해요.

AWS 리소스가 때때로 변경되는 DNS 이름 항목을 사용하기 때문에, JVM에 TTL 값을 60초 이하로 구성할 것을 권장해요. 이렇게 하면 리소스의 IP 주소가 변경될 때 애플리케이션이 DNS를 다시 조회해 리소스의 새 IP 주소를 받아 사용할 수 있어요.

일부 Java 구성에서는 JVM 기본 TTL이 JVM을 다시 시작할 때까지 DNS 항목을 새로 고치지 않도록 설정돼 있어요. 따라서 애플리케이션이 실행되는 동안 AWS 리소스의 IP 주소가 변경되면, JVM을 수동으로 다시 시작하고 캐시된 IP 정보를 새로 고칠 때까지 리소스를 사용할 수 없어요. 이 경우 JVM의 TTL을 설정해 캐시된 IP 정보를 주기적으로 새로 고치도록 하는 것이 중요해요.

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을 사용하는 모든 애플리케이션에 속성 값을 전역으로 설정하려면 $JAVA_HOME/jre/lib/security/java.security 파일에 networkaddress.cache.ttl을 설정하세요.
networkaddress.cache.ttl=60
  • 애플리케이션에만 속성을 로컬로 설정하려면 네트워크 연결이 설정되기 전에 애플리케이션의 초기화 코드에서 networkaddress.cache.ttl을 설정하세요.
java.security.Security.setProperty("networkaddress.cache.ttl" , "60");

더 알아보기 (Learn more)