엔터프라이즈 재해 복구를 계획하는 것은 매우 중요합니다. 다음과 같은 요소를 포함하는 포괄적인 재해 복구(DR) 계획을 준비하는 것이 좋습니다.
지정된 복구 점 목표(RPO)
지정된 RTO(복구 시간 목표)
이러한 목표에 부합하는 자동화된 프로세스
이 페이지의 권장 사항을 활용하여 재난에 대비하고 대응하세요.
재해 복구에 도움이 되는 사전 예방적 고가용성 구성에 대한 자세한 내용은 Atlas 고가용성을 위한 권장사항을 참조하세요.
Atlas 재해 복구 기능
재해 복구를 지원하는 Atlas 기능에 대해 알아보려면 Atlas 아키텍처 센터의 다음 페이지를 참조하세요.
Atlas 재해 복구 권장 사항
다음 재해 복구 권장 사항을 사용하여 조직을 위한 DR 계획을 수립하세요. 이 권장 사항은 재해 발생 시 취해야 할 단계에 대한 정보를 제공합니다.
이 섹션의 계획은 반드시 정기적으로(분기마다, 적어도 반년마다) 테스트해야 합니다. 테스트는 종종 EDM(엔터프라이즈 데이터베이스 관리) 팀 재해에 대응할 수 있도록 준비하는 동시에 지침을 최신 상태로 유지하는 데 도움이 됩니다.
일부 재해 복구 테스트에는 EDM 사용자가 수행할 수 없는 조치가 필요할 수 있습니다. 이러한 경우 테스트 작업을 실행 계획보다 최소 일주일 전에 인공 중단을 수행할 목적으로 지원 사례를 엽니다.
다음 다이어그램은 RTO 및 RPO의 상대적 이점, 각 옵션을 배포하고 다양한 재해 시나리오를 해결하는 데 드는 상대적 비용 및 복잡성을 포함하여 사용 가능한 재해 복구 구성 옵션에 대한 개요를 제공합니다.
Atlas 클러스터를 배포할 수 있는 각 클라우드 공급자는 장애를 완화하는 데 도움이 되는 기본 데이터 중복성을 제공합니다.
AWS는 AWS 리전에서 최소 3개의 가용영역에 걸쳐 여러 기기에 객체를 저장합니다.
Microsoft Azure는 선택한 리전의 단일 데이터 센터 내에서 데이터를 세 번 복제하는 로컬 중복 저장(LRS)을 사용합니다.
Google Cloud는 백업 리전의 여러 영역에 데이터를 분산합니다.
재해 복구를 강화하려면 다른 리전에 스냅샷과 oplog의 사본을 자동으로 생성하도록 Atlas를 설정할 수 있습니다. 이렇게 하면 프라이머리 리전에 장애가 발생해도 다른 리전에 저장된 스냅샷 복사본을 사용하여 클러스터를 복원할 수 있습니다. Atlas 리전 가용성에 따라 가장 효율적인 옵션을 선택하고, 복사본이 있는 리전으로 복원할 경우 복사된 스냅샷을 활용해 복원 속도를 최적화합니다. 또한 지역 장애로 인해 원본 스냅샷에 접근할 수 없는 경우, Atlas는 가장 가까운 사용 가능한 스냅샷 복사본을 사용해 복원함으로써 가동 중단 시간을 최소화하고 회복 탄력성을 향상합니다. 자세한 내용은 스냅샷을 다른 리전으로 자동 복사하도록 Atlas 구성하기를 참조하세요.
멀티 리전 또는 멀티 클라우드 MongoDB 클러스터를 실행하는 경우에는 백업 전략을 구성할 때 데이터 손상 위험을 완화하기 위한 특정 요구 사항을 고려해야 합니다. 시스템 내의 잠재적인 데이터 손상 문제를 얼마나 빨리 식별할 수 있는지 평가합니다. 이 탐지 기간을 설정한 후에는 백업 보존을 적절히 구성하고, 손상이 발생하기 전의 스냅샷이 복원 가능한지 확인합니다. 문제를 감지하는 데 지연이나 불확실성이 발생할 수 있으므로 일반적으로 백업 보존 예정 기간에 10~15% 정도의 추가 버퍼를 포함하는 것이 좋습니다. 이 버퍼는 중요한 정보의 손실 없이 깨끗한 데이터를 안정적으로 복구할 수 있도록 지원하여 배포서버의 전반적인 회복 탄력성과 안정성을 향상합니다.
모든 배포서버 패러다임 권장사항
다음 권장사항은 모든 배포서버 패러다임에 적용됩니다.
이 섹션에서는 다음과 같은 재해 복구 절차에 대해 설명합니다.
단일 노드 중단
부분적인 지역 장애로 인해 복제본 세트의 단일 노드가 실패하더라도 권장사항을 따랐다면 배포서버를 계속해서 사용할 수 있습니다. 세컨더리 노드에서 읽는 경우 프로비저닝되지 않은 클러스터의 부하 증가로 인해 세컨더리 노드에 장애가 발생할 경우 성능이 저하되거나 중단될 가능성이 있습니다.
Atlas UI의 프라이머리 페일오버 테스트 기능 또는 페일오버 테스트 Atlas 관리 API 엔드포인트를 사용하여 Atlas 에서 프라이머리 노드 중단을 테스트할 수 있습니다.
리전 중단
리전 장애가 발생하면 멀티 리전 클러스터는 자동으로 투표를 실시하고, 필요한 경우 새로운 프라이머리 노드를 식별합니다. 이 토폴로지 변경 사항이 애플리케이션에 자동으로 전달되어 필요한 수정 조치를 취할 수 있습니다. 지역 장애 발생 시 애플리케이션 가동 시간을 유지하려면 애플리케이션 자체도 멀티 리전 토폴로지를 사용하여 배포해야 합니다. 애플리케이션이 통합될 수 있는 모든 타사 서비스에도 이 요구 사항이 적용됩니다. 자세한 내용은 멀티 리전 배포서버 패러다임을 참조하세요.
단일 리전 중단 또는 다중 리전 중단으로 인해 클러스터 상태 저하되는 경우 다음 단계를 따르세요.
식별한 지역에 노드 추가
중단 원인의 영향을 받을 가능성이 낮은 리전 전체에 걸쳐 정상 상태 에 필요한 노드 수를 추가합니다.
운영 중단 시 지역 또는 노드를 추가하여 복제본 세트를 재구성하려면 지역 장애 시 복제본 세트 재구성을 참조하세요.
Atlas UI의 중단 시뮬레이션 기능 또는 중단 시뮬레이션 시작하기 Atlas 관리 API 엔드포인트를 사용하여 Atlas 에서 리전 중단을 테스트할 수 있습니다.
클라우드 공급자 장애
멀티 클라우드 클러스터를 사용하면 클라우드 공급자 간에 투표 선택 가능 노드를 선택해 고가용성을 유지할 수 있습니다. 프라이머리 노드가 배포된 공급자를 사용할 수 없게 되는 경우, 투표 선택 가능 노드를 프라이머리 노드로 전환해 작업을 계속할 수 있습니다. 예를 들어 AWS, Google Cloud 및 Microsoft Azure에서 투표 선택 가능 노드를 생성하면, 어느 클라우드 공급자에게 장애가 발생해도 다른 공급자에서 투표 선택 가능 노드를 클러스터의 프라이머리 노드로 사용할 수 있습니다. 자세한 내용은 멀티 클라우드 배포서버 패러다임을 참조하세요.
대부분의 멀티 리전 Atlas 클러스터는 단일 리전 장애에서 자동으로 복구됩니다. 자세한 내용은 고가용성 섹션 및 멀티 리전 배포서버 페이지를 참조하세요. 지역 장애로 인해 과반수의 노드가 중단된 경우, 노드를 몇 개 더 추가해야 과반수의 노드를 정상 상태로 유지할 수 있는지 결정해야 합니다.
모든 클라우드 공급자가 사용 불가능인 경우 배포를 다시 온라인 상태로 전환하려면 다음 단계를 따릅니다.
새 클러스터 배포 하려는 대체 cloud 제공자 식별합니다.
cloud 제공자 목록 및 정보는 클라우드 제공자를 참조하세요.
백업을 여러 클라우드 공급자에 저장하면 클라우드 공급자에 장애가 발생하면 프라이머리 클라우드 공급자에 저장된 백업을 사용할 수 없게 되므로, 장애가 시작되기 전에 클러스터에서 캡처한 사용 가능한 최신 스냅샷을 찾습니다.
백업 스냅샷을 보는 방법을 알아보려면 M10+ 백업 스냅샷 보기를 참조하세요.
이전 클러스터 에 연결하는 모든 애플리케이션을 새로 생성된 클러스터 로 전환합니다.
새로운 연결 문자열을 찾으려면 드라이버를 통한 연결을 참조하세요. 새 클라우드 공급자에 재배포해야 할 가능성이 있으므로 애플리케이션 스택을 검토합니다.
Atlas 중단
Atlas Control Plane과 Atlas UI가 매우 드물게 사용 불가능한 상황에서도 클러스터는 여전히 사용 가능하며 접근할 수 있습니다. 자세한 내용은 플랫폼 Reliability를 참조하세요. 우선순위가 높은 지원 티켓을 열어 추가 조사를 진행하세요.
리소스 용량 문제
디스크 공간, RAM 또는 CPU와 같은 컴퓨팅 리소스 용량 문제는 부실한 계획 또는 예기치 않은 데이터베이스 트래픽으로 인해 발생할 수 있습니다. 이러한 동작은 재해의 결과가 아닐 수 있습니다.
컴퓨팅 리소스가 최대 할당량에 도달하여 재해를 초래할 경우 다음 단계를 따릅니다.
실시간 성능 패널 또는 Atlas 지표 사용하여 최대로 활용되는 계산 리소스 식별합니다.
Atlas UI 에서 리소스 사용률을 보려면 실시간 성능 모니터링을 참조하세요.
Atlas 관리 API 사용하여 지표 보려면 모니터링 및 로그를 참조하세요.
필요한 리소스 할당
Atlas 이 변경을 순차적으로 수행하므로 애플리케이션에 큰 영향 미치지 않습니다.
더 많은 리소스를 할당하는 방법을 학습 클러스터 편집을 참조하세요.
리소스 장애
중요
이는 전체 시스템 다운타임을 줄이기 위한 임시 솔루션입니다. 기본 문제가 해결되면 새로 생성된 클러스터 의 데이터를 원래 클러스터 에 병합하고 모든 애플리케이션이 원래 클러스터 를 가리키 점 .
컴퓨팅 리소스가 실패하여 클러스터를 사용할 수 없게 되면 다음 단계를 따릅니다.
프로덕션 데이터 삭제
프로덕션 데이터는 인적 오류나 데이터베이스 위에 구축된 애플리케이션의 버그로 인해 실수로 삭제될 수 있습니다. 클러스터 자체가 실수로 삭제된 경우 Atlas는 볼륨을 일시적으로 보관할 수 있습니다.
컬렉션이나 데이터베이스의 내용이 삭제된 경우 다음 단계에 따라 데이터를 복원합니다.
컬렉션 또는 데이터베이스 에 데이터가 포함된 경우 현재 상태 의 복사본을 만듭니다.
mongoexport 를 사용하여 사본을 만들 수 있습니다.
데이터 사본을 만든 경우 내보낸 새 데이터를 가져옵니다.
mongoimport를 업서트 모드로 사용하여 데이터를 가져오고 수정 및 추가된 데이터가 컬렉션이나 데이터베이스에 올바르게 반영되도록 할 수 있습니다.
드라이버 장애
드라이버가 실패하면 다음 단계를 따르세요.
데이터 손상
중요
이는 전체 시스템 다운타임을 줄이기 위한 임시 솔루션입니다. 기본 문제가 해결되면 새로 생성된 클러스터 의 데이터를 원래 클러스터 에 병합하고 모든 애플리케이션이 원래 클러스터 를 가리키 점 .
기본 데이터가 손상되면 다음 단계를 따르세요.