Amazon Aurora의 고가용성
Amazon Aurora 아키텍처는 스토리지와 컴퓨팅이 분리됩니다. Aurora에는 DB 클러스터의 데이터에 적용되는 몇 가지 고가용성 기능이 포함되어 있습니다. 클러스터의 일부 또는 모든 DB 인스턴스를 사용할 수 없는 경우에도 데이터는 안전하게 유지됩니다. 다른 고가용성 기능이 DB 인스턴스에 적용됩니다. 이러한 기능은 하나 이상의 DB 인스턴스가 애플리케이션의 데이터베이스 요청을 처리할 수 있도록 준비하는 데 도움이 됩니다.
주제
Aurora 데이터의 고가용성
Aurora는 단일 AWS 리전에서 다중 가용 영역에 걸쳐 DB 클러스터에 데이터 복사본을 저장합니다. Aurora는 DB 클러스터의 인스턴스가 여러 가용성 영역에 걸쳐 있는지 여부에 관계없이 이러한 복사본을 저장합니다. Aurora에 대한 자세한 내용은 Amazon Aurora DB 클러스터 관리 단원을 참조하십시오.
기본 DB 인스턴스에 데이터가 기록되면 Aurora에서 가용 영역의 데이터를 클러스터 볼륨과 연결된 6개의 스토리지 노드에 동기적으로 복제합니다. 이 방법은 데이터 중복을 제공하고, I/O 중지를 없애고, 시스템 백업 중에 지연 시간 스파이크를 최소화합니다. DB 인스턴스를 고가용성으로 실행하면 계획된 시스템 유지 관리 중 가용성을 향상시킬 수 있으며, 데이터베이스에서 오류 및 가용 영역 중단이 일어나는 것을 방지할 수 있습니다. 가용 영역에 대한 자세한 정보는 리전 및 가용 영역 단원을 참조하십시오.
Aurora DB 인스턴스의 고가용성
기본(라이터) 인스턴스를 생성한 후에 최대 15개의 읽기 전용 Aurora 복제본을 생성할 수 있습니다. Aurora 복제본은 리더 인스턴스로도 알려져 있습니다.
일상적인 작업 중에 리더 인스턴스에서 SELECT 쿼리를 처리하여 읽기 집약적 응용 프로그램의 일부 작업을 오프로드할 수 있습니다. 문제가 기본 인스턴스에 영향을 미치는 경우 이러한 리더 인스턴스 중 하나가 기본 인스턴스 역할을 인수합니다. 이 메커니즘을 장애 조치(failover)라고 합니다. 많은 Aurora 기능이 장애 조치 메커니즘에 적용됩니다. 예를 들어 Aurora는 데이터베이스 문제를 감지하고 필요한 경우 장애 조치 메커니즘을 자동으로 활성화합니다. 또한 Aurora는 장애 조치 완료 시간을 단축하는 기능을 갖추고 있습니다. 이렇게 하면 장애 조치 중에 데이터베이스를 쓰기에 사용할 수 없는 시간이 최소화됩니다.
Aurora는 최대한 빨리 복구하도록 설계되었으며, 가장 빠른 복구 경로는 대개 동일한 DB 인스턴스를 다시 시작하거나 장애 조치하는 것입니다. 재시작은 장애 조치보다 더 빠르고 오버헤드가 적습니다.
장애 조치로 인해 새 기본 인스턴스를 승격하는 경우에도 동일하게 유지되는 연결 문자열을 사용하려면 클러스터 엔드포인트에 연결합니다. 클러스터 엔드포인트는 항상 클러스터의 현재 기본 인스턴스를 나타냅니다. 클러스터 엔드포인트에 대한 자세한 내용은 Amazon Aurora 엔드포인트 연결 섹션을 참조하세요.
작은 정보
각 AWS 리전 내에서 가용 영역(AZ)은 중단이 발생할 경우 격리를 제공하기 위해 서로 구별되는 위치를 나타냅니다. DB 클러스터의 가용성을 개선하려면 여러 가용 영역에 걸쳐 있는 DB 클러스터에 기본 인스턴스와 리더 인스턴스를 배포하는 것이 좋습니다. 이렇게 하면 전체 가용 영역에 영향을 미치는 문제로 인해 클러스터가 중단되지 않습니다.
클러스터를 생성할 때 간단한 선택을 수행하여 다중 AZ DB 클러스터를 설정할 수 있습니다. AWS Management Console, AWS CLI 또는 Amazon RDS API를 사용할 수 있습니다. 또한 새 리더 DB 인스턴스를 추가하고 다른 가용 영역을 지정하여 기존 Aurora DB 클러스터를 다중 AZ DB 클러스터로 만들 수 있습니다.
Aurora Global Database를 사용한 AWS 리전 간 고가용성
여러 AWS 리전 간의 고가용성을 위해 Aurora Global Database를 설정할 수 있습니다. 각각의 Aurora Global Database는 여러 AWS 리전에 걸쳐 있어, 대기 시간이 짧은 글로벌 읽기와 AWS 리전에 걸쳐 중단에 대한 재해 복구를 지원합니다. Aurora는 기본 AWS 리전에서 각 보조 영역으로 모든 데이터 및 업데이트 복제를 자동으로 처리합니다. 자세한 내용은 Amazon Aurora 글로벌 데이터베이스 사용 단원을 참조하십시오.
Aurora DB 클러스터의 내결함성
Aurora DB 클러스터는 내결함성을 고려하여 설계되었습니다. 클러스터 볼륨은 단일 AWS 리전에 속하는 다중 가용 영역(AZ)을 모두 아우르며, 각 가용 영역에는 클러스터 볼륨 데이터의 사본이 복사됩니다. 이 기능은 가용 영역 한 곳에서 결함이 발생하더라도 DB 클러스터가 잠시 서비스가 중단될 뿐 전혀 데이터 손실 없이 결함을 견딜 수 있음을 의미합니다.
DB 클러스터의 기본 인스턴스에 결함이 발생하면 Aurora는 다음 두 가지 방법 중 하나를 사용하여 자동으로 새 기본 인스턴스로 장애 조치합니다.
-
기존 Aurora 복제본을 새 기본 인스턴스로 승격시킴
-
새로운 기본 인스턴스 만들기
DB 클러스터에 Aurora 복제본이 하나 이상인 경우에는 장애가 발생하더라도 Aurora 복제본이 기본 인스턴스로 승격됩니다. 이 실패 이벤트로 인해 예외적으로 실패하는 읽기 및 쓰기 작업 동안 짧은 중단이 발생합니다. 하지만, 일반적인 서비스 복구 시간은 60초 미만이지만 대부분 30초 미만에 복원됩니다. DB 클러스터의 가용성을 높이려면 최소 하나 이상의 Aurora 복제본을 둘 이상의 다른 가용 영역에 생성하는 것이 바람직합니다.
작은 정보
Aurora MySQL 2.10 이상에서는 클러스터에 리더 DB 인스턴스를 2개 이상 보유하여 장애 조치 중에 가용성을 개선할 수 있습니다. Aurora MySQL 2.10 이상에서 Aurora는 장애 조치 대상인 라이터 DB 인스턴스와 리더 인스턴스만 다시 시작합니다. 클러스터의 다른 리더 인스턴스는 장애 조치 중에 리더 엔드포인트에 대한 연결을 통해 쿼리를 처리하는 데 계속해서 사용할 수 있습니다.
Aurora DB 클러스터와 함께 RDS 프록시를 사용하여 장애 조치 중에 가용성을 개선할 수도 있습니다. 자세한 내용은 Amazon RDS 프록시를 사용하는 고가용성 단원을 참조하십시오.
각 복제본에 우선 순위를 지정함으로써 장애 이후 기본 인스턴스로 승격할 Aurora 복제본 순서를 사용자 지정할 수 있습니다. 우선 순위 범위는 가장 높은 값인 0부터 가장 낮은 값인 15까지입니다. 기본 인스턴스에 결함이 발생하면 Amazon RDS는 우선순위가 가장 높은 Aurora 복제본을 새로운 기본 인스턴스로 승격시킵니다. Aurora 복제본의 우선 순위는 언제든지 수정할 수 있습니다. 우선 순위 수정으로 인해 장애 조치가 트리거되지는 않습니다.
둘 이상의 Aurora 복제본이 동일한 우선 순위를 공유하여 승격 계층을 만들 수도 있습니다. 둘 이상의 Aurora 복제본이 동일한 우선 순위를 공유하면 Amazon RDS는 크기가 가장 큰 복제본을 승격시킵니다. 둘 이상의 Aurora Replicas가 동일한 우선 순위와 크기를 공유하면 Amazon RDS는 동일한 승격 티어에서 임의의 복제본을 승격시킵니다.
DB 클러스터에 Aurora 복제본이 포함되어 있지 않으면 기본 인스턴스가 실패 이벤트 중에 동일한 AZ에 다시 생성됩니다. 이 실패 이벤트로 인해 예외적으로 실패하는 읽기 및 쓰기 작업 동안 중단이 발생합니다. 새로운 기본 인스턴스가 생성도면 서비스도 복구되지만 보통 10분 미만의 시간이 걸립니다. Aurora 복제본을 기본 인스턴스로 승격시키는 것이 기본 인스턴스를 새로 생성하는 것보다 훨씬 빠릅니다.
전체 AZ에 영향을 미치는 중단으로 인해 클러스터의 기본 인스턴스를 사용할 수 없다고 가정해 보겠습니다. 이 경우, 새 기본 인스턴스를 온라인 상태로 만드는 방법은 클러스터가 다중 AZ 구성을 사용하는지 여부에 따라 달라집니다.
-
프로비저닝 클러스터 또는 Aurora Serverless v2 클러스터에 다른 AZ의 리더 인스턴스가 포함되어 있는 경우, Aurora은(는) 장애 조치 메커니즘을 사용하여 해당 리더 인스턴스 중 하나를 새 기본 인스턴스로 승격시킵니다.
-
프로비저닝된 클러스터 또는 Aurora Serverless v2 클러스터에 단일 DB 인스턴스만 포함되어 있거나 기본 인스턴스와 모든 리더 인스턴스가 동일한 AZ에 있는 경우, 다른 AZ에 하나 이상의 새 DB 인스턴스를 수동으로 생성해야 합니다.
-
클러스터에서 Aurora Serverless v1을(를) 사용하는 경우 Aurora은(는) 다른 AZ에 새 DB 인스턴스를 자동으로 생성합니다. 그러나 이 프로세스에는 호스트 교체가 수반되므로 장애 조치보다 시간이 더 오래 걸립니다.
참고
Amazon Aurora는 외부 MySQL 데이터베이스 또는 RDS MySQL DB 인스턴스의 복제도 지원합니다. 자세한 내용은 Aurora과 MySQL 간의 복제 또는 Aurora와 다른 Aurora DB 클러스터(이진 로그 복제본) 간의 복제 단원을 참조하십시오.
Amazon RDS 프록시를 사용하는 고가용성
RDS 프록시를 사용하면 복잡한 장애 처리 코드를 작성할 필요 없이 데이터베이스 장애를 투명하게 견딜 수 있는 애플리케이션을 구축할 수 있습니다. 프록시는 애플리케이션 연결을 유지하면서 트래픽을 새 데이터베이스 인스턴스로 자동 라우팅합니다. 또한 도메인 이름 시스템(DNS) 캐시를 우회하여 Aurora 다중 AZ 데이터베이스의 장애 조치 시간을 최대 66% 단축합니다. 자세한 내용은 Aurora용 Amazon RDS 프록시 사용 단원을 참조하십시오.
