AWS re:Post을(를) 사용하면 다음에 동의하게 됩니다. 이용 약관

AWS Aurora Global Database를 사용한 Cross-Region 장애조치

5분 분량
중급
1

AWS Aurora Global Database 의 개념을 이해하고 리전간 복제 서비스를 활성화 하여, 특정 지역의 서비스 장애시 리전간 장애조치를 할 수 있는 방법에 대해서 알아보도록 합니다.

Aurora Global Database를 사용한 Cross-Region 장애조치

Author : Sungwook Kang(강성욱), AWS Solutions Architect

Amazon Aurora Global Database는 여러 AWS 리전에 걸쳐 있고 대기 시간이 짧은 글로벌 읽기를 지원하기 때문에, 전세계 지역에서 실행되는 애플리케이션들은 가까운 리전의 Aurora Global Database에서 서비스를 제공받기 때문에 안정적이며 빠른 서비스를 제공할 수 있습니다. 또한 Aurora Global Database는 데이터를 마스터링하는 하나의 기본 AWS 리전 및 최대 5개의 읽기 전용 보조 AWS 리전으로 구성되기 때문에, AWS 리전에서 장애 발생시 신속하게 다른 리전으로 복구할 수 있습니다. Aurora Global Database는 아래와 같은 장점을 가지고 있습니다.

  • 로컬 대기 시간으로 글로벌 읽기 : 전 세계에 지사를 두고 있는 경우, Aurora Global Database를 사용하여 기본 AWS 리전에서 정보의 주요 소스를 최신 상태로 유지할 수 있습니다. 다른 리전의 사무실은 로컬 지연 시간을 사용하여 해당 리전의 정보에 액세스할 수 있습니다.
  • 확장 가능한 보조 Aurora DB 클러스터 : AWS 리전에 읽기 전용 인스턴스(Aurora 복제본)를 추가하여 보조 클러스터를 확장할 수 있습니다. 세컨더리 클러스터는 읽기 전용이므로 단일 Aurora 클러스터에 대하여 일반적인 제한인 15개가 아닌 최대 16개의 읽기 전용 Aurora 복제본 인스턴스를 지원할 수 있습니다.
  • 기본 DB클러스터에서 보조 Aurora DB 클러스터로의 빠른 복제 : Aurora Global Database에서 수행되는 복제는 기본 DB 클러스터의 성능에 거의 영향을 미치지 않습니다. DB 인스턴스의 리소스는 애플리케이션 읽기/쓰기 워크로드 처리 전용입니다.
  • 리전 전체의 운영 중단으로부터 복구 : 보조 클러스터를 사용하면 기존 복제 솔루션보다 적은 데이터 손실(더 낮은 RPO)로 새로운 기본 AWS 리전에서 Aurora Global Database를 보다 신속하게(더 낮은 RTO) 가용 상태로 만들 수 있습니다.

Aurora Global Database는 한 리전의 기본(Primary) Aurora 클러스터와 다른 리전의 보조(Secondary) Aurora 클러스터로 생성됩니다. Aurora 글로벌 데이터베이스는 Aurora 전용 스토리지 계층의 전용 인프라를 사용하여 리전 간 복제를 처리 합니다. 스토리지 계층의 전용 복제 서버가 복제를 처리하므로 시스템 로드 중에도 데이터베이스 성능을 저하시키지 않으면서 향상된 복구 및 가용성 목표를 달성할 수 있습니다. Aurora Global Database는 물리적 스토리지 수준 복제를 사용하여 동일한 데이터 세트로 기본 데이터베이스의 복제본을 생성하므로 논리적 복제 프로세스에 대한 종속성이 제거됩니다. 아래 그림은 기본(Primary) 및 보조(Secondary) 리전에 걸쳐 있는 Aurora 클러스터가 있는 Aurora 글로벌 데이터베이스 입니다.

pic1

Aurora Global Database 복제과정은 아래와 같습니다.

  1. Aurora 클러스터의 기본 인스턴스는 Primary 리전의 스토리지 노드, 복제본 인스턴스 및 복제 서버에 병렬로 로그 레코드를 전달합니다.
  2. Primary 리전의 복제 서버는 로그 레코드를 Secondary 리전의 복제 에이전트로 스트리밍 합니다.
  3. 복제 에이전트는 Secondary 리전의 스토리지 노드 및 복제본 인스턴스에 병렬로 로그 레코드를 전달합니다.
  4. Secondary 리전의 복제 서버는 스토리지 노드에서 로그 레코드를 가져와 동기화 합니다.

Aurora 스토리지 시스템은 단일 리전 내의 3개 가용 영역에 걸쳐 6개의 데이터 복사본을 자동으로 유지 관리하고 데이터 손실 없이 정상적인 가용 영역에서 데이터베이스 복구를 자동으로 시도하므로 내구성과 가용성이 크게 향상 됩니다. 쓰기 쿼럼은 6개 복사본 중 4개의 쿼럼 승인이 필요하고 읽기 쿼럼은 보호 그룹의 6개 구성원 중 3개 입니다. 데이터는 최종 사용자에 대한 성능 영향 없이 실시간으로 Aurora를 사용하여 Amazon Simple Storage Service(Amazon S3)에 지속적으로 백업 됩니다.

아래 그림은 기본 리전에서 여러 보조 리전으로 물리적 스토리지 수준 아웃바운드 복제가 있는 Aurora 글로벌 데이터베이스를 나타냅니다.

pic2

Aurora 글로벌 데이터베이스를 사용하여 각 보조 리전에서 최대 5개의 보조 리전과 최대 16개의 읽기 전용 복제본을 구성할 수 있습니다. 각 보조 클러스터는 기본 클러스터 및 다른 보조 클러스터와 다른 리전에 있어야 합니다.

Aurora 글로벌 데이터베이스를 사용하면 장애조치에 대한 두 가지 접근 방식 중에서 선택할 수 있습니다.

  • 관리형 계획 장애조치 : 기본 DB 클러스터를 Aurora 글로벌 데이터베이스의 보조 리전 중 하나로 재배치 합니다. 이 기능을 사용하면 RPO가 0(데이터 손실 없음)이고 다른 변경을 수행하기 전에 보조 DB 클러스터를 기본 클러스터와 동기화 합니다. 이 자동화된 프로세스의 RTO는 일반적으로 수동 장애조치의 RTO보다 적습니다.
  • 계획되지 않은 수동 장애조치 : 계획되지 않은 중단에서 복구하기 위해 Aurora 글로벌 데이터베이스의 보조 데이터베이스 중 하나로 교차 리전 장애조치를 수동으로 수행할 수 있습니다. 이 수동 프로세스의 RTO는 계획되지 않은 중단에서 Aurora 글로벌 데이터베이스를 얼마나 빨리 수동으로 복구할 수 있는지에 따라 다릅니다. RPO는 일반적으로 초 단위로 측정되지만 오류 발생 시 네트워크 전체의 Aurora 스토리지 복제 지연에 따라 다릅니다.

Aurora Global Database사용시 수동 장애조치가 어떻게 이루어지는지 살펴보겠습니다.
기본 리전에서 Writer 인스턴스에서 읽기 및 쓰기를 수행하고 읽기 전용 복제본에서만 읽기를 수행하는 Aurora 클러스터에 연결된 애플리케이션과 보조 리전에서 읽기 전용 복제본에서 읽기만 수행하는 Aurora 클러스터에 연결된 애플리케이션이 있습니다. Amazon Route 53 (CNAME 레코드)은 장애조치 및 재구성으로 인해 애플리케이션을 다시 연결하기 위해 수행해야 하는 수동 작업의 양을 최소화하기 위해 Aurora 리더 및 라이터 엔드포인트를 가리키도록 생성됩니다.

pic3

전체 지역의 인프라 또는 서비스를 기본 지역에서 사용할 수 없게 되거나, 잠재적은 성능 저하 또는 격리 문제가 발생할 경우, 보조 클러스터를 기본 클러스터로 승격하도록 수동으로 장애조치를 시작하거나 스크립트를 작성할 수 있습니다. 장애조치 시 RPO에 의해 수량화된 잠재적 데이터 손실을 이해할 수 있어야 합니다.

pic4

장애조치가 완료되면 승격된 리전(이전 보조 리전)이 새로운 기본 Aurora 클러스터 역할을 하며 1분 이내에 전체 읽기 및 쓰기 워크로드를 처리할 수 있으므로 애플리케이션 가동 시간에 대한 영향이 최소화 됩니다. 이전 기본 리전의 인프라 또는 서비스를 사용할 수 있게 되거나 리전을 추가하면 계획되지 않은 중단 중에 애플리케이션에서 읽기 워크로드만 가져오는 새로운 보조 Aurora 클러스터 역할을 할 수 있습니다.

pic5

Reference