Atlas Search 배포 옵션
이 페이지의 내용
사전 프로덕션 또는 프로덕션 환경의 요구 사항을 충족하도록 다양한 배포 유형, 클라우드 제공자, 클러스터 계층으로 Atlas 클러스터를 구성할 수 있습니다. 이러한 권장 사항을 사용하여 벡터 Atlas Search를 수행하기 위한 배포 유형, 클라우드 제공자 및 리전, 클러스터 및 Atlas Search 계층을 선택합니다.
환경 | 배포 유형 | 클러스터 계층 | 클라우드 제공자 리전 | 노드 아키텍처 |
|---|---|---|---|---|
쿼리 테스트 | Shared or dedicated cluster Local deployment | M0, M2, M5, or higher tierN/A | All N/A | MongoDB 및 Atlas Search 프로세스는 동일한 노드에서 실행됩니다. |
프로토타입 애플리케이션 | 전용 클러스터, 샤딩 또는 비샤딩 | M10, M20 이상 계층 | 모두 | MongoDB 및 Atlas Search 프로세스는 동일한 노드에서 실행됩니다. |
프로덕션 | 별도의 검색 노드가 있는 전용 클러스터, 샤딩 또는 비샤딩 | M10 이상 클러스터 계층 및 S10 이상 검색 계층 | 일부 리전 및 Google Cloud에서 AWS, 모든 리전에서 Azure | MongoDB 와 Atlas Search 프로세스는 서로 다른 노드에서 실행됩니다. |
이러한 배포 모델에 대해 자세히 알아보려면 다음 섹션을 검토하세요.
테스트 및 프로토타입 제작 환경
검색 쿼리를 테스트하고 애플리케이션의 프로토타입을 만들려면 다음 구성을 권장합니다. 이 구성은 다음과 같은 사용 사례에 가장 적합합니다.
인덱싱할 총 문서가 2백만 개 미만입니다.
인덱싱된 데이터가 10GB 미만입니다.
7일 기간 동안 10,000건 미만의 쿼리.
사용량이 명시된 값을 초과하면 별도의 검색 노드로 마이그레이션하세요.
배포 유형
Atlas Search 쿼리를 테스트하기 위해 공유 또는 전용 클러스터 또는 로컬 Atlas 배포를 배포할 수 있습니다.
Cluster Tiers
공유 클러스터에는 M0, M2 및 M5 계층이 포함됩니다. 이러한 저비용 클러스터 유형은 Atlas Search 쿼리를 테스트하는 데 사용할 수 있습니다. 그러나 공유 클러스터에서 리소스 경합 및 쿼리 지연 시간이 발생할 수 있습니다. 공유 클러스터로 프로젝트를 시작하는 경우 애플리케이션을 프로덕션에 사용할 준비가 되면 상위 계층으로 업그레이드하는 것이 좋습니다.
전용 클러스터에는 M10 이상의 계층이 포함됩니다. M10 및 M20 계층은 애플리케이션 프로토타입을 제작하는 데 적합합니다. 애플리케이션을 프로덕션할 준비가 되면 상위 계층으로 업그레이드하여 대규모 데이터 세트를 처리하거나, 워크로드 격리를 위한 전용 검색 노드를 배포할 수 있습니다.
클라우드 제공자 및 리전
모든 클러스터 계층은 지원되는 모든 클라우드 공급자 리전에서 사용할 수 있습니다. 선택한 클라우드 공급자와 리전은 클러스터 계층에 사용할 수 있는 구성 옵션과 클러스터 실행 비용에 영향을 미칩니다.
Atlas Search 쿼리를 로컬에서 테스트하려는 경우, Atlas CLI를 사용하여 로컬 컴퓨터에 호스팅된 단일 노드 복제본 세트를 배포할 수 있습니다. 자세한 내용은 로컬 Atlas 배포 만들기를 참조하세요.
애플리케이션을 프로덕션할 준비가 되면 실시간 마이그레이션을 사용하여 로컬 Atlas 배포를 프로덕션 환경으로 마이그레이션하세요. 로컬 배포는 로컬 컴퓨터의 CPU, 메모리 및 스토리지 리소스에 의해 제한됩니다.
노드 아키텍처
이 배포 모델에서는 Atlas 클러스터의 각 노드에서 검색 mongot 프로세스가 mongod 프로세스와 함께 실행됩니다. mongod 프로세스는 쿼리를 동일한 노드의 mongot로 라우팅하고 동일한 리소스를 공유합니다.
기본적으로 Atlas는 첫 번째 Atlas Search 인덱스를 생성할 때 mongod 프로세스를 실행하는 동일한 노드에서 검색 mongot 프로세스를 활성화합니다. mongot 프로세스는 mongot 프로세스 소개에 설명된 작업을 수행합니다.
Atlas Search 인덱스에서 저장된 소스 필드를 정의하면 mongot 프로세스가 지정된 필드를 mongot에 저장할 수 있습니다. 그런 다음, 데이터베이스에서 전체 문서를 조회하는 대신 Atlas Search 쿼리에서 ReturnStoredSource 옵션을 사용하여 일치하는 문서에 대한 저장된 필드를 mongot 파일에서 직접 조회할 수 있습니다.
혜택
Atlas Search를 활성화하면 통합된 완전 관리형 검색 엔진을 통해 데이터 위에 쉽게 검색 기능을 구축할 수 있으며, 이는 데이터베이스와 자동으로 동기화됩니다. Atlas Search는 $search 및 $searchMeta와 같은 Atlas Search 집계 파이프라인 단계를 사용하여 전체 텍스트 검색을 수행하고 $vectorSearch를 사용하여 시맨틱 검색을 다른 MongoDB 집계 파이프라인 단계와 함께 사용할 수 있는 풍부한 쿼리 언어를 제공합니다.
클러스터에 프로비저닝된 리소스에 따라 두 프로세스를 동일한 노드에 배포하는 것이 별도의 전용 노드에서 검색 프로세스를 실행하는 것보다 비용 효율성이 더 높을 수 있습니다.
제한 사항
데이터베이스 mongod와 검색 mongot 프로세스 간에 리소스 경합이 발생할 수 있습니다. 이는 인덱스 성능과 쿼리의 지연 시간에 부정적인 영향을 미칠 수 있습니다. 이 배포서버 모델은 테스트 및 프로토타이핑 환경에만 사용하는 것을 권장합니다. 프로덕션에 즉시 사용할 수 있는 애플리케이션과 관련 검색 워크로드에는 전용 검색 노드로 마이그레이션하는 것이 좋습니다.
비용
Atlas 클러스터에서 Atlas Search를 활성화해도 추가 비용이나 요금은 없습니다. 그러나 인덱싱된 컬렉션의 크기 또는 인덱스 정의와 같은 요인에 따라 클러스터의 리소스 사용률이 증가할 수 있습니다.
고려 사항
mongod 및 mongot 프로세스가 모두 동일한 노드 에서 실행 되므로 특정 상황에서는 mongot 을(를) 사용하지 못할 수 있습니다. 다음 표에서는 잠재적인 원인에 대해 설명합니다.
원인 | 설명 |
|---|---|
클러스터 계층 확장 - 네트워크 스토리지 | 클러스터 를 확장하다 또는 축소하면 Atlas 가 새 인스턴스 프로비저닝합니다. 인스턴스 가 준비되면 Atlas 는 네트워크 저장 를 연결하고 새 노드에서
|
클러스터 계층 확장 - 로컬 SSD | 로컬 SSD 를 사용하여 Atlas cluster 를 확장하다 하는 경우 저장 를 유지했다가 새 노드에 다시 연결할 수 없습니다. 따라서 Atlas 는 초기 동기화 를 수행하여 검색 인덱스를 다시 작성합니다. 초기 동기화 가 완료될 때까지 검색 쿼리가 실패합니다. |
루센 다운그레이드 | 드문 경우지만 루센 다운그레이드해야 하는 경우 최신 루센 인덱스 형식을 읽지 못할 수도 있습니다. |
스토리지 조정 | Atlas cluster 노드에 연결된 네트워크 저장 를 유지할 수 있습니다. 이를 통해 그러나 클러스터 가 로컬 NVMe 디스크를 사용하는 특정 리전 또는 기타 드문 상황에서는 네트워크 저장 를 유지하지 못할 수 있습니다. 이러한 경우 Atlas 는 초기 동기화 를 수행하며 초기 동기화 가 완료될 때까지 검색 쿼리가 실패합니다. |
mongot 버전 업데이트 | mongot 버전 업데이트 중에 Atlas 는 mongot 의 이전 버전을 중지하고 새 버전을 시작합니다. 이 짧은 기간 동안에는 새 mongot 가 작동할 때까지 검색 쿼리가 실패합니다. |
새 mongod 노드 | 클러스터 에 새 노드 를 추가하면 Atlas 가 초기 동기화 를 수행하여 검색 인덱스를 생성합니다. 새 mongod 노드 를 사용하는 검색 쿼리는 초기 동기화 가 완료될 때까지 실패합니다. |
인스턴스 재부팅 또는 교체 |
|
프로덕션 환경
프로덕션 지원 애플리케이션의 경우 다음 클러스터 구성을 권장합니다. 이 구성은 다음과 같은 사용 사례에 적합합니다.
인덱싱할 총 문서 수가 2백만 개 이상입니다.
인덱싱된 데이터가 10GB를 초과합니다.
7일 기간 동안 쿼리가 10,000개를 초과합니다.
배포 유형
프로덕션용 애플리케이션의 경우 전용 클러스터가 필요합니다.
Cluster Tiers
전용 클러스터에는 M10 및 그 이상의 계층이 포함됩니다. M10 및 M20 계층은 개발 및 프로덕션 환경에 적합합니다. 그러나 더 높은 계층은 대용량 데이터 세트와 프로덕션 작업을 처리할 수 있습니다. 검색 워크로드를 위해 전용 검색 노드를 배포하는 것도 좋습니다. 이를 통해 검색 배포를 독립적이고 적절하게 확장할 수 있습니다.
클라우드 제공자 및 리전
검색 노드는 Google Cloud 및 Azure의 모든 리전에서 사용할 수 있지만, AWS의 경우에는 일부 리전에서만 사용할 수 있습니다. 배포에 사용할 수 있는 클라우드 공급자와 검색 노드를 반드시 선택해야 합니다.
모든 클러스터 계층은 지원되는 클라우드 공급자 리전에서 사용할 수 있습니다. 선택하는 클라우드 공급자 및 리전은 클러스터에 사용할 수 있는 구성 옵션 및 검색 계층과 클러스터 실행 비용에 영향을 줍니다.
노드 아키텍처
이 배포 모델에서 mongot 프로세스는 mongod 프로세스가 실행되는 클러스터 노드와 분리된 검색 노드에서 실행됩니다. Atlas는 각 클러스터 또는 클러스터의 각 샤드와 함께 검색 노드를 배포합니다.
예를 들어 샤드가 3개인 클러스터에 검색 노드 2개를 배포하면 Atlas는 검색 노드를 샤드당 2개씩, 총 6개를 배포합니다. 또한 검색 노드 수와 각 검색 노드에 프로비저닝된 리소스의 양을 구성할 수도 있습니다.
별도의 검색 노드를 배포하는 경우 Atlas는 인덱싱을 위해 각 mongot에 대한 mongod를 자동으로 할당합니다. mongot는 저장하는 인덱스에 대한 변경 사항을 수신하고 동기화하기 위해 mongod와 통신합니다. Atlas Search는 mongod 및 mongot 프로세스가 동일한 노드에서 실행될 때와 비슷하게 쿼리를 인덱싱하고 처리합니다. 자세한 내용은 Atlas 검색 인덱스 만들기 및 관리 와 Atlas 검색 쿼리 만들기 및 실행을 참조하세요. 검색 노드를 별도로 배포하는 방법에 대해 자세히 알아보려면 워크로드 격리를 위한 검색 노드를 참조하세요.
검색 노드로 마이그레이션할 때, Atlas는 검색 노드를 배포하지만 검색 노드에서 클러스터의 모든 인덱스를 성공적으로 구축할 때까지 해당 노드에서 쿼리를 제공하지 않습니다. Atlas가 새로운 노드에서 인덱스를 구축하는 동안 클러스터 노드에 있는 인덱스를 사용하여 계속해서 쿼리를 제공합니다. Atlas는 검색 노드에서 인덱스를 성공적으로 구축하고 클러스터 노드에서 인덱스를 제거한 후에만 검색 노드에서 쿼리를 제공하기 시작합니다.
클러스터의 모든 검색 노드를 삭제하면 검색 쿼리 결과 처리가 중단될 수 있습니다. 자세한 내용은 클러스터 수정을 참조하세요. Atlas 클러스터를 삭제하면 Atlas가 일시 중지된 후 관련된 모든 Atlas Search 배포(mongot 프로세스)를 삭제합니다.
Atlas Search 인덱스에서 저장된 소스 필드를 정의하면 mongot 프로세스가 지정된 필드를 mongot에 저장할 수 있습니다. 그런 다음, 데이터베이스에서 전체 문서를 조회하는 대신 Atlas Search 쿼리에서 ReturnStoredSource 옵션을 사용하여 일치하는 문서에 대한 저장된 필드를 mongot 파일에서 직접 조회할 수 있습니다.
혜택
별도의 검색 노드를 배포하면 다음과 같은 이점이 있습니다.
- 고가용성
- 별도의 검색 노드를 배포할 때 Atlas는 장애나 중단 시 최소한의 다운타임으로 작업 부하가 계속 작동하도록 최소 두 개의 검색 노드를 작용합니다.
- 확장성
별도의 검색 노드를 배포하면 다음을 수행할 수 있습니다.
스토리지와 컴퓨팅을 MongoDB 클러스터와 독립적으로 확장합니다.
쿼리 부하를 MongoDB와 독립적으로 확장할 수 있습니다.
검색 노드를 수평 및 수직으로 확장할 수 있습니다.
검색 노드의 수를 늘리거나 줄이고 클러스터를 수평으로 확장할 수 있습니다. 최소 2개에서 최대 32개의 검색 노드를 프로비저닝할 수 있으며 두 값 모두 포함됩니다. Atlas Search는 사용 가능한 검색 노드 목록을 순환하며 쿼리를 검색 노드에서 실행하도록 배포합니다. 이를 통해 모든 프로비저닝된 노드에 쿼리 부하가 균등하게 분산되도록 합니다.
검색 노드에 대한 다양한 검색 계층을 선택할 수 있습니다. 다양한 검색 계층을 통해 전체 텍스트 및 벡터 워크로드에 가장 적합한 CPU, RAM, 스토리지 구성을 선택할 수 있습니다.
- 성능
별도의 검색 노드를 배포하면
mongod프로세스와mongot프로세스 모두에 대한 성능 및 리소스 사용률이 향상되고 두 프로세스 간의 리소스 경합이 제거됩니다.전용 검색 노드는 동시 세그먼트 검색을 지원하므로, Atlas Search에서 여러 인덱스 세그먼트를 동시에 검색하고 경우에 따라 쿼리 응답 시간을 개선할 수 있습니다. 자세한 내용은 세그먼트간 쿼리 실행 병렬 처리를 참조하세요.
클러스터 크기 조정 및 확장
검색 노드에 필요한 메모리 양을 확인하려면 다음 Atlas 메트릭을 사용하세요.
검색 인덱스의 크기
검색 노드의 총 RAM
예를 들어 다음을 고려하세요.
검색 인덱스 크기 = 10GB
검색 노드의 총 RAM = 4GB
전체 4GB의 RAM 중 1GB가 다른 프로세스에 의해 사용되고 인덱스 데이터에는 3GB만 사용할 수 있다고 가정해 보겠습니다. 그러 나머지 7GB의 인덱스 데이터(10GB - 3GB = 7GB)는 필요에 따라 디스크에서 페이징됩니다. 디스크에서 빈번한 페이징(7GB)은 페이지 폴트, 디스크 I/O, CPU IOWait를 증가시켜 성능 저하를 초래합니다.
더 많은 RAM(8GB 이상)을 가진 상위 검색 계층은 대부분의 검색 인덱스 데이터를 메모리에서 제공하여 디스크 읽기와 페이지 폴트를 최소화하고 성능을 개선합니다.
참고
검색 노드에 사용되는 로컬 SSD는 인덱스 작업을 지원하기 위해 20% 스토리지 오버헤드가 필요합니다.
검색 노드 비용
MongoDB는 전용 (M10 이상) 클러스터에서 별도의 검색 노드를 지원합니다. 검색 노드는 컴퓨팅 집약적인 NVMe 인스턴스에 배포됩니다. 노드는 두 개 이상 배포해야 합니다. 노드마다 매일 시간당 리소스 사용에 대한 요금이 청구됩니다. 자세한 사항은 검색 노드 비용을 참조하세요.
전용 Atlas Search 노드로 마이그레이션
전용 검색 노드를 사용하면 클러스터와 별도로 검색 배포의 규모를 조정하고 확장할 수 있습니다. 또한 동일한 노드에서 데이터베이스와 검색 프로세스를 모두 실행하는 클러스터에서 발생할 수 있는 리소스 경합을 제거합니다.
전용 검색 노드로 마이그레이션하려면 배포를 다음과 같이 변경합니다.
현재 배포에서 공유 계층을 사용하는 경우 클러스터를 더 높은 계층으로 업그레이드하세요. 전용 검색 노드는
M10이상 클러스터 계층에서만 지원됩니다. 다른 클러스터 계층으로 마이그레이션하는 방법에 대해 자세히 알아보려면 Cluster Tier 수정을 참조하세요.전용 검색 노드는 AWS 리전의 하위 집합과 지원되는 모든 Google Cloud 및 Azure 리전에서 사용할 수 있습니다. 검색 노드를 사용할 수 있는 리전에 클러스터를 배포하세요. 기존 클러스터가 검색 노드를 사용할 수 없는 리전에 있는 경우 클러스터를 검색 노드를 사용할 수 있는 리전으로 마이그레이션하세요. 자세한 내용은 클라우드 공급자 리전을 참조하세요.
Search Nodes for workload isolation을 활성화하고 검색 노드를 구성합니다. 자세한 내용은 검색 노드 추가를 참조하세요.
별도의 검색 노드를 배포하는 경우, Atlas가 검색 노드에서 인덱스를 구축하는 동안 Atlas Search는 Atlas 클러스터의 인덱스를 사용하여 쿼리를 계속 처리합니다. Atlas는 다음을 완료한 후에만 쿼리를 검색 노드로 라우팅합니다.
모든 인덱스를 검색 노드에서 성공적으로 빌드합니다.
클러스터 노드에서 검색 인덱스를 제거합니다.