문서 메뉴
문서 홈
/
MongoDB Atlas
/

Atlas 클러스터 크기 조정 및 계층 선택

이 페이지의 내용

  • 클러스터 자동 확장
  • 메모리
  • 네트워크 트래픽

중요

서버리스 인스턴스에서는 사용할 수 없는 기능입니다.

현재 서버리스 인스턴스는 이와 같은 기능을 지원하지 않습니다. 자세히 보려면 서버리스 인스턴스 제한을참조합니다.

프로덕션 MongoDB deployment를 성공적으로 설정하려면 Atlas cluster 계층과 구성을 올바르게 선택하는 것이 중요합니다. 나중에 언제든지 클러스터를 수정할 수 있지만 데이터 세트 크기와 네트워크 요구 사항에 따라 몇 가지 계산을 수행하면 올바른 구성으로 시작할 수 있습니다.

또한 클러스터 사용량에 따라 클러스터 계층, 스토리지 용량 또는 둘 다를 자동으로 확장하도록 클러스터를 구성하여 클러스터에 필요한 수동 유지 관리를 줄일 수 있습니다. 자세한 내용은 클러스터 자동 확장을 참조하세요.

참고

프로덕션용으로는 M30 이상의 클러스터를 권장합니다.

프로덕션 환경에는 M30 이상의 클러스터가 권장됩니다. 트래픽이 적은 애플리케이션을 위한 프로덕션 환경으로 M10 및 M20 클러스터를 사용할 수 있습니다. M10 및 M20 계층에서 부하가 지속되는 클러스터는 시간이 지남에 따라 성능이 저하될 수 있습니다.

클러스터 계층 M10 이상은 클러스터 자동 확장을 지원합니다. 클러스터 계층 자동 확장은 사용자 인터페이스에서 새 클러스터를 생성할 때 기본적으로 활성화됩니다. API에서 새 클러스터를 생성하면 기본적으로 비활성화됩니다. Atlas는 자동 확장을 활성화하면 클러스터 사용량에 따라 클러스터 계층, 스토리지 용량 또는 둘 모두를 자동으로 확장합니다. 자동 확장을 사용하면 클러스터를 현재 워크로드에 맞게 조정하고 수동 최적화의 필요성을 줄일 수 있습니다.

  • 디스크 용량의 90%를 사용하는 경우, 클러스터 스토리지 확장은 클러스터 스토리지 용량을 자동으로 확장합니다. 이 설정은 클러스터가 항상 갑작스러운 데이터 유입을 지원할 수 있도록 하기 위해 기본적으로 활성화됩니다. 클러스터 스토리지 확장을 사용하지 않으려면 Auto-scale 섹션에서 Storage Scaling 확인란을 선택 취소합니다.

  • 클러스터 계층 확장은 다양한 클러스터 지표에 따라 클러스터 계층을 자동으로 확장 또는 축소합니다. 클러스터 계층 자동 확장을 선택 해제하려면 Auto-scale 섹션에서 Cluster Tier Scaling 확인란을 선택 취소하세요.

    Atlas가 클러스터를 자동 확장하는 방법을 제어하려면 다음을 설정합니다:

    • 클러스터가 자동으로 확장될 수 있는 최대 클러스터 계층입니다. 기본적으로 이 설정은 현재 클러스터 계층과 비교하여 다음 클러스터 계층으로 설정됩니다.

    • 클러스터를 축소할 수 있는 최소 클러스터 계층입니다. 기본적으로 이 설정은 현재 클러스터 계층으로 설정됩니다.

메모리는 Atlas cluster의 각 데이터 보유 노드 에서 사용할 수 있는 물리적 RAM의 총합을 나타냅니다. 예를 들어, M30 표준 복제본 세트는 각 3 데이터 보유 노드에 8 GB RAM으로 구성됩니다.

Atlas는 WiredTiger 스토리지 엔진을 사용합니다.

  • 기본적으로 M40 이상의 클러스터의 경우 WiredTiger는 WiredTiger 캐시에 50% 이상의 물리적 RAM을 전용으로 사용합니다. 나머지 메모리는 다음 용도를 위해 예약됩니다.

    • 정렬 및 계산과 같은 인메모리 작업

    • 기본 운영 체제 및 기타 시스템 서비스

  • 기본적으로 M30 이하 클러스터의 경우, WiredTiger는 물리적 RAM의 25%를 WiredTiger 캐시에 할당합니다.

메모리 사용에 대해 자세히 알아보려면 WiredTiger 및 메모리 사용을 참조하세요.

MongoDB는 WiredTiger 캐시를 사용하여 가장 최근에 사용된 데이터와 인덱스를 보관합니다. 작업 세트는 모든 인덱스와 자주 액세스되는 문서 세트를 합한 것입니다. 작업 세트가 RAM에 맞는 경우, MongoDB는 메모리에서 쿼리를 제공해 가장 빠른 쿼리 응답 시간을 제공합니다.

작업 세트의 크기를 추정하려면 총 인덱스 공간에 대해 db.stats() 에서 얻은 정보를 사용하여 계산을 수행하고 데이터 공간의 백분율이 자주 액세스된다고 가정하거나 다음을 기반으로 메모리 요구 사항을 추정할 수 있습니다. 교육된 가정.

Atlas 샘플 데이터 세트를 사용하여 단일 Atlas 클러스터에서 이러한 모든 데이터베이스를 실행하는 데 필요한 메모리 요건을 계산해 보겠습니다. 다음 JavaScript 프로그램은 클러스터에 대한 데이터베이스 정보를 반환합니다:

var totalIndexSize = 0;
var totalDataSize = 0;
var reservedDBs = ["admin","config","local"];
// Switch to admin database and get list of databases.
db = db.getSiblingDB("admin");
dbs = db.runCommand({ "listDatabases": 1 }).databases;
// Iterate through each database and get its stats.
dbs.forEach(function(database) {
if (reservedDBs.includes(database.name))
return;
db = db.getSiblingDB(database.name);
print("Obtaining stats for " + database.name);
var stats = db.stats();
totalIndexSize += (stats.indexSize / (1024*1024*1024)) ;
totalDataSize += (stats.dataSize / (1024*1024*1024)) ;
});
print ("Total data size in GB: " + totalDataSize.toFixed(2));
print ("Total index size in GB: " + totalIndexSize.toFixed(2));

이 프로그램은 다음과 같은 결과를 반환합니다:

Obtaining stats for sample_airbnb
Obtaining stats for sample_geospatial
Obtaining stats for sample_mflix
Obtaining stats for sample_supplies
Obtaining stats for sample_training
Obtaining stats for sample_weatherdata
Total data size in GB: 0.32
Total index size in GB: 0.02

이러한 데이터베이스를 완전히 메모리 내에서 실행하려면 최소 0.68GB의 물리적 RAM이 필요하며, WiredTiger가 물리적 RAM의 50%를 사용하므로 작업 세트를 메모리에 넣으려면 최소 0.34GB가 필요합니다.

실제 프로덕션 클러스터의 경우 데이터 및 인덱스 크기가 훨씬 커지므로 전체 데이터 세트와 인덱스를 메모리에서 실행하는 것은 실용적이지 않거나 비즈니스 또는 성능 요구 사항에 부합하지 않을 수 있습니다. 다른 시나리오를 살펴보겠습니다.

인기 있는 모바일 게임의 데이터 용량은 512GB, 인덱스 용량은 32GB입니다. 게임의 내부 시스템 데이터는 16GB를 차지하고 나머지는 플레이어 프로필 데이터입니다. 플레이어가 게임을 즐기는 동안 플레이어의 프로필은 메모리에 있어야 합니다. 이 게임의 상시 활동 플레이어의 비율은 전체 플레이어의 25%입니다. 시스템 데이터는 지속적으로 사용되며 최적의 게임 성능을 위해 RAM에 완전히 들어가야 합니다. 또한 가장 빠른 쿼리 응답 시간을 위해 모든 인덱스도 RAM에 포함되어야 합니다. 메모리 크기는 다음과 같습니다:

데이터
RAM 요구 사항
WiredTiger 캐시용 RAM
시스템: 16 GB
RAM 100%
16 GB
인덱스: 32 GB
RAM 100%
32 GB
플레이어 프로필: 496 GB
RAM 용량 25%
124 GB

이러한 요구 사항을 감안할 때 평균 작업 세트 에는 172 GB의 RAM이 필요할 것으로 예상할 수 있습니다.

WiredTiger는 물리적 RAM의 50%를 WiredTiger 캐시에 할당하므로 작업 세트를 수용하는 데 필요한 최소한의 물리적 RAM은 작업 세트의 두 배입니다.

이 예에서는 WiredTiger 캐시와 172GB 작업 세트를 수용하기 위해 최소 344GB의 물리적 RAM이 필요합니다. 다음 표에는 적합한 Atlas 클러스터 계층이 나열되어 있습니다.

서비스 제공자
가능한 클러스터 계층
참고 사항
AWS
  • M300 384GB RAM

  • M400 488GB RAM

  • M700 768GB RAM

M300 충분한 RAM이 있으며 더 높은 클러스터 계층으로 수직 확장할 수 있는 공간이 있습니다.
GCP
  • M300 360GB RAM

M300 RAM이 충분하지만 수직 확장이 필요한 경우 사용할 수 있는 상위 계층이 없습니다.
Azure
  • M300 384GB RAM

  • M400 432GB RAM

M300 충분한 RAM이 있으며 더 높은 클러스터 계층으로 수직 확장할 수 있는 공간이 있습니다.

참고

256 GB RAM이 있는 Azure M200 와 같이 RAM이 충분하지 않은 클러스터 계층을 선택하는 경우 샤딩 이 필요합니다.

클러스터 노드 간, 그리고 Atlas 클러스터에서 데이터를 사용하는 클라이언트 간의 모든 네트워크 트래픽은 네트워크 대역폭에 영향을 미칩니다. 클러스터의 적절한 크기 조정을 위해 클러스터의 각 노드가 처리할 최대 트래픽을 고려하고 이를 기반으로 적절한 Atlas 클러스터 계층을 선택합니다.

클러스터에서 클라이언트 애플리케이션으로의 다운스트림 데이터 전송 속도는 일정 기간 동안 반환된 총 문서의 합계로 계산할 수 있습니다. 프라이머리 노드 에서만 읽는 경우, 이 계산만 수행하면 됩니다. 애플리케이션이 세컨더리 노드 에서도 읽는 경우, 이 숫자를 읽기 작업을 제공할 수 있는 노드 수로 나눌 수 있습니다.

db.stats() 메서드를 사용하여 데이터베이스의 평균 문서 크기를 찾을 수 있습니다. 평균 문서 크기(avgObjSize)에 초당 제공되는 문서 수를 곱하여 필요한 대역폭을 추정합니다.

예제

평균 문서 크기 10KB

초당 100,000건의 문서 제공

10 KB * 100,000 = 초당 1 GB

Atlas 인스턴스는 상위 계층에서 더 빠른 대역폭 속도를 제공합니다. AWS에서 지원하는 인스턴스는 M30 수준에서 초당 최대 10기가비트를 제공하는 반면, M200 수준은 초당 최대 25기가비트를 제공합니다.

Atlas 클러스터는 클러스터 계층에 따라 결정되는 클라이언트 연결 수를 지원할 수 있습니다. M30 클러스터는 최대 2,000개의 동시 연결을 지원하고, M200 클러스터는 최대 128,000개의 동시 연결을 지원합니다.

← 프로덕션 정보