Amazon Neptune 재해 복구 수행 - Amazon Neptune
분리 및 승격계획된 관리형 장애 조치

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amazon Neptune 재해 복구 수행

Neptune 글로벌 데이터베이스는 독립형 Neptune DB 클러스터보다 더 포괄적인 장애 조치 기능을 제공합니다. 글로벌 데이터베이스를 사용하면 재해를 대비하고 신속하게 복구할 수 있습니다. 재해 복구는 일반적으로 복구 시간 목표(RTO) 및 복구 시점 목표()를 평가하여 평가합니다RPO.

  • 복구 시간 목표(RTO) - 재해 발생 후 시스템이 작업 상태로 돌아가는 속도입니다. 즉, 는 가동 중지 시간을 RTO 측정합니다. Neptune 글로벌 데이터베이스의 경우 는 분 단위로 표시될 RTO 수 있습니다.

  • 복구 시점 목표(RPO) - 데이터가 손실되는 시간입니다. Neptune 글로벌 데이터베이스의 경우 RPO는 일반적으로 초 단위로 측정됩니다( 참조Neptune 글로벌 데이터베이스에 대한 계획된 관리형 장애 조치 수행).

Neptune 글로벌 데이터베이스의 경우, 장애 조치를 수행하는 2가지 다른 접근 방식이 있습니다.

  • Detach-and-promote (수동 계획되지 않은 복구) - 계획되지 않은 중단에서 복구하거나 재해 복구 테스트(DR 테스트)를 수행하려면 글로벌 데이터베이스의 보조 DB 클러스터 중 하나에서 교차 리전 detach-and-promote을 수행합니다. 이 수동 프로세스의 RTO 는 에 나열된 작업을 얼마나 빨리 수행할 수 있는지에 따라 달라집니다분리 및 승격. RPO 는 일반적으로 몇 초이지만 장애 발생 시 네트워크 전반의 스토리지 복제 지연에 따라 달라집니다.

  • 계획된 관리형 장애 조치   —   이 접근 방식은 글로벌 데이터베이스의 기본 DB 클러스터를 보조 리전 중 하나로 재배치하는 등 운영 유지 관리 및 기타 계획된 운영 절차를 위한 것입니다. 이 프로세스는 다른 변경을 수행하기 전에 보조 DB 클러스터를 프라이머리와 동기화하기 때문에 RPO는 효과적으로 0(즉, 데이터 손실 없음)입니다. Neptune 글로벌 데이터베이스에 대한 계획된 관리형 장애 조치 수행을 참조하세요.

Detach-and-promote 예상치 못한 중단 시 Neptune 글로벌 데이터베이스

Neptune 글로벌 데이터베이스가 기본 에서 예기치 않은 중단을 경험하는 매우 드문 상황에서 AWS 리전는 기본 Neptune DB 클러스터와 라이터 노드를 사용할 수 없게 되고 기본 클러스터와 보조 의 복제가 중단됩니다. 결과 가동 중지 시간(RTO)과 데이터 손실()을 모두 최소화하려면 리전 간 detach-and-promote을 RPO빠르게 수행하여 글로벌 데이터베이스를 재구성합니다.

작은 정보

수행하기 전에 이 프로세스를 이해하고 리전 전반에 문제 발생을 처음 알아차린 즉시 진행할 수 있는 계획을 세우는 것이 좋습니다.

  • Amazon을 CloudWatch 정기적으로 사용하여 보조 클러스터의 지연 시간을 추적하면 장애 조치가 필요한 경우 지연 시간이 가장 짧은 보조 리전을 식별할 수 있습니다.

  • 계획을 테스트하여 절차가 완전하고 정확한지 확인하세요.

  • 시뮬레이션된 환경을 사용하여 직원이 교육을 받아 필요할 경우 DR 장애 조치를 신속하게 수행할 수 있도록 준비되었는지 확인해야 합니다.

기본 리전에서 계획되지 않은 중단 후 보조 클러스터로 장애 조치하려면

  1. 기본 DB 클러스터에서 변형 쿼리 및 기타 쓰기 작업을 더 이상 실행하지 마십시오.

  2. 글로벌 데이터베이스의 새 기본 DB 클러스터로 AWS 리전 사용할 보조 의 DB 클러스터를 식별합니다. 글로벌 데이터베이스에 보조 AWS 리전이 2개 이상 있는 경우 지연 시간이 가장 짧은 보조 클러스터를 선택합니다.

  3. Neptune 글로벌 데이터베이스에서 선택한 보조 DB 클러스터를 분리합니다.

    Neptune 글로벌 데이터베이스에서 보조 DB 클러스터를 제거하면 기본 클러스터에서 보조 클러스터로의 데이터 복제가 즉시 중지되고, 전체 읽기/쓰기 기능을 갖춘 독립 실행형 DB 클러스터로 승격됩니다. 글로벌 데이터베이스의 다른 보조 클러스터는 계속 사용할 수 있으며, 애플리케이션의 읽기 호출을 수락할 수 있습니다.

    Neptune 글로벌 데이터베이스를 재생성하기 전에 클러스터 간의 데이터 불일치를 방지하기 위해 다른 보조 클러스터도 분리해야 합니다(클러스터 제거 참조).

  4. 새 엔드포인트를 사용하여 새 기본 클러스터로 선택한 독립형 Neptune DB 클러스터로 모든 쓰기 작업을 전송하도록 애플리케이션을 재구성합니다. Neptune 글로벌 데이터베이스 생성 시의 기본 이름을 수락한 경우, 애플리케이션에 있는 클러스터의 엔드포인트 문자열에서 -ro를 제거하여 엔드포인트를 변경할 수 있습니다.

    예를 들어, 보조 클러스터의 엔드포인트 my-global.cluster-ro-aaaaaabbbbbb.us-west-1.neptune.amazonaws.com는 해당 클러스터가 글로벌 데이터베이스에서 분리될 때 my-global.cluster-aaaaaabbbbbb.us-west-1.neptune.amazonaws.com이 됩니다.

    이 Neptune DB 클러스터는 다음 단계에서 리전을 추가하기 시작하면 새 Neptune 글로벌 데이터베이스의 기본 클러스터가 됩니다.

  5. DB 클러스터에 AWS 리전 를 추가합니다. 이렇게 하면 기본 클러스터에서 보조 클러스터로의 복제 프로세스가 시작됩니다. Amazon Neptune의 기본 리전에 보조 글로벌 데이터베이스 리전 추가 을 참조하세요.

  6. 필요에 AWS 리전 따라 를 추가하여 애플리케이션을 지원하는 데 필요한 토폴로지를 다시 생성합니다.

애플리케이션 쓰기가 이러한 변경 전, 중, 후에 올바른 Neptune DB 클러스터로 전송되는지 확인합니다. 이렇게 하면 브레인 분할 문제라고 하는 Neptune 글로벌 데이터베이스의 DB 클러스터 간 데이터 불일치를 방지할 수 있습니다.

Neptune 글로벌 데이터베이스에 대한 계획된 관리형 장애 조치 수행

계획된 관리형 장애 조치를 사용하면 Neptune 글로벌 데이터베이스의 기본 클러스터를 언제든지 다른 로 재배치할 AWS 리전 수 있습니다. 일부 조직에서는 기본 클러스터 위치를 정기적으로 교체하려고 합니다.

참고

여기에서 설명하는 계획된 관리형 장애 조치 프로세스는 정상적인 Neptune 글로벌 데이터베이스에서 사용하도록 되어 있습니다. 계획되지 않은 중단에서 복구하거나 재해 복구(DR) 테스트를 수행하려면 분리 및 승격 프로세스를 따르세요.

계획된 관리형 장애 조치 중에 글로벌 데이터베이스의 기존 복제 토폴로지가 유지되는 동안 기본 클러스터는 선택한 보조 리전으로 장애 조치됩니다. 계획된 관리형 장애 조치 프로세스가 시작되기 전에 글로벌 데이터베이스는 모든 보조 클러스터를 기본 클러스터와 동기화합니다. 모든 클러스터가 동기화되었는지 확인되면 계획된 관리형 장애 조치가 시작됩니다. 기본 리전의 DB 클러스터가 읽기 전용이 되고, 선택한 보조 클러스터는 읽기 전용 인스턴스 중 하나를 전체 라이터 상태로 승격하여 클러스터가 기본 클러스터의 역할을 맡을 수 있습니다. 프로세스 시작 시 모든 보조 클러스터가 기본 클러스터와 동기화되었으므로, 새로운 기본 클러스터는 데이터 손실 없이 글로벌 데이터베이스에 대한 작업을 계속합니다. 기본 클러스터와 선택한 보조 클러스터가 새 역할을 맡으므로, 데이터베이스를 잠시 사용할 수 없습니다.

애플리케이션 가용성을 최적화하려면 기본 DB 클러스터에 대한 쓰기가 최소인 사용량이 적은 시간에 장애 조치를 수행하면 됩니다. 장애 조치를 시작하기 전에 다음 단계도 수행합니다.

  • 가능한 경우 애플리케이션을 오프라인 상태로 전환하여 기본 클러스터에 대한 쓰기 횟수를 줄입니다.

  • 글로벌 데이터베이스에 있는 모든 보조 Neptune DB 클러스터의 지연 시간을 확인하고 전체 지연 시간이 가장 적은 보조 클러스터를 기본 클러스터로 선택합니다. Amazon CloudWatch 을 사용하여 모든 보조 항목에 대한 NeptuneGlobalDBProgressLag 지표를 봅니다. 이 지표는 보조 DB 클러스터가 기본 DB 클러스터에 얼마나 뒤처져 있는지 밀리초 단위로 알려줍니다. 이 값은 Neptune이 장애 조치를 완료하는 데 걸리는 시간과 정비례합니다. 즉, 지연 값이 클수록 장애 조치 중단 시간이 길어지므로 지연 시간이 가장 적은 보조 클러스터를 선택해야 합니다. 자세한 내용은 Neptune CloudWatch 지표 섹션을 참조하세요.

계획된 관리형 장애 조치 중에 선택한 보조 DB 클러스터가 새 기본 DB 클러스터 역할로 승격되지만, 기본 DB 클러스터의 전체 구성을 상속하지는 않습니다. 구성이 일치하지 않으면 성능 문제, 워크로드 비호환성, 기타 비정상적인 동작이 발생할 수 있습니다. 이러한 문제를 방지하려면 장애 조치 전에 글로벌 데이터베이스 클러스터 간의 다음과 같은 구성 차이를 해결하세요.

  • 새 기본 클러스터의 파라미터를 현재 기본 클러스터와 일치하도록 구성합니다.

  • 모니터링 도구, 옵션 및 경보 구성   —   현재 기본 클러스터와 동일한 로깅 기능, 경보 등을 사용하여 새 기본 클러스터가 될 DB 클러스터를 구성합니다.

  • 다른 AWS 서비스와의 통합 구성 - Neptune 글로벌 데이터베이스가 AWS Identity and Access Management (IAM), Amazon S3 또는 와 같은 AWS 서비스와 통합되는 경우 새 기본 DB 클러스터와 통합하기 위해 필요에 따라 이러한 데이터베이스가 구성되었는지 AWS Lambda확인합니다.

장애 조치 프로세스가 완료되고 승격된 DB 클러스터가 글로벌 데이터베이스의 쓰기 작업을 처리할 준비가 되면 새 기본 클러스터에 새 엔드포인트를 사용하도록 애플리케이션을 변경해야 합니다.

AWS CLI 를 사용하여 계획된 관리형 장애 조치 시작

failover-global-cluster CLI 명령(FailoverGlobalCluster를 래핑함API)을 사용하여 Neptune 글로벌 데이터베이스를 장애 조치합니다.

aws neptune failover-global-cluster \
  --region (the region where the primary cluster is located) \
  --global-cluster-identifier (global database ID) \
  --target-db-cluster-identifier (the ARN of the secondary DB cluster to promote)
참고

failover-global-cluster API 는 미리 보기에서 사용할 수 없습니다. GA 릴리스의 일부가 될 예정입니다.