자체 관리 배포를 위한 운영 체크리스트
다음 체크리스트는 개발 체크리스트 목록과 함께 프로덕션 MongoDB 배포에서 문제를 방지하는 데 도움이 되는 권장 사항을 제공합니다.
파일 시스템
디스크 파티션을 RAID 구성에 맞게 정렬합니다.
dbPath
에 NFS 드라이브를 사용하지 않도록 합니다. NFS 드라이브를 사용하면 성능이 저하되고 불안정해질 수 있습니다. 자세한 정보는 원격 파일 시스템(NFS)을 참조하세요.VMware 사용자는 NFS를 통해 VMware 가상 드라이브를 사용해야 합니다.
Linux/Unix: 드라이브를 XFS 또는 EXT4로 포맷합니다. 가능하면 일반적으로 MongoDB에서 더 나은 성능을 발휘하는XFS를 사용하세요.
WiredTiger 스토리지 엔진과 함께 EXT4를 사용할 때 발생하는 성능 문제를 방지하려면 XFS를 사용할 것을 강력히 권장합니다.
RAID를 사용하는 경우 RAID 지오메트리로 XFS를 구성해야 할 수 있습니다.
Windows: NTFS 파일 시스템을 사용합니다. FAT 파일 시스템은 사용하지 않습니다(예: FAT 16/32/exFAT).
복제
숨겨지지 않은 모든 복제 세트 구성원이 RAM, CPU, 디스크, 네트워크 설정 등과 관련하여 동일하게 프로비저닝되었는지 확인합니다.
사용 사례에 맞게 oplog 크기를 구성하세요.
복제 oplog window는 전체 재동기화가 필요하지 않도록 일반적인 유지 보수 및 다운타임 윈도우를 포함해야 합니다.
복제 oplog window는 마지막 백업에서 복제 세트 구성원을 복원하는 데 필요한 시간이 포함되어야 합니다.
참고
복제 oplog window는 데이터 복사 중에 oplog 레코드를 가져오므로 초기 동기화를 통해 복제본 세트 멤버를 복원하는 데 필요한 시간을 포함할 필요가 없습니다. 그러나 복원되는 멤버는 이 데이터 복사 단계 동안 이러한 oplog 레코드를 임시로 저장할 수 있는 충분한 디스크 공간이 로컬 데이터베이스에 있어야 합니다.
복제본 세트에 저널링과 함께 실행되는 데이터 보유 투표 멤버가 셋 이상 포함되어 있고 가용성과 내구성을 위해
w: majority
쓰기 고려를 통해 쓰기를 발행해야 합니다.복제본 세트 구성원을 구성할 때는 IP 주소가 아닌 호스트 이름을 사용합니다.
모든
mongod
인스턴스 간의 완전한 양방향 네트워크 연결을 보장합니다.각 호스트가 스스로 해결할 수 있는지 확인합니다.
복제본 세트에 홀수의 투표 회원 수가 포함되어 있는지 확인하세요.
mongod
인스턴스에0
또는1
투표가 있는지 확인합니다.고가용성을 위해 복제본 세트를 최소 3개의 데이터 센터에 배포합니다.
샤딩
대규모 클러스터에서 최적의 성능을 발휘할 수 있도록 전용 하드웨어에 config 서버를 배치하세요. 데이터 파일을 메모리에 완전히 저장할 수 있도록 하드웨어에 충분한 RAM 공간이 있고 전용 저장 공간이 있는지 확인합니다.
NTP를 사용하여 샤딩된 클러스터의 모든 구성 요소의 시계를 동기화합니다.
CNAME을 사용하여 클러스터에 대한 config 서버를 식별하면 가동 중지 시간 없이 구성 서버의 이름을 바꾸고 번호를 다시 지정할 수 있습니다.
저널링: WiredTiger 스토리지 엔진
모든 인스턴스가 저널링을사용하도록 합니다.
쓰기 집약적인 워크로드를 위해 지연 시간이 짧은 자체 디스크에 저널을 배치하세요. 데이터베이스 상태를 구성하는 파일이 별도 볼륨에 상주하므로 이는 스냅샷 스타일 백업에 영향을 미칩니다.
하드웨어
클라우드 하드웨어에 배포
Windows Azure: TCP 킵얼라이브(
tcp_keepalive_time
)를 100~120으로 조정합니다. Azure 부하 분산 장치의 TCP 유휴 시간 제한이 MongoDB의 연결 풀링 동작에 비해 너무 느립니다. 자세한 내용은 Azure 프로덕션 정보를 참조하세요.Windows Azure와 같이 지연 시간이 긴 스토리지가 있는 시스템에서는 MongoDB 버전 2.6.4 이상을 사용하세요. 이 버전에는 해당 시스템에 대한 성능 개선 사항이 포함되어 있습니다.
운영 체제 구성
Linux
MongoDB 8.0 이상을 실행 중인 경우 Transparent Hugepages를 활성화합니다.
MongoDB 7.0 또는 이전 버전을 실행하는 경우 Transparent Hugepages를 비활성화합니다.
데이터베이스 파일을 저장하는 장치에서 미리 읽기 설정을 조정합니다.
테스트 결과 더 높은 미리 읽기 값에서 측정 가능하고 반복 가능한 확실한 이점이 확인되지 않는 한 WiredTiger 스토리지 엔진은 스토리지 미디어 유형(회전 디스크, SSD 등)에 관계없이 8에서 32 사이의 미리 읽기 값을 설정합니다.
MongoDB 상업 부문 지원 팀은 대체 리드헤드(readahead) 구성에 대한 지침을 제공할 수 있습니다.
RHEL/CentOS에서
tuned
을(를) 사용하는 경우tuned
프로필을 사용자 지정해야 합니다. RHEL/CentOS와 함께 제공되는 많은tuned
프로필은 기본 설정을 사용할 경우 성능에 부정적인 영향을 미칠 수 있습니다. 선택한tuned
프로필을 다음과 같이 사용자 지정합니다:MongoDB 버전에 따라 Transparent Hugepages를 활성화하거나 비활성화합니다.
MongoDB 8.0 이상 버전을 사용하는 경우 tuned 및 ktune을 사용하여 THP 활성화를 참조하세요.
MongoDB 7.0 이하 버전을 사용하는 경우 tuned 및 ktune을 사용하여 THP 비활성화를 참조하세요.
저장 미디어 유형에 관계없이 리드헤드를 8~32로 설정합니다. 자세한 내용은 리드헤드 설정을 참조하세요.
SSD의 경우 cfq 또는
deadline
디스크 스케줄러를 사용합니다.게스트 VM의 가상화된 드라이브에 cfq 디스크 스케줄러를 사용합니다.
NUMA를 비활성화하거나 vm.zone_reclaim_mode를 0으로 설정하고 노드 인터리빙을 사용하여
mongod
인스턴스를 실행합니다. 자세한 내용은 MongoDB 및 NUMA 하드웨어를 참조하세요.사용 사례에 맞게 하드웨어의
ulimit
값을 조정합니다. 동일한 사용자로 여러 개의mongod
또는mongos
인스턴스를 실행 중인 경우ulimit
값을 적절히 조정합니다. 자세한 내용은 자체 관리 배포에 대한 UNIXulimit
설정을 참조하세요.dbPath
마운트 지점에noatime
을 사용합니다.배포서버에 충분한 파일 핸들(
fs.file-max
), 커널 pid 제한(kernel.pid_max
), 프로세스당 최대 스레드(kernel.threads-max
), 프로세스당 최대 메모리 맵 영역(vm.max_map_count
)을 구성합니다. 대규모 시스템의 경우 다음 값이 좋은 출발점이 될 수 있습니다.fs.file-max
98000kernel.pid_max
64000,kernel.threads-max
값을 64000으로 설정하고vm.max_map_count
131060값
시스템에 스왑 공간이 구성되어 있는지 확인합니다. 적절한 크기 조정에 대한 자세한 내용은 운영 체제의 설명서를 참조하세요.
시스템 기본 TCP 킵얼라이브가 올바르게 설정되어 있는지 확인합니다. 값이 120인 경우 복제본 세트 및 샤딩된 클러스터에 더 나은 성능을 제공하는 경우가 많습니다. 자세한 내용은 자주 묻는 질문에서 TCP
keepalive
시간이 MongoDB deployment에 영향을 주나요?를 참조하세요.
Windows
NTFS '마지막 액세스 시간' 업데이트를 사용하지 않도록 설정하는 것이 좋습니다. 이는 Unix 계열 시스템에서
atime
비활성화를 하는 것과 유사합니다.4096바이트의 Allocation unit size 기본값을 사용하여 NTFS 디스크를 포맷합니다.
백업
백업 및 복원 프로세스의 주기적 테스트 일정을 예약하여 예상 시간을 확인하고 기능을 확인합니다.
모니터링
MongoDB Enterprise Advanced에서 사용할 수 있는 온프레미스 솔루션인 MongoDB Cloud Manager 또는 Ops Manager를 사용하거나 다른 모니터링 시스템을 사용하여 주요 데이터베이스 지표를 모니터링하고 이에 대한 알림을 설정하세요. 다음 메트릭에 대한 알림을 포함하세요.
복제 지연
복제 oplog window
어설션(assertions)
queues
페이지 오류
서버의 하드웨어 통계를 모니터링합니다. 특히 디스크 사용량, CPU 및 사용 가능한 디스크 공간에 주의를 기울입니다.
디스크 공간 모니터링이 없는 경우 또는 예방 조치로는 다음을 수행하세요.
storage.dbPath
드라이브에 4GB의 더미 파일을 만들어 디스크가 가득 차면 사용 가능한 공간을 확보하세요.다른 모니터링 도구를 사용할 수 없는 경우
cron+df
조합을 사용하면 디스크 공간이 최고 수위점에 도달할 때 경고를 보낼 수 있습니다.
부하 분산
로드 밸런서를 구성하여 기존 연결에 충분한 시간 제한을 두고 'Sticky Sessions' 또는 '클라이언트 선호도'를 활성화합니다.
MongoDB 클러스터 또는 복제본 세트 구성 요소 사이에 로드 밸런서를 배치하지 않도록 합니다.
보안
MongoDB 설치를 보호하기 위한 보안 조치 목록은 MongoDB 보안 체크리스트를 참조하세요.