MongoDB - 아키텍처 우수 사례

배치 전략

MongoDB의 배치를 계획 중이면, 몇 가지 핵심 영역을 고려해야 합니다. 가장 중요한 점은 현재 및 예상 데이터 세트 크기입니다. 이러한 두 영역은 개별 실제 노드 리소스 요구의 선택사항에 대한 기본 드라이버이며 샤딩 플랜에 도움이 됩니다. 또한 데이터의 중요도와 데이터 유실 또는 지연 가능성에 대한 허용 정도를 고려해야 합니다(특히 복제된 시나리오에서).

메모리 크기

MongoDB(많은 데이터 지향 애플리케이션처럼)의 경우는 데이터 세트가 메모리에 상주할 때 최상으로 작동합니다. 그 어느 것도 디스크 I/O가 필요 없는 MongoDB 인스턴스보다 성능이 좋을 수 없습니다. 가급적이면, 작업 중인 데이터 세트 크기보다 RAM 가용성이 높은 플랫폼을 선택하십시오. 데이터 세트가 단일 노드에서 사용 가능한 RAM을 초과하는 경우 샤딩 활용을 고려하십시오. 샤딩을 사용하면 대형 데이터 세트를 수용할 수 있는 클러스터의 RAM 크기가 늘어납니다. 따라서 배치에 대한 전체 성능이 최대화됩니다. 페이지 결함은 배치에서 사용 가능한 RAM이 초과되었음을 나타낼 수 있습니다. 사용 가능한 RAM 늘리기를 고려해야 합니다.

디스크 유형

속도가 중요하지 않거나 지원할 수 있는 사용 가능한 메모리 전략보다 큰 데이터 세트가 있는 경우, 배치에 맞는 디스크 유형이 중요합니다. IOPS는 디스크 유형 선택에 있어 중요합니다. IOPS가 클수록 MongoDB의 성능이 좋아집니다. 네트워크 스토리지로 인해 대기 시간이 길어지고 배치의 성능이 저하되면 로컬 디스크를 사용해야 합니다. 디스크 어레이에 RAID 10을 사용하는 것이 좋습니다.

CPU

map-reduce를 사용하려는 경우 클럭 속도 및 사용 가능한 프로세서의 수가 고려사항이 됩니다. 하지만 메모리에 있는 대부분의 데이터와 함께 MongoDB 인스턴스를 실행하는 경우 클럭 속도가 성능에 영향을 줄 수 있습니다. 해당 상황에서 시스템이 실행 중이며 초당 조작을 극대화하려는 경우, 고속 클럭 버스의 CPU가 포함된 배치 전략을 고려하십시오.

복제

클러스터에서 노드에 장애가 발생하면 복제를 통해 데이터의 고가용성이 제공됩니다. 최상의 결과를 얻으려면, MongoDB 배치에서 최소한 세 개의 노드를 사용하여 복제하십시오. 세 개의 노드 복제에 대한 가장 일반적인 구성은 단일 데이터 센터에 두 개의 기본 노드가 있고 보조 데이터 센터에 백업 서버가 있는 2x1 배치입니다.

샤딩

[: #dbt-샤딩]

대형 데이터 세트를 예상하는 경우 샤딩된 MongoDB 배치를 배치하는 것이 좋습니다. 샤딩을 사용하여 다중 노드에서 데이터 세트를 파티션할 수 있습니다. MongoDB는 클러스터의 노드에서 데이터를 자동으로 분배할 수 있습니다. 또는 샤딩 키를 정의하고 해당 키의 범위 기반 샤딩을 작성할 수 있습니다. 샤딩은 쓰기 성능에 도움이 되므로 데이터 세트가 작지만 많은 수의 업데이트나 삽입이 필요한 경우에도 샤딩할 수 있습니다. 샤딩된 세트를 배치하는 경우 MongoDB는 현재 샤드 구성을 추적하는 데 Mongo 런타임에 특화된 세 가지 구성 서버 인스턴스만 필요로 합니다. 이러한 노드 중 하나가 손실되면 클러스터는 구성에 대해서만 읽기 전용 모드로 전환되며 구성을 변경하기 전에 모든 노드를 다시 온라인 상태로 전환해야 합니다.

쓰기 안전 모드

MongoDB에서 디스크에 대한 데이터의 지속성을 처리하는 방법을 제어하는 쓰기 안전 모드에 대한 다수의 옵션이 있습니다. 데이터 무결성과 성능 모두에 대한 요구에 가장 잘 맞는 전략을 고려하는 것이 중요합니다. 다음 쓰기 안전 모드가 사용 가능합니다.

• 없음- 고성능에 도움이 되는 비차단 방식의 지연 쓰기 전략을 제공합니다. 그러나 노드 장애 및 데이터 손실 가능성은 적습니다. 또한 클러스터의 한 노드에 작성된 데이터를 읽기 일관성을 위해 해당 클러스터의 모든 노드에서 즉시 사용하지 못할 수도 있습니다. 없음 모드에서는 네트워크 장애에 대비한 데이터 보호를 제공하지 않습니다. 이 모드는 신뢰성이 매우 낮으며 성능이 우선순위이고 데이터 무결성은 중요하지 않은 경우에만 사용됩니다.
• 정상 – MongoDB의 기본값입니다. 일반 모드도 비차단 지연 쓰기 전략입니다.
• 안전 – MongoDB에서 쓰기 요청의 수신을 확인할 때까지 차단하지만, 쓰기가 완료될 때까지 차단을 수행합니다. 안전 모드는 클러스터 내 데이터 무결성과 읽기 일관성의 레벨을 높입니다.
• 저널 안전 – MongoDB의 복구 옵션을 제공합니다. 저널 안전 모드는 데이터가 수신확인되었으며 리턴 전에 저널 업데이트가 완료되었음을 확인합니다.
• Fsync – 최상위 레벨의 데이터 무결성을 제공하고 데이터의 실제 쓰기가 이루어질 때까지 차단합니다. Fsync를 사용하면 성능이 저하되므로 데이터 무결성이 애플리케이션에 중요한 경우에만 사용합니다.

배치 테스트

10gen에는 배치에 대한 로드 테스트에 사용하는 여러 도구가 있습니다. 콘솔 도구 benchRun은 JavaScript 테스트 도구 내에서 조작을 실행할 수 있습니다. benchRun은 각 조작에 대한 조작 정보와 지연 횟수를 리턴합니다. MongoDB 인스턴스에 대한 자세한 정보가 필요한 경우, mongostat 명령 또는 MMS를 실행하여 테스트 중에 배치를 모니터하는 작업을 고려하십시오.

설치

안정적이고 성능 지향적인 솔루션의 작성에 도움이 되는 MongoDB의 설치 시에 몇 가지 고려사항이 있습니다. 10gen에서는 가급적이면 CentOS(64비트)의 사용을 권장합니다. 32비트 운영 체제와 Windows 운영 체제에서는 배치를 피하십시오. 해당 시스템은 열악한 배치 플랫폼을 제공합니다. 배치에서 RAM 부족을 보충하기 위해 OS에서 가상 메모리를 사용하는 경우, 32비트 운영 체제에는 문제를 유발하는 파일 크기 제한이 있으며 Windows는 성능 문제를 유발할 수 있습니다. 기본적으로 IBM Cloud는 모든 엔지니어링 서버 배치에 CentOS 64비트 운영 체제를 제공합니다.

또한 성능 최대화를 위해 기본 OS 설치를 다음과 같이 변경해야 합니다.

• 16개의 블록으로 SSD 미리 읽기 기본값 설정 – SSD 드라이브는 미리 읽기를 16개의 블록으로 축소할 수 있도록 허용하는 탁월한 찾기 시간을 갖고 있습니다. 스피닝 디스크에는 약간의 버퍼링이 필요하므로 이러한 디스크를 32개의 블록으로 설정합니다.
• noatime – Noatime을 사용하면 시스템이 읽고 있는 파일에 대해 파일 시스템에 기록하지 않아도 됩니다. 즉, 파일 액세스 속도가 빨라지고 디스크 마모가 줄어듭니다.
• BIOS에서 NUMA 끄기 Linux, NUMA 및 MongoDB의 경우는 일반적으로 함께 작동하지 않습니다. NUMA 하드웨어에서 MongoDB를 실행하는 경우 이를 끄는 것이 좋습니다(인터리브 메모리 정책을 사용하여 실행). 실행하지 않는 경우 엄청나게 느려지거나 높은 시스템 CPU 시간 발생 등의 문제점이 나타날 수 있습니다.
• ulimit 설정 – 열린 파일의 경우 ulimit가 64,000으로 설정되고, 사용자 프로세스의 경우 ulimit가 32,000으로 설정됩니다. 이러한 ulimit를 사용하여 사용 가능한 파일 핸들 또는 사용자 프로세스 유실로 인한 실패를 방지합니다.
• ext4 사용 – Ext3은 파일 할당(또는 제거) 시 느립니다. 또한 ext3의 경우 대형 파일 내 액세스도 양호하지 않습니다.

기본적으로 이러한 변경 사항은 모든 IBM Cloud 서버에 설정됩니다.

저널 볼륨과 데이터 볼륨은 개별 실제 볼륨이어야 합니다. 저널 및 데이터 디렉토리가 단일 실제 볼륨에 있는 경우, 저널에 대한 비우기로 인해 데이터 액세스가 인터럽트되며 MongoDB 배치 내에서 긴 대기 시간에 대한 스파이크가 나타납니다.

조작

MongoDB 배치가 프로덕션으로 승격되면, 모니터링 및 성능 최적화를 위한 다음의 권장사항을 고려하십시오.

• MMS 에이전트가 MongoDB의 모든 인스턴스에서 실행 중인지 확인하십시오. 이는 배치의 상태와 성능을 모니터링하는 데 도움이 됩니다. MMS 에이전트는 지원 상호작용 중에 10gen에 유용한 디버깅 데이터를 제공합니다.
• mongostat 명령은 MongoDB 노드의 성능에 대한 런타임 정보도 제공합니다.

이러한 도구 중 하나가 성능 문제를 발견하면 샤딩 또는 색인 작성을 통해 이러한 성능 문제를 정정할 수 있습니다.

• 모니터링 도구에서 필드 기반 쿼리가 제대로 작동하지 않는 것으로 표시되는 경우 MongoDB 배포에 대한 인덱스를 만듭니다. 성능 향상에 도움이 되도록 개별 필드를 기반으로 한 데이터를 조회할 때 항상 색인을 사용하십시오.
• 대형 운용 데이터 세트로 인해 노드의 전체 성능이 저하될 때는 샤딩을 사용하십시오. 상황이 악화되기 전에 샤딩해야 합니다. 시스템은 삽입 또는 업데이트 시 샤딩을 위해서만 청크를 분할합니다. 샤딩에 너무 시간이 오래 걸리면 불균등하게 분배될 수 있습니다.