프로덕션 정보

개요

데이터 플랫폼으로 MongoDB Atlas를 사용하면 데이터베이스 인프라를 구축하고 유지 관리하는 데 필요한 일상적인 운영 작업과 워크플로우에서 벗어나 엔지니어가 비즈니스에 가치를 더할 수 있도록 지원하는 데 집중할 수 있습니다. 엔지니어는 하드웨어를 유지 관리하고 운영 체제 수준의 소프트웨어 패치를 따라잡는 대신 기업의 현재와 미래의 요구 사항을 충족하는 데이터 모델을 개발하는 데 시간과 에너지를 쏟을 수 있습니다.

이 문서에서는 MongoDB Atlas 클러스터를 사용하여 성공적인 MongoDB 프로덕션 배포서버를 설정하고 유지 관리하기 위한 몇 가지 권장사항을 간략하게 설명합니다.

역할 및 책임

MongoDB는 고객에게 MongoDB 데이터베이스 서비스를 제공하기 위해 필요한 인프라를 관리하고 운영합니다. MongoDB의 책임은 다음과 같습니다.

• 데이터베이스 클러스터와 기본 인프라를 관리하여 크기가 M10 이상인 클러스터에 대해 99.995% 가동 시간 서비스 수준 계약 (SLA) 으로 뒷받침되는 MongoDB의 가용성, 안정성 및 성능을 보장합니다.

• 기본 컴퓨팅 노드의 상태를 확인합니다. 실행 중이고, 네트워크에 연결되어 있으며, 작동 시간 SLA를 유지하기 위해 권장되는 모든 OS 수준 패치가 있는지 확인합니다.

• Atlas 사용자 인터페이스 또는 REST API를 통해 고객이 선택한 특정 설계를 기반으로 MongoDB 데이터베이스 구성을 관리합니다.

• 제품에 대한 최신 버그 수정이 사용되도록 모든 MongoDB 유지 관리 업그레이드를 자동으로 적용합니다.

• 역할 기반 액세스 제어, IP 액세스 목록에 IP 주소 추가, 피어링을 포함한 보안 프로필을 관리하여 고객의 지시에 따라 클러스터 보안을 극대화할 수 있습니다.

• 백업 및 복원 서비스를 제공합니다.

고객은 기본 데이터베이스 리소스 및 인프라를 직접 관리할 필요 없이 MongoDB에 액세스하는 애플리케이션을 계속 개발하고 배포합니다.

클러스터 관리

MongoDB Atlas 는 데이터베이스 작업을 추상화하여 사용자가 높은 수준의 가치 있는 관리 의사 결정에 집중할 수 있도록 합니다. Atlas user Role 을 사용하여 cluster에 액세스 를 관리 할 수 Atlas 있습니다. 이러한 권한 은 조직 수준 또는 프로젝트 수준 에서만 적용 할 수 있습니다. 따라서 조직과 프로젝트의 계층 구조를 신중하게 계획해야 합니다.

Atlas 내에서 잘 설계된 조직 및 프로젝트 계층 구조를 만들려면 클러스터를 사용 사례에 적합한 프로젝트로 나누세요. 이를 통해 운영상의 마찰을 최소화하면서 엔터프라이즈 의 효율성 을 극대화할 수 있습니다.

단일 리전 및 멀티 리전 클러스터

고가용성과 클러스터 내구성은 클러스터의 지리적 배포 구성에 따라 달라집니다. 단일 리전 내에 배포된 클러스터는 해당 리전 내의 가용영역에 분산되어 있으므로 읽기 또는 쓰기 가용성의 중단 없이 부분적인 리전 장애를 견딜 수 있습니다.

선택적으로 클러스터를 두 개 이상의 리전에 분산하여 복원력과 워크로드 격리를 강화할 수 있습니다.

리전 순서에 따라 프라이머리 노드 위치의 우선순위가 결정됩니다. 따라서 특정 리전을 사용할 수 있을 때 데이터베이스 쓰기 작업을 특정 리전으로 지정하려면 먼저 해당 리전을 나열해야 합니다. 목록의 두 번째 리전은 첫 번째 리전을 사용할 수 없는 경우 쓰기가 이동해야 하는 위치에 대한 두 번째 선택이어야 합니다.

Atlass 클러스터 만들기 UI의 다음 예는 세 개의 서로 다른 리전에서 선택 가능한 노드가 있는 멀티 리전 클러스터를 우선순위가 가장 높은 것부터 낮은 것까지 정렬하여 보여줍니다.

클릭하여 확대

us-east-1 리전을 사용할 수 없게 되면 us-west-1 리전에서 새로운 프라이머리 리전이 결정됩니다.

참고

기본 선택 가능성을 보장하려면 클러스터에 홀수 개의 노드가 있어야 합니다. 자세한 내용은 복제본 세트 투표(Replica Set Elections)를 참조하세요.

두 리전에 배포

두 리전에 클러스터를 배포하면 데이터 사본이 항상 둘 이상의 리전에서 유지 관리됩니다. 그러나 클러스터의 노드 대부분을 포함하는 리전이 손실되면 관리자가 개입하거나 원래 리전을 사용할 수 있게 될 때까지 두 번째 리전은 읽기 전용 상태로 남게 됩니다.

3개 이상의 리전에 배포

클러스터를 3개 이상의 리전에 배포하면 애플리케이션 계층에 내결함성이 있는 경우 클러스터가 전체 리전 수준의 장애를 견디면서 읽기 및 쓰기 가용성을 유지할 수 있습니다.

선호하는 리전에서 쓰기 작업을 항상 유지하는 것이 최우선 순위인 경우, 선호하는 리전 내 최소 두 곳의 데이터 센터에 최소 두 개의 투표 선택 가능 구성원이 있도록 클러스터를 배포하는 것이 좋습니다.

글로벌 클러스터

전 세계 배포서버에서 최상의 데이터베이스 성능을 위해, 사용자는 위치 인식 샤딩을 사용하여 읽기 및 쓰기 지연 시간을 최소화하는 글로벌 클러스터를 구성할 수 있습니다. 지리적 저장 요구 사항이 있는 사용자는 데이터가 특정 지리적 영역에 저장되도록 할 수도 있습니다.

애플리케이션 관리

애플리케이션 수준의 책임은 다음과 같습니다.

• 쿼리 및 인덱스 최적화를 포함한 스키마 디자인.

• 클러스터 계층 및 토폴로지 선택. 최적의 데이터베이스 성능을 위해서는 적절한 클러스터 크기와 토폴로지(복제본 세트 또는 샤딩된 클러스터), 스토리지 용량 및 IOPS를 선택하는 것이 중요합니다.

• 비프로덕션 클러스터의 프로비저닝입니다. 프로덕션 백업은 Atlas UI 또는 API를 사용하여 비프로덕션 클러스터로 복원할 수 있습니다.

• 용량 계획입니다. 일반적으로 Atlas에서 제공하는 모니터링 원격 측정을 사용하여 추가 컴퓨팅 용량이 필요한 시기를 결정합니다. 애플리케이션 다운타임 없이 용량을 추가할 수 있으며, 필요에 따라 자동 확장을 활성화하여 사용량 급증에 자동으로 대응할 수 있습니다.

• 주요 데이터베이스 버전 업그레이드를 구현할 시기를 결정합니다.

• 백업 및 복원 계획을 구현하고 테스트합니다.

• 테스트를 통해 애플리케이션이 클러스터 장애 조치를 원활하게 처리하는지 확인합니다.

• BI Connector 및 차트와 같은 도구를 사용하여 데이터 분석 서비스를 구성합니다 .

다중 테넌시

Atlas로 멀티 테넌시를 구현하여 애플리케이션의 단일 인스턴스가 여러 테넌트를 지원하도록 할 수 있습니다. 다중 테넌트 아키텍처에 대한 초기 디자인 결정은 시간이 지남에 따라 요구 사항이 발전하거나 확장 기대치가 변경됨에 따라 의도하지 않은 영향을 미칠 수 있습니다. 자세한 내용은 멀티테넌트 아키텍처 구축을 참조하십시오.

아카이브 데이터 오프로드 및 쿼리

데이터 수명 주기의 일부로 콜드 데이터를 다른 스토리지 계층으로 이동해야 하는 경우, 날짜 또는 사용자 지정 기준에 따라 데이터를 이동하도록 Atlas 온라인 아카이브 규칙을 설정할 수 있습니다. Atlas에 데이터가 보관되면 읽기 전용 연합 데이터베이스 인스턴스를 통해 Atlas 및 온라인 아카이브 데이터를 합쳐진 형태로 볼 수 있습니다.

연합 데이터 쿼리

Atlas Data Federation을 사용하여 다양한 인프라에 걸쳐 제자리에서 데이터를 쿼리하거나 다양한 시스템 간에 데이터를 이동할 수 있습니다. 여러 소스의 데이터에 집계 파이프라인을 사용하여 데이터에서 인사이트를 추출하거나 다른 용도로 데이터를 변환할 수 있습니다. 예를 들어, $out을 S3에, $out을 Atlas에 사용하여 스토리지 계층 간에 데이터를 이동할 수 있습니다. 또한 $out을 S3에 사용하여 Atlas 클러스터의 데이터를 JSON, BSON, CSV, TSV, Avro, Parquet, ORC로 쉽게 변환할 수 있을 뿐만 아니라 AWS S3에 저장하여 액세스가 필요한 다운스트림 시스템에 공급할 수 있습니다.

임시 데이터베이스 사용자 감사

애플리케이션 서비스 사용자를 포함한 모든 데이터베이스 사용자에 대해 감사를 사용하도록 설정하면 클러스터 성능에 심각한 영향을 미칠 수 있습니다. 임시 데이터베이스 사용자의 작업을 감사해야 하는 경우 감사 대상 사용자 지정 역할을 만들고, 상승된 권한을 가진 임시 사용자를 만든 다음, 이 사용자에게 사용자 지정 역할을 부여하여 해당 사용자의 작업을 감사할 수 있습니다.

임시 데이터베이스 사용자의 조치를 감사하려면 다음을 수행합니다.

선택적 모니터링 & 로깅 통합

DataDog를 사용하여 Atlas 에 대한 푸시 기반 모니터링 통합 을 구성할 수 있습니다. Atlas 관리 API 를 사용하여 모니터링 데이터를 가져올 수도 있습니다.

jSonar를 사용하여 풀 기반 로깅 통합을 구성할 수 있으며, 이를 통해 Splunk 및 SumoLogic과 같은 다른 서비스로 푸시할 수 있습니다. Atlas Administration API를 사용하여 5분마다 로그 데이터를 가져올 수도 있습니다.

클러스터 데이터 볼륨 관리

Atlas는 클러스터 데이터 볼륨을 관리하는 데 도움이 되는 다음과 같은 기본 제공 도구를 제공합니다.

• 클러스터 자동 확장은 애플리케이션 로드에 자동으로 반응하고 클러스터 계층을 조정합니다.

• Online Archive는 자주 액세스하지 않는 데이터의 보관을 자동화합니다.

• 검색 노드 는 독립적으로 확장하다 되며 클러스터 에서 Atlas Search 및 Atlas Vector Search 인덱스 저장 의 오프로드 을 덜 수 있습니다.

• TTL 인덱스는 time series 컬렉션에서 문서를 자동으로 제거하여 공간을 확보합니다.

이러한 도구 외에도 클러스터 크기 조정 가이드를 참조하여 클러스터 크기를 늘리거나 줄이는 방법을 알아보세요. 또한 클러스터를 일시 중지하여 최대 30일 동안 데이터를 보존하면서 비용을 절감할 수도 있습니다.

Support

개발 중인 고객과 엔터프라이즈 고객을 위한 옵션을 포함하여 다양한 지원 계층을 사용할 수 있습니다.

지원 가능한 영역은 다음과 같습니다.

• 관리 중인 MongoDB 클러스터에 대한 문제 및 우려 사항.

• 성능 관련 문의.

• 애플리케이션 측 및 드라이버 상담.