Azure Cosmos DB for MongoDB vCore 클러스터의 컴퓨팅 및 스토리지 구성
적용 대상: MongoDB vCore
컴퓨팅 리소스는 기본 하드웨어의 논리적 CPU를 나타내는 vCore 수로 제공됩니다. 프로비전을 위한 스토리지 크기는 클러스터의 분할에 사용 가능한 용량을 나타냅니다. 스토리지는 데이터베이스 파일, 임시 파일, 트랜잭션 로그 및 데이터베이스 서버 로그에 사용됩니다. 컴퓨팅 및 스토리지 설정을 독립적으로 선택할 수 있습니다. 선택한 컴퓨팅 및 스토리지 값은 클러스터의 각 분할에 적용됩니다.
Azure Cosmos DB for MongoDB vCore에서 컴퓨팅
단일 분할의 총 RAM 양은 선택한 vCore 수를 기반으로 합니다.
클러스터 계층 | vCore 수 | 분할 1개, GiB RAM |
---|---|---|
M25 | 2(버스트 가능) | 8 |
M30 | 2 | 8 |
M40 | 4 | 16 |
M50 | 8 | 32 |
M60 | 16 | 64 |
M80 | 32 | 128 |
M200 | 64 | 256 |
Azure Cosmos DB for MongoDB vCore의 스토리지
프로비전하는 총 스토리지 양은 클러스터의 각 분할에 사용 가능한 I/O 용량도 정의합니다.
스토리지 크기, GiB | 최대 IOPS |
---|---|
32 | 3,500† |
64 | 3,500† |
128 | 3,500† |
256 | 3,500† |
512 | 3,500† |
1,024 | 5,000 |
2,048 | 7,500 |
4,095 | 7,500 |
8,192 | 16,000 |
16,384 | 18,000 |
32,767 | 20,000 |
† 무료 디스크 버스팅을 통한 최대 IOPS. 무료 디스크 버스팅이 사용하도록 설정된 경우 최대 512GiB의 스토리지가 제공됩니다.
컴퓨팅/스토리지 구성을 위한 IOPS 최대화
각 컴퓨팅 구성에는 vCore 수에 따라 달라지는 IOPS 제한이 있습니다. 선택한 스토리지에서 IOPS를 완전히 활용하려면 클러스터에 대한 컴퓨팅 구성을 선택해야 합니다.
스토리지 크기 | 스토리지 IOPS, 최대 | 최소 컴퓨팅 계층 | 최소 vCore |
---|---|---|---|
최대 0.5TiB | 3,500† | M30 | vCore 2개 |
1TiB | 5,000 | M40 | vCore 4개 |
2TiB | 7,500 | M50 | vCore 8개 |
4TiB | 7,500 | M50 | vCore 8개 |
8TiB | 16,000 | M60 | vCore 16개 |
16TiB | 18,000 | M60 | vCore 16개 |
32TiB | 20,000 | M60 | vCore 16개 |
† 무료 디스크 버스팅을 통한 최대 IOPS. 무료 디스크 버스팅이 사용하도록 설정된 경우 최대 512GiB의 스토리지가 제공됩니다.
예를 들어, 분할당 8TiB 이상의 스토리지가 필요한 경우 노드의 컴퓨팅 구성에 대해 16개 이상의 vCore를 선택해야 합니다. 이렇게 선택하면 선택한 스토리지에서 제공하는 IOPS 사용량을 최대화할 수 있습니다.
컴퓨팅 및 스토리지에 대한 고려 사항
작업 집합 및 메모리 고려 사항
Azure Cosmos DB for MongoDB vCore에서 작업 집합은 애플리케이션에서 자주 액세스하고 사용하는 데이터 부분을 나타냅니다. 여기에는 애플리케이션의 일반적인 작업 중에 정기적으로 읽거나 쓰는 데이터와 인덱스가 모두 포함됩니다. MongoDB는 많은 데이터베이스와 마찬가지로 작업 집합이 RAM에 적합할 때 가장 잘 수행되기 때문에 작업 집합의 개념은 성능 최적화에 중요합니다.
MongoDB 데이터베이스 작업 집합을 정의하고 이해하려면 다음 구성 요소를 고려합니다.
- 자주 액세스하는 데이터: 이 데이터에는 애플리케이션이 정기적으로 읽거나 업데이트하는 문서가 포함됩니다.
- 인덱스: 쿼리 작업에 사용되는 인덱스는 빠른 액세스를 보장하기 위해 메모리에 로드되어야 하므로 작업 집합의 일부를 구성합니다.
- 애플리케이션 사용 패턴: 애플리케이션의 사용 패턴을 분석하면 데이터 중 어느 부분이 가장 자주 액세스되는지 파악하는 데 도움이 됩니다.
작업 집합을 RAM에 유지하면 느린 디스크 I/O 작업을 최소화하여 MongoDB 데이터베이스의 성능을 개선할 수 있습니다. 작업 집합이 사용 가능한 RAM을 초과하는 경우 데이터 모델 최적화, RAM 추가 또는 분할을 사용하여 여러 노드에 데이터를 배포하는 것을 고려할 수 있습니다.
워크로드에 대한 최적의 구성 선택
Azure Cosmos DB for MongoDB vCore 워크로드에 적합한 컴퓨팅 및 스토리지 구성을 결정하려면 애플리케이션의 요구 사항 및 사용 패턴과 관련된 여러 요소를 평가해야 합니다. 최적의 구성을 결정하기 위한 주요 단계 및 고려 사항은 다음과 같습니다.
워크로드이해
- 데이터 볼륨: 인덱스를 포함한 데이터의 전체 크기를 예상합니다.
- 읽기/쓰기 비율: 쓰기 작업에 대한 읽기 작업의 비율을 결정합니다.
- 쿼리 패턴: 애플리케이션이 수행하는 쿼리 형식을 분석합니다. 예를 들어, 단순한 읽기, 복잡한 집계 등이 있습니다.
- 동시성: 데이터베이스가 처리해야 하는 동시 실행 작업 수를 평가합니다.
현재 성능 모니터링
- 리소스 사용률: 워크로드를 Azure로 이동하기 전에 모니터링 도구를 사용하여 CPU, 메모리, 디스크 I/O 및 네트워크 사용량을 추적하고 Azure Cosmos DB for MongoDB vCore 클러스터에서 MongoDB 워크로드 실행을 시작한 후에는 메트릭을 모니터링합니다.
- 성능 메트릭: 대기 시간, 처리량, 캐시 적중률과 같은 주요 성능 메트릭을 모니터링합니다.
- 병목 현상: 높은 CPU 사용량, 메모리 압력 또는 느린 디스크 I/O와 같은 기존 성능 병목 현상을 식별합니다.
리소스 요구 사항 예상
- 메모리: 작업 집합(자주 액세스하는 데이터 및 인덱스)이 RAM에 맞는지 확인합니다. 작업 집합 크기가 사용 가능한 메모리를 초과하는 경우 RAM을 추가하거나 데이터 모델을 최적화하는 것이 좋습니다.
- CPU: 쿼리 로드 및 동시성 요구 사항을 처리할 수 있는 CPU 구성을 선택합니다. CPU 집약적인 워크로드에는 더 많은 코어가 필요할 수 있습니다. Azure Cosmos DB for MongoDB vCore 클러스터에서 '최대' 집계와 함께 'CPU 비율' 메트릭을 사용하여 기록 컴퓨팅 사용 패턴을 확인합니다.
- 스토리지 IOPS: 읽기 및 쓰기 작업을 처리하기에 충분한 IOPS가 있는 스토리지를 선택합니다. 클러스터의 '최대' 집계와 함께 'IOPS' 메트릭을 사용하여 기록 스토리지 IOPS 사용량을 확인합니다.
- 네트워크: 특히 분산 설정의 경우 애플리케이션과 데이터베이스 간의 데이터 전송을 처리하기에 적절한 네트워크 대역폭을 보장합니다. SR-IOV와 같은 가속화된 네트워킹 기술을 지원하도록 MongoDB 애플리케이션용 호스트를 구성했는지 확인합니다.
적절하게 크기 조정
- 수직 크기 조정: 컴퓨팅/RAM을 확장 및 축소하고 스토리지를 확장합니다.
- 컴퓨팅: 워크로드에 일시적인 증가가 필요하거나 장기간 CPU 사용률의 70%를 초과하는 경우가 많으면 클러스터에서 vCore/RAM을 늘립니다.
- Azure Cosmos DB for MongoDB vCore 데이터베이스에 적절한 데이터 보존이 있는지 확인합니다. 보존을 통해 불필요한 스토리지 사용을 방지할 수 있습니다. '최대' 집계를 사용하여 '스토리지 비율' 및/또는 '사용된 스토리지' 메트릭에 대한 경고를 설정하여 스토리지 사용량을 모니터링합니다. 워크로드 크기가 사용량의 70%를 초과하면 스토리지 증가를 고려합니다.
- 수평 크기 조정: 워크로드가 증가함에 따라 성능을 향상하고 더 나은 용량 관리를 위해 클러스터에 여러 분할을 사용하여 여러 Azure Cosmos DB for MongoDB vCore 노드에 데이터를 배포하는 것이 좋습니다. 이는 대규모 데이터 세트(2~4TiB 이상) 및 처리량이 높은 애플리케이션에 특히 유용합니다.
- 수직 크기 조정: 컴퓨팅/RAM을 확장 및 축소하고 스토리지를 확장합니다.
테스트 및 반복
- 벤치마킹: 다양한 구성으로 가장 자주 사용되는 쿼리에 대한 측정을 수행하여 성능에 미치는 영향을 확인합니다. CPU/RAM 및 IOPS 메트릭과 애플리케이션 수준 벤치마킹을 사용합니다.
- 부하 테스트: 부하 테스트를 수행하여 프로덕션 워크로드를 시뮬레이션하고 선택한 구성의 성능의 유효성을 검사합니다.
- 지속적인 모니터링: Azure Cosmos DB for MongoDB vCore 배포를 지속적으로 모니터링하고 변화하는 워크로드 및 사용 패턴에 따라 필요에 따라 리소스를 조정합니다.
이러한 요소를 체계적으로 평가하고 구성을 지속적으로 모니터링 및 조정하면 MongoDB 배포가 특정 워크로드에 잘 최적화되어 있는지 확인할 수 있습니다.
스토리지에 대한 고려 사항
워크로드에 적절한 스토리지 크기를 결정하려면 최적의 성능과 확장성을 보장하기 위한 몇 가지 고려 사항이 필요합니다. Azure Cosmos DB for MongoDB vCore의 스토리지 크기에 대한 고려 사항은 다음과 같습니다.
예상 데이터 크기:
- Azure Cosmos DB for MongoDB vCore 데이터의 예상 크기를 계산합니다. 고려할 사항은 다음과 같습니다.
- 현재 데이터 크기: 기존 데이터베이스에서 마이그레이션하는 경우.
- 성장률: 시간이 지남에 따라 추가될 데이터의 양을 예측합니다.
- 문서 크기 및 구조: 스토리지 효율성에 영향을 미치는 데이터 스키마와 문서 크기를 이해합니다.
- Azure Cosmos DB for MongoDB vCore 데이터의 예상 크기를 계산합니다. 고려할 사항은 다음과 같습니다.
인덱스의 요소:
- Azure Cosmos DB for MongoDB vCore는 효율적인 쿼리를 위해 인덱스를 사용합니다. 인덱스는 추가 디스크 공간을 소비합니다.
- 다음을 기준으로 인덱스 크기를 예상합니다.
- 인덱스 수.
- 인덱싱된 필드의 크기.
성능 고려 사항:
- 디스크 성능은 특히 작업 집합을 RAM에 맞출 수 없는 워크로드의 경우 데이터베이스 작업에 영향을 미칩니다. 고려할 사항은 다음과 같습니다.
- I/O 처리량: IOPS(초당 입출력 작업 수)는 1초에 스토리지 디스크로 전송되는 요청 수입니다. 스토리지 크기가 클수록 IOPS도 높아집니다. 읽기/쓰기 작업에 적절한 처리량을 보장합니다. 클러스터에서 사용된 IOPS를 모니터링하려면 '최대' 집계와 함께 'IOPS' 메트릭을 사용합니다.
- 대기 시간: 대기 시간은 애플리케이션이 단일 요청을 수신하고 이를 스토리지 디스크에 보내고 클라이언트에 응답을 보내는데 걸리는 시간입니다. 대기 시간은 IOPS 및 처리량 외에도 애플리케이션의 성능에 대한 중요한 측정입니다. 대기 시간은 주로 사용되는 스토리지 형식과 스토리지 구성에 따라 정의됩니다. Azure Cosmos DB for MongoDB와 같은 관리되는 서비스에서는 프리미엄 SSD 디스크와 같은 빠른 스토리지가 대기 시간을 줄이기 위해 최적화된 설정으로 사용됩니다.
- 디스크 성능은 특히 작업 집합을 RAM에 맞출 수 없는 워크로드의 경우 데이터베이스 작업에 영향을 미칩니다. 고려할 사항은 다음과 같습니다.
향후 증가 및 확장성:
- 향후 데이터 증가 및 확장성 요구 사항을 계획합니다.
- 빈번한 스토리지 확장 없이 성장을 수용할 수 있도록 현재 요구 사항보다 더 많은 디스크 공간을 할당합니다.
계산 예제:
- 초기 데이터 크기가 500GiB라고 가정합니다.
- 인덱스를 사용하면 700GiB까지 증가할 수 있습니다.
- 2년 안에 데이터가 두 배로 늘어날 것으로 예상된다면 1.4TiB(700GiB * 2)를 계획합니다.
- 오버헤드, 증가 및 운영 요구 사항에 대한 버퍼를 추가합니다.
- 지금 1TiB 스토리지로 시작하고 크기가 800GiB 이상으로 커지면 2TiB로 크기 조정할 수 있습니다.
스토리지 크기를 결정하려면 현재 및 향후의 데이터 요구 사항을 예측하고, 인덱싱 및 압축을 고려하고, 적절한 성능과 확장성을 보장해야 합니다. 실제 사용량과 성장 추세를 기반으로 정기적인 모니터링과 조정도 최적의 MongoDB 성능을 유지하는 데 중요합니다.