멀티 리전 Atlas 배포는 둘 이상의 리전 에 걸쳐 설정하다 클러스터입니다. 다중 리전 배포서버 동일한 지역(대륙 또는 국가와 같은 넓은 지역) 내에 여러 리전이 있거나 여러 지역에 여러 리전이 있을 수 있습니다. 멀티 리전 배포:
지속적인 가용성과 원활한 사용자 환경을 위해 트래픽을 다른 리전 으로 자동 라우팅하여 리전 중단 시 보호 기능을 강화하세요.
데이터를 사용자에게 더 가깝게 배치하여 일부 애플리케이션의 성능과 가용성을 개선합니다.
멀티 리전 배포서버 귀하에게 적합한지 고려할 때는 애플리케이션 의 중요도와 이것이 다양한 RTO/RPO 요구 사항과 어떻게 일치하는지 평가해야 합니다. 복원력은 멀티 리전 배포서버 의 다운타임이 없는 것부터 단일 리전 배포서버 의 다양한 백업 일정까지 다양합니다. 더 많은 가용성을 위해 비용 인상하는 절충안입니다.
멀티 리전 배포서버 워크로드 에 적합한지 여부에 대한 자세한 지침 은 안정성 섹션을 참조하세요.
참고
멀티 리전 배포는 M10 전용 클러스터 이상에서만 사용할 수 있습니다.
멀티 리전 배포 전략
다음 다이어그램은 2+2+1 토폴로지 의 2 예를 보여 주며, 이에 대해서는 아래에서 자세히 설명합니다. 이는 3 개의 서로 다른 리전에 5 개의 노드가 있는 단일 클러스터 보여줍니다: US1의 2 노드, US2의 2, US3의 1.
5-노드, 3-리전 아키텍처(2+2+1)
리전 중단 시 거의 즉각적인 복구를 달성하려면 3 리전에 분산된 최소 5 노드로 구성된 아키텍처를 권장합니다. 이 아키텍처는 두 번째 리전 으로 페일오버 하지 않고도 정기적인 유지 관리 작업을 수행할 수 있도록 하는 동시에 전체 리전 중단 사고에서 자동화된 페일오버 및 데이터 손실 보호를 보장합니다.
다음 다이어그램은 이 아키텍처의 세부 정보를 보여줍니다.
참고 및 고려 사항
비공개 엔드포인트 사용하여 클러스터 에 연결하고 애플리케이션 서버 VPC 간의 VPC 피어링을 사용합니다. VPC 피어링을 사용하면 네트워크 연결이 끊어지거나 해당 리전 의 Atlas 다운되더라도 애플리케이션 계층 여전히 프라이머리 노드 로 라우팅할 수 있으며, 먼저 VPC 피어링을 통해, 그 다음에는 비공개 엔드포인트를 통해 라우팅할 수 있습니다.
이 아키텍처는 리전 간 네트워크 트래픽과 5 이상의 데이터 보유 노드로 인해 비용 가장 높습니다.
이 아키텍처는 최고의 복원력을 제공합니다. Atlas 작업 중에는 (예: 자동 업그레이드) 중단이 없으며, 중단이나 수동 개입 없이 애플리케이션 완전한 리전 장애를 견딜 수 있습니다.
이 아키텍처는 리전 간 네트워크 트래픽과 5 이상의 데이터 보유 노드로 인해 비용 가장 높습니다.
5-노드, 2-리전 아키텍처(2+3)
회사 2 리전으로만 제한되어 있는 경우, 두 리전에 분산된 5 노드가 있는 5-노드, 3-리전 아키텍처의 변형을 사용할 수 있습니다. 프라이머리 리전 2 개의 투표 선택 가능 노드가 있고, 세컨더리 리전 1 개의 투표 선택 가능 노드 와 2 개의 읽기 전용(투표하지 않음) 노드가 있습니다.
3 리전을 사용할 수 있는 경우 일반적으로 권장되지 않습니다. 그러나 승인된 리전이 2 개만 있는 고객에게는 좋은 옵션입니다.
참고 및 고려 사항
이 아키텍처는 데이터 손실에 대한 향상된 보호 기능을 제공합니다. 소수 리전 손실되더라도 다수 리전 클러스터 완전히 작동하도록 유지되므로 사용자가 조치 취할 필요가 없습니다. 과반수 리전 손실되더라도 대다수의 노드가 투표 선택 가능 상태 될 때까지 시스템은 읽기 전용 모드 로 계속 사용 가능합니다. 그러나 장애 후 일부 데이터가 세컨더리 노드 에 아직 복제되지 않은 경우에는 완전한 데이터 손실 보호를 제공하지 않을 수 있습니다. 이 경우 프라이머리 리전 복구될 때까지 해당 데이터를 사용할 수 없습니다.
이 아키텍처에는 몇 가지 주의 사항이 있습니다.
다수 리전 손실되면 소수 리전 클러스터 제대로 작동하지 않습니다. 즉, 프라이머리 없으며 읽기만 허용하고 쓰기는 허용할 수 없습니다.
투표 노드의 과반수가 없기 때문에 프라이머리 가 없으며 읽기(쓰기 제외)만 허용할 수 있습니다.
기능 클러스터 복원 하려면 관리자가 2 읽기 전용 노드를 투표 선택 가능 노드로 재구성해야 합니다. 그러나 데이터가 손실될 수 있습니다. 운영 중단 중에 세컨더리에 대한 모든 새 쓰기는 수동 복구를 위해 특수 컬렉션 에 배치됩니다. 그러나 프라이머리 다운되기 전에 하나 이상의 세컨더리 노드 에 복제되지 않은 프라이머리 에 대한 모든 쓰기는 손실됩니다.자세한 학습 은 리전 운영 중단 중 복제본 세트 재구성을 참조하거나 acceptDataRisksAndForceReplicaSetReconfig API 매개변수를 사용하세요.
샤딩된 클러스터에서 MongoDB 프로세스 청크 마이그레이션을 복제하지 않은 경우 데이터 불일치로 인해 고아 문서가 발생할 수 있습니다.
저렴한 변형
추가 비용 절감을 위해 2 읽기 전용 노드 없이 이 아키텍처를 설계할 수 있습니다. 위에 나열된 주의 사항 외에도 클러스터 에 새 노드를 추가할 때마다 데이터를 세컨더리 노드에 동기화해야 하므로 데이터 크기는 결정에 중요한 영향 미칩니다. 예시 를 들어, 1 TB의 데이터는 평균 1 시간의 복구 및 동기화 시간입니다. 소수 리전 리전에 2 읽기 전용 노드를 두는 것이 좋습니다. 이는 이미 완전히 동기화되어 있고, 완전히 작동하는 클러스터 로 복구하는 데 몇 초에서 몇 분 밖에 걸리지 않기 때문입니다.
3-노드, 3-리전 아키텍처(1+1+1)
가용성이나 지연 시간 보다 배포서버 비용 더 중요한 요인인 경우 각 3 리전에서 1 노드 사용하여 저렴한 아키텍처를 만들 수 있습니다. 각 리전에 투표 선택 가능 노드 있으므로 프라이머리 노드 사용할 수 없는 경우 클러스터 새 리전 으로 페일오버되어 지속적인 가용성을 보장합니다. 그러나 원래 프라이머리 리전 의 앱 계층 여전히 사용자 요청을 처리하는 경우 요청이 여러 리전으로 라우팅되므로 지연 시간 증가합니다.
참고
Atlas 노드를 정기적으로 계획적으로 유지 관리하면 일시적인 지연 시간 급증이 발생할 수 있으므로 일반적으로 이 구성을 권장하지 않습니다.
멀티 리전 배포를 위한 권장 사항
멀티 리전 배포를 구성하는 방법과 추가할 수 있는 다양한 노드 유형에 대해 학습 학습 Atlas 설명서에서 고가용성 및 워크로드 격리 구성을 참조하세요.
Atlas cloud 배포에 대한 권장 사항을 찾으려면 다음 리소스를 참조하세요.