문서 메뉴
문서 홈
/
MongoDB 매뉴얼
/
관리

자체 관리형 배포서버를 위한 운영 체크리스트

이 페이지의 내용

  • 파일 시스템
  • 복제
  • 샤딩
  • 저널링: WiredTiger 스토리지 엔진
  • 하드웨어
  • 클라우드 하드웨어에 배포
  • 운영 체제 구성
  • 백업
  • 모니터링
  • 부하 분산
  • 보안

다음 체크리스트는 개발 체크 리스트 목록과 함께 프로덕션 MongoDB deployment에서 문제를 방지하는 데 도움이 되는 권장 사항을 제공합니다.

파일 시스템

복제

  • 숨겨지지 않은 모든 복제 세트 구성원이 RAM, CPU, 디스크, 네트워크 설정 등과 관련하여 동일하게 프로비저닝되었는지 확인합니다.

  • 사용 사례에 맞게 oplog 크기를 구성하세요.

    • 복제 oplog 윈도우는 전체 재동기화가 필요하지 않도록 일반적인 유지 보수 및 다운타임 윈도우를 포함해야 합니다.

    • 복제 oplog 윈도우는 마지막 백업에서 복제 세트 구성원을 복원하는 데 필요한 시간이 포함되어야 합니다.

      참고

      복제 oplog window는 데이터 복사 중에 oplog 레코드를 가져오므로 초기 동기화를 통해 복제본 세트 구성원을 복원하는 데 필요한 시간을 포함할 필요가 없습니다. 그러나 복원되는 멤버는 이 데이터 복사 단계 동안 이러한 oplog 레코드를 임시로 저장할 수 있는 충분한 디스크 공간이 로컬 데이터베이스에 있어야 합니다.

  • 복제본 세트에 저널링과 함께 실행되는 데이터 보유 투표 멤버가 셋 이상 포함되어 있고 가용성과 내구성을 위해 w: majority 쓰기 고려를 통해 쓰기를 발행해야 합니다.

  • 복제본 세트 구성원을 구성할 때는 IP 주소가 아닌 호스트 이름을 사용합니다.

  • 모든 mongod 인스턴스 간의 완전한 양방향 네트워크 연결을 보장합니다.

  • 각 호스트가 스스로 해결할 수 있는지 확인합니다.

  • 복제본 세트에 홀수의 투표 회원 수가 포함되어 있는지 확인하세요.

  • mongod 인스턴스에 0 또는 1 투표가 있는지 확인합니다.

  • 고가용성을 위해 복제본 세트를 최소 3개의 데이터 센터에 배포합니다.

샤딩

  • 대규모 클러스터에서 최적의 성능을 발휘할 수 있도록 전용 하드웨어에 config 서버를 배치하세요. 데이터 파일을 메모리에 완전히 저장할 수 있도록 하드웨어에 충분한 RAM 공간이 있고 전용 저장 공간이 있는지 확인합니다.

  • 프로덕션 구성 가이드라인에 따라 mongos 라우터를 배포합니다.

  • NTP를 사용하여 샤딩된 클러스터의 모든 구성 요소의 시계를 동기화합니다.

  • mongod, mongos 및 config 서버 간의 완전한 양방향 네트워크 연결을 보장합니다.

  • CNAME을 사용하여 클러스터에 대한 config 서버를 식별하면 가동 중지 시간 없이 구성 서버의 이름을 바꾸고 번호를 다시 지정할 수 있습니다.

저널링: WiredTiger 스토리지 엔진

  • 모든 인스턴스가 저널링을사용하도록 합니다.

  • 쓰기 집약적인 워크로드를 위해 지연 시간이 짧은 자체 디스크에 저널을 배치하세요. 데이터베이스 상태를 구성하는 파일이 별도 볼륨에 상주하므로 이는 스냅샷 스타일 백업에 영향을 미칩니다.

하드웨어

  • 최적의 성능을 위해 RAID10 및 SSD 드라이브를 사용하세요.

  • SAN 및 가상화:

    • 각 mongod에 dbPath에 대해 프로비저닝된 IOPS가 있거나 자체 물리적 드라이브 또는 LUN이 있는지 확인합니다.

    • 가상 환경에서 실행하는 경우 메모리 벌루닝과 같은 동적 메모리 기능을 사용하지 않도록 합니다.

    • SAN은 단일 실패 지점이 될 수 있으므로 모든 복제본 세트 구성원을 동일한 SAN에 배치하지 않도록 합니다.

클라우드 하드웨어에 배포

  • Windows Azure: TCP 킵얼라이브(tcp_keepalive_time)를 100~120으로 조정합니다. Azure 부하 분산 장치의 TCP 유휴 시간 제한이 MongoDB의 연결 풀링 동작에 비해 너무 느립니다. 자세한 내용은 Azure 프로덕션 정보를 참조하세요.

  • Windows Azure와 같이 지연 시간이 긴 스토리지가 있는 시스템에서는 MongoDB 버전 2.6.4 이상을 사용하세요. 이 버전에는 해당 시스템에 대한 성능 개선 사항이 포함되어 있습니다.

운영 체제 구성

리눅스

  • Transparent Huge Pages를 끕니다. 자세한 내용은 Transparent Huge Pages 설정을 참조하세요.

  • 데이터베이스 파일을 저장하는 장치에서 미리 읽기 설정을 조정합니다.

    • 테스트 결과 더 높은 미리 읽기 값에서 측정 가능하고 반복 가능한 확실한 이점이 확인되지 않는 한 WiredTiger 스토리지 엔진은 스토리지 미디어 유형(회전 디스크, SSD 등)에 관계없이 8에서 32 사이의 미리 읽기 값을 설정합니다.

      MongoDB 상용 지원팀 에서 대체 리드헤드 구성에 대한 조언과 지침을 제공할 수 있습니다.

  • RHEL/CentOS에서 tuned을(를) 사용하는 경우 tuned 프로필을 사용자 지정해야 합니다. RHEL/CentOS와 함께 제공되는 많은 tuned 프로필은 기본 설정을 사용할 경우 성능에 부정적인 영향을 미칠 수 있습니다. 선택한 tuned 프로필을 다음과 같이 사용자 지정합니다:

    • Transparent Huge Pages를 비활성화합니다. 자세한 내용은 tuned 및 ktune 사용을 참조하십시오.

    • 저장 미디어 유형에 관계없이 리드헤드를 8~32로 설정합니다. 자세한 내용은 리드헤드 설정을 참조하세요.

  • SSD의 경우 cfq 또는 deadline 디스크 스케줄러를 사용합니다.

  • 게스트 VM의 가상화된 드라이브에 cfq 디스크 스케줄러를 사용합니다.

  • NUMA를 비활성화하거나 vm.zone_reclaim_mode를 0으로 설정하고 노드 인터리빙을 사용하여 mongod 인스턴스를 실행합니다. 자세한 내용은 MongoDB 및 NUMA 하드웨어를 참조하세요.

  • 사용 사례에 맞게 하드웨어의 ulimit 값을 조정합니다. 동일한 사용자로 여러 개의 mongod 또는 mongos 인스턴스를 실행 중인 경우 ulimit 값을 적절히 조정합니다. 자세한 내용 은 자체 관리 배포서버를 위한 UNIX ulimit 설정을 참조하세요.

  • dbPath 마운트 지점에 noatime을 사용합니다.

  • 배포서버에 충분한 파일 핸들(fs.file-max), 커널 pid 제한(kernel.pid_max), 프로세스당 최대 스레드(kernel.threads-max), 프로세스당 최대 메모리 맵 영역(vm.max_map_count)을 구성합니다. 대규모 시스템의 경우 다음 값이 좋은 출발점이 될 수 있습니다.

    • fs.file-max 98000

    • kernel.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 윈도우 (oplog window)

    • 어설션(assertions)

    • 큐

    • 페이지 오류

  • 서버의 하드웨어 통계를 모니터링합니다. 특히 디스크 사용량, CPU 및 사용 가능한 디스크 공간에 주의를 기울입니다.

    디스크 공간 모니터링이 없는 경우 또는 예방 조치로는 다음을 수행하세요.

    • storage.dbPath 드라이브에 4GB의 더미 파일을 만들어 디스크가 가득 차면 사용 가능한 공간을 확보하세요.

    • 다른 모니터링 도구를 사용할 수 없는 경우 cron+df 조합을 사용하면 디스크 공간이 최고 수위점에 도달할 때 경고를 보낼 수 있습니다.

부하 분산

  • 로드 밸런서를 구성하여 기존 연결에 충분한 시간 제한을 두고 'Sticky Sessions' 또는 '클라이언트 선호도'를 사용하도록 설정합니다.

  • MongoDB 클러스터 또는 복제본 세트 구성 요소 사이에 로드 밸런서를 배치하지 않도록 합니다.

보안

MongoDB 설치를 보호하기 위한 보안 조치 목록은 MongoDB 보안 체크리스트를 참조하세요.

돌아가기

프로덕션 정보

다음

개발 체크리스트

이 페이지의 내용