비즈니스 연속성 계획은 중단 시 애플리케이션의 가용성과 복구 가능성을 보장합니다. 계획은 다음을 결합해야 합니다.
고가용성(HA): 인프라에 장애가 발생하면 자동으로 자가 복구되는 아키텍처를 배포합니다.
재해 복구(DR): 자동 페일오버 도움이 되지 않을 때 수동으로 복구하는 절차를 설정합니다.
테스트: HA 및 DR 기능을 모두 정기적으로 검증합니다.
문서화: 명확한 절차와 복구 목표를 유지합니다.
참고
MongoDB Atlas 공동 책임 모델은 안전하고 복원력이 뛰어난 데이터 환경을 유지 관리하는 데 있어 MongoDB 와 MongoDB 고객의 보완 의무를 정의합니다. 이 프레임워크 에서 MongoDB 기본 플랫폼의 보안 및 운영 무결성을 관리하고 고객은 특정 배포의 구성, 관리 및 데이터 정책을 책임집니다. 보안 및 운영 우수성에 대한 소유권에 대한 자세한 분석은 공유 책임 모델을 참조하세요.
회복 탄력성 전략 선택
요구 사항에 따라 다음 프라이머리 접근 방식 중에서 선택합니다.
고가용성 - 자동 자가 복구
다운타임이 거의 없고 여러 가용영역(AZ), 리전 또는 클라우드 공급자에게 배포 할 수 있는 경우 HA를 선택합니다.
특성:
수동 개입이 필요 없는 자동 페일오버 .
RPO = 0 사용 시
majority쓰기 고려 (write concern).RTO = 초.
더 높은 인프라 비용.
사용 시기: 대부분의 프로덕션 배포, 특히 다음과 같은 경우에 적용됩니다.
여러 리전에 사용자가 있습니다.
애플리케이션 에 지속적인 가용성이 필요합니다.
가용영역이 3이상인 리전에 배포 할 수 있습니다.
자세한 내용은 Atlas 고가용성 지침 및 Atlas 배포서버 패러다임을 참조하세요.
재해 복구 - 수동 복구
다음과 같이 HA가 가능하지 않거나 비용 효율적이지 않은 경우 DR을 선택합니다.
리전이 2 개만 있는 캐나다와 같은 지리적 제약 조건입니다.
비용에 민감한 애플리케이션.
수동 복구 절차에 대한 허용 범위.
특성:
수동 개입이 필요합니다.
RPO > 0, 백업 빈도에 따라 다릅니다.
RTO = 분에서 시간으로
인프라 비용 낮추면 백업 저장 비용이 적용.
사용 시기:
지리적 또는 규제적 제약으로 인해 멀티 리전 배포서버 불가능합니다.
예산 제약으로 인해 비용 최적화가 필요합니다.
애플리케이션은 복구를 위해 계획된 다운타임을 허용할 수 있습니다.
자세히 알아보려면 Atlas 재해 복구 지침을 참조하세요.
HA와 DR 결합
대부분의 프로덕션 환경은 두 접근 방식을 결합하여 포괄적인 보호 기능을 제공하는 이점이 있습니다.
인프라 장애에 대한 HA: 자동 페일오버 노드, 구역, 리전 또는 제공자 중단으로부터 보호합니다.
데이터 무결성 문제에 대한 DR: 백업은 자동 페일오버 로 주소 수 없는 시나리오로부터 보호합니다.
HA를 사용하는 경우에도 DR의 이점을 누릴 수 있는 이유
고가용성 배포서버 사용하는 경우에도 다음과 같은 재해 복구 절차의 이점을 누릴 수 있습니다.
- 데이터 손상 또는 우발적인 삭제
- 고가용성은 모든 노드에서 손상된 데이터를 복제합니다. 손상 또는 삭제가 발생하기 전의 상태 로 복구하려면 백업에서 복원 해야 합니다.
- 애플리케이션 수준 장애
- 인프라가 아닌 데이터 무결성에 영향을 미치는 코드 오류 또는 악의적인 공격. 손상된 상태 전체 복제본 세트 에 복제되었습니다.
- 컴플라이언스 요구 사항
- 많은 규정에서 자동 페일오버 제공하는 것 이상의 특정 시점 복구 기능과 백업 보존 정책을 요구하고 있습니다.
이 계층화된 접근 방식은 가용성과 데이터 무결성을 모두 최적화하는 동시에 포괄적인 보호 기능을 제공합니다.
복구 목표 정의
아키텍처 및 백업 결정의 가이드 명확한 복구 목표를 설정하세요.
RPO( 복구 시점 목표 )
시간 단위로 측정한 데이터 손실의 허용 가능한 최대량입니다.
예시:
RPO = 0:
majority쓰기 고려 (write concern) 와 함께 HA를 사용합니다.RPO = 1 시간: 시간별 스냅샷을 구성합니다.
RPO = 1 일: 일일 스냅샷을 구성합니다.
RTO( 복구 시간 목표 )
중단 후 서비스를 복원 수 있는 최대 허용 시간입니다.
예시:
RTO = 초: 자동 페일오버 와 함께 HA를 사용합니다.
RTO = 1 시간: 백업 복원 절차가 <1 시간 내에 완료되는지 확인합니다.
RTO = 4 시간: 수동 복구 절차를 문서화하고 테스트합니다.
배포서버 패러다임과 백업 전략은 이러한 목표와 일치해야 합니다. Atlas 고가용성을 위한 지침 및 Atlas 재해 복구를 위한 지침 의 비교 표를 사용하여 옵션을 평가하세요.
정기적으로 계획 테스트
최소 반기별로 비즈니스 연속성 계획을 테스트합니다(분기별 권장). 테스트는 절차를 검증하고 팀 교육합니다.
고가용성 페일오버 테스트
자동화된 테스트:
Atlas UI의 Test Primary Failover (프라이머리 페일오버 테스트 ) 기능 사용하세요.
Use Test 페일오버 Atlas Administration API 엔드포인트를 사용합니다.
유효성 검사:
예상 RTO 내에 페일오버가 완료됩니다.
애플리케이션이 자동으로 다시 연결됩니다.
데이터 손실이 발생하지 않습니다(RPO = 0).
재해 복구 절차 테스트
수동 복구 테스트:
비프로덕션 환경에서 백업에서 복원을 연습합니다.
실제 복구 시간을 문서화하고 RTO와 비교합니다.
복원된 데이터 무결성을 확인합니다.
멀티 리전 스냅샷 배포를 사용하는 경우 리전 간 복원을 테스트합니다.
유효성 검사:
팀이 문서화된 절차를 올바르게 따릅니다.
예상 RTO 내에 복구가 완료됩니다.
데이터 손실은 예상 RPO에 따릅니다.
모든 종속성(네트워크, 자격 증명)이 올바르게 작동합니다.
일부 테스트에서는 표준 사용자가 수행할 수 없는 조치가 필요할 수 있습니다. 인공 장애 또는 기타 제한된 테스트 시나리오를 예정 하려면 최소 일주일 전에 지원 사례를 열어야 합니다.
계획 문서화
비즈니스 연속성 계획에 대한 명확한 문서를 유지합니다.
필수 문서
복구 목표:
각 애플리케이션 계층 에 대한 문서화된 RPO 및 RTO.
선택한 배포서버 패러다임에 대한 근거입니다.
백업 빈도 및 보존 결정.
아키텍처 문서:
배포 토폴로지 (리전, 구역, 클라우드 공급자).
네트워크 아키텍처 및 페일오버 동작.
애플리케이션 배포서버 토폴로지.
타사 서비스 종속성.
복구 절차:
단계별 복원 절차.
대기 중인 팀 의 연락처 정보입니다.
다양한 시나리오 유형에 대한 에스컬레이션 경로.
모니터링 대시보드 및 경고에 대한 링크입니다.
테스트 결과:
과거 테스트 실행 날짜 및 결과.
식별된 문제와 해결 상태.
테스트 학습을 기반으로 절차를 변경합니다.
각 테스트 실습 또는 인프라 변경 후 검토하고 업데이트하여 문서를 최신 상태로 유지하세요.
일반적인 시나리오 및 대응 계획
일반적인 중단 시나리오에 대한 대응 계획을 준비합니다. 자세한 절차는 Atlas 재해 복구를 위한 지침의 시나리오별 섹션을 참조하세요.
인프라 장애(HA 시나리오)
단일 노드 장애:
HA 배포: 자동 페일오버, 조치 필요하지 않습니다.
성공적인 페일오버 및 노드 복원을 모니터링합니다.
가용영역 장애:
다중 AZ 배포: 자동 페일오버, 조치 필요하지 않습니다.
애플리케이션 트래픽을 계속 제공하는지 확인합니다.
리전 장애:
멀티 리전 배포: 다른 리전 으로 자동 페일오버 .
애플리케이션 이 멀티 리전에도 배포되도록 합니다.
타사 서비스에 계속 액세스할 수 있는지 확인합니다.
클라우드 공급자 장애:
멀티 클라우드 배포: 다른 제공자 로 자동 페일오버 .
단일 클라우드 배포: DR 절차를 실행합니다.
데이터 무결성 문제(DR 시나리오)
데이터 손상:
손상 타임스탬프를 식별합니다.
손상이 발생하기 전에 백업 에서 복원합니다.
연속 백업 의 경우: 특정 시점 복원 사용합니다.
실수로 삭제:
삭제 타임스탬프를 식별합니다.
삭제하기 전에 백업 에서 복원합니다.
복원된 데이터 무결성을 확인합니다.
전체 배포서버 손실:
문서화된 DR 절차를 실행합니다.
가장 최근 백업 에서 복원합니다.
애플리케이션 기능을 검증합니다.
컨트롤 플레인 장애:
매우 드문 경우입니다. Atlas 높은 안정성을 유지합니다.
플랫폼 안정성을 참조하세요.
즉시 MongoDB 지원 에 문의하세요.
각 시나리오에 대한 자세한 복구 절차는 Atlas 재해 복구 지침을 참조하세요.