멀티 리전 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-노드, 3-리전 아키텍처의 변형으로 2개 리전에 5개 노드를 분산시킬 수 있습니다. 기본 리전에는 투표 가능한 노드가 2개, 보조 리전에는 투표 가능한 노드 1개와 읽기 전용(비투표) 노드 2개가 배치됩니다.
3 리전을 사용할 수 있는 경우 대부분의 리전 장애가 발생할 경우 페일오버 위해 연산자 수동으로 개입해야 하므로 일반적으로 이 방법을 권장하지 않습니다. 그러나 승인된 리전이 2 개만 있는 고객을 위한 옵션입니다.
참고 및 고려 사항
이 아키텍처는 데이터 손실에 대한 보호 수준을 높여줍니다. 소수 리전에 장애가 발생해도 과반수의 리전이 정상적으로 클러스터를 유지하므로 사용자가 조치를 취할 필요가 없습니다. 다수의 리전에 장애가 발생하더라도 과반수 노드가 선출 가능한 상태로 전환될 때까지 시스템은 읽기 전용 모드로 동작합니다. 단, 장애 발생 후 일부 데이터가 세컨더리 노드로 아직 복제되지 않았다면 완전한 데이터 손실 보호는 어렵습니다. 이 경우 해당 데이터는 기본 리전이 복구될 때까지 사용할 수 없습니다.
이 아키텍처에는 다음과 같은 몇 가지 주의점이 있습니다.
다수 리전 손실되면 소수 리전 클러스터 제대로 작동하지 않습니다. 즉, 프라이머리 없으며 읽기만 허용하고 쓰기는 허용할 수 없습니다.
투표 노드의 과반수가 없기 때문에 프라이머리 가 없으며 읽기(쓰기 제외)만 허용할 수 있습니다.
기능 클러스터를 복원하려면 관리자가 2개의 읽기 전용 노드를 투표 가능한 노드로 재구성해야 합니다. 그러나 이 과정에서 데이터 손실이 발생할 수 있습니다. 장애 기간 동안 세컨더리로의 새로운 쓰기 작업은 수동 복구를 위한 특별한 컬렉션에 저장됩니다. 그러나 프라이머리 노드가 다운되기 전에 최소한 하나의 세컨더리 노드에 복제되지 않은 프라이머리 쓰기는 소실됩니다. 자세한 내용은 리전 장애 시 복제본 세트 재구성을 참고하거나 acceptDataRisksAndForceReplicaSetReconfig API 매개 변수를 사용하세요.
샤딩된 클러스터에서 MongoDB 프로세스가 청크 마이그레이션을 복제하지 못하면 데이터 불일치로 인해 고아 문서가 발생할 수 있습니다.
저렴한 변형
추가 비용 절감을 위해 2 읽기 전용 노드 없이 이 아키텍처를 설계할 수 있습니다. 위에 나열된 주의 사항 외에도 클러스터 에 새 노드를 추가할 때마다 데이터를 세컨더리 노드에 동기화해야 하므로 데이터 크기는 결정에 중요한 영향 미칩니다. 예시 를 들어, 1 TB의 데이터는 평균 1 시간의 복구 및 동기화 시간입니다. 소수 리전 리전에 2 읽기 전용 노드를 두는 것이 좋습니다. 이는 이미 완전히 동기화되어 있고, 완전히 작동하는 클러스터 로 복구하는 데 몇 초에서 몇 분 밖에 걸리지 않기 때문입니다.
3-노드, 3-리전 아키텍처(1+1+1)
중단을 허용할 수 있는 덜 중요도가 높은 워크로드의 경우 각 3 리전에서 1 노드 사용하여 저렴한 아키텍처를 활용할 수 있습니다. 각 리전에 투표 선택 가능 노드 있으므로 프라이머리 노드 사용할 수 없는 경우 클러스터 새 리전 으로 페일오버되어 지속적인 가용성을 보장합니다. 그러나 원래 프라이머리 리전 의 앱 계층 여전히 사용자 요청을 처리하는 경우 요청이 여러 리전으로 라우팅되므로 지연 시간 증가합니다. 또한 노드 재구축하는 경우 최적화된 초기 동기화 수행할 기능 없습니다.
참고
Atlas 노드를 정기적으로 계획적으로 유지 관리하면 일시적인 지연 시간 급증이 발생할 수 있으므로 일반적으로 이 구성을 권장하지 않습니다.
멀티 리전 배포의 권장 사항
멀티 리전 배포를 구성하는 방법과 추가할 수 있는 다양한 노드 유형을 확인하려면 Atlas 문서의 고가용성 및 워크로드 격리 구성을 참조하세요.
Atlas 클라우드 배포에 대한 권장 사항은 다음 리소스를 참고하세요.