이 문서에 설명 된 모범 사례에 대해 질문하고 싶습니다.

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

여러 쿼리 라우터를 사용하십시오. 여러 서버에 분산 된 여러 몽고 프로세스를 사용하십시오. 일반적인 배포는 응용 프로그램과 몽고 프로세스 간의 로컬 통신을 허용하는 응용 프로그램 서버에 몽고 프로세스를 배치하는 것입니다. 적절한 수의 몽고 프로세스는 응용 프로그램 및 배포의 특성에 따라 다릅니다.

배포에 대한 배경 지식이 조금 있습니다. 우리는 많은 애플리케이션 서버 노드를 가지고 있습니다. 각각은 상태 비 저장 RESTful WS를 사용하여 하나의 JVM 기반 프로세스를 실행합니다. 이 모범 사례에서 알 수 있듯이 모든 단일 애플리케이션 서버 노드는 자체 mongos프로세스를 실행합니다. 즉, JVM 프로세스 수는 항상 mongos프로세스 수와 같습니다 .

모든 mongos프로세스는 3 개의 구성 서버와 여러 개의 몽고 샤드 (각 샤드 내에 복제 세트가 있음)에 연결됩니다. 샤드 배포를 사용하더라도 실제로 컬렉션을 샤딩하지는 않습니다. 실제로 우리는 생성 시간 동안 모든 샤드에 걸쳐 분산 된 많은 데이터베이스를 보유하고 있습니다 (현재 샤딩의 주요 사용 사례입니다).

모범 사례는 "적절한 수의 몽고 프로세스가 응용 프로그램 및 배포의 특성에 따라 달라질 것"이라고 제안하기 때문에 사용 방법 mongos이 실제로 적절한 지 또는 여러 전용 mongos노드 를 갖는 것이 더 나은지 궁금해지기 시작했습니다. 앱 서버는 mongos로컬로 실행 하지 않고도 서버에 연결 됩니다.

mongos애플리케이션 서버 인스턴스 수 또는 MongoDB 클러스터 크기와 관련하여 적절한 인스턴스 수 를 결정하는 가장 좋은 방법에 대한 귀하의 의견은 무엇입니까 ?

최근에 우리는 Stateless 웹 서비스에 대한 클러스터 관리를 조사하기 시작했습니다. 즉, Docker, Apache Mesos 및 Kubernetes와 같은 도구를 의미합니다. Docker를 사용하는 경우 일반적으로 컨테이너 내에서 둘 이상의 프로세스를 실행하는 것이 좋습니다. 이러한 사실을 고려할 때 응용 프로그램 서버 컨테이너와 mongos컨테이너가 항상 동일한 물리적 노드에 같은 위치에 있고 동일한 양의 프로세스를 갖도록 하는 것은 실제로 어렵습니다 . 이 모범 사례가 방금 설명한 클러스터 아키텍처에 여전히 적용되는지 궁금합니다. 그렇지 않다면 mongos이 아키텍처에서 프로세스 를 찾고 배포하는 더 좋은 방법이 무엇인지 제안 해 주 시겠습니까?

이미 답변이 제출되어 있고 그에 유용하고 유효한 답변이 있기 때문에 나는 그 자체의 유용성을 방해하고 싶지 않지만 실제로는 짧은 의견을 넘어서서 제기해야 할 요점이 있습니다. 따라서이 "증강"을 고려하십시오. 이는 희망적으로 유효하지만 주로 이미 언급 된 내용에 추가됩니다.

진실은 "응용 프로그램이 데이터를 사용하는 방법"을 실제로 고려하고 "샤딩 된 환경"의 요인과 이에 영향을주는 제안 된 "컨테이너 환경"을 인식하는 것입니다.

배경 사례

mongos응용 프로그램 인스턴스와 함께 프로세스를 함께 배치하기위한 일반적인 권장 사항 은 응용 프로그램이 해당 mongos프로세스 와 통신하는 데 필요한 네트워크 오버 헤드를 방지하는 것입니다. 물론 mongos어떤 이유로 "가장 가까운"노드를 사용할 수없는 경우 다른 연결을 선택할 수있는 경우 응용 프로그램 연결 문자열에 여러 인스턴스 를 지정하는 것이 "권장 사례" 입니다. 원격 노드.

언급 한 "docker"사례는 다소 임의적 인 것으로 보입니다. 컨테이너의 주요 목표 중 하나 (및 그 이전의 BSD jails 또는 chroot)가 일반적으로 일정 수준의 "프로세스 격리"를 달성하는 것이 사실이지만, 여러 프로세스를 실행하는 데 실제로 아무런 문제가 없습니다. 그 의미를 이해하십시오.

이 특정한 경우에, mongos이는 "경량"이고 응용 프로그램 자체의 "쌍"부분 인 방식으로 응용 프로세스에 대한 "추가 기능"으로서 실행되도록 의도된다. 따라서 도커 이미지 자체에는 프로세스와 같은 "초기화"가 없지만 컨테이너의 기본 프로세스로 supervisord (예 :)와 같은 프로세스 컨트롤러를 실행하는 데 실제로 아무런 문제가 없습니다. 그 컨테이너도. "페어링 된 프로세스"의 이러한 상황은 합리적인 경우이며 공식적인 문서가 필요하다는 것은 일반적입니다.

배포를 위해 이러한 "페어링 된"작업을 선택한 경우 실제로 mongos는 동일한 네트워크 연결 및 실제로 "서버 인스턴스"에서 응용 프로그램 서버와 같은 인스턴스를 유지 관리하는 주요 지점을 처리 합니다. 또한 "전체 컨테이너"가 실패한 경우 해당 노드 자체가 단순히 유효하지 않은 경우로 볼 수도 있습니다. 권장하지는 않으며 실제로 mongos대기 시간을 늘리는 네트워크 연결을 통해서만 액세스 할 수있는 경우에도 다른 인스턴스 를 찾도록 연결을 구성해야합니다 .

버전 별 / 용도별

이제 그 시점이 결정되었으므로 여기서 다른 고려 사항은 mongos네트워크 대기 시간 목적으로 프로세스를 응용 프로그램과 함께 배치하는 초기 고려 사항으로 돌아갑니다 . 2.6 이전의 MongoDB 버전 및 특히 집계 프레임 워크와 같은 작업과 관련하여 mongos다른 샤드의 데이터를 처리하기위한 프로세스에서 수행 한 처리 작업 이후에 훨씬 더 많은 네트워크 트래픽이 발생하는 경우가있었습니다. . 이제 "라우터"로 "증류"하기 전에 이러한 샤드 자체에 대해 상당한 양의 처리 워크로드를 수행 할 수 있기 때문에 지금은 그렇지 않습니다.

다른 경우는 샤딩과 관련된 응용 프로그램 사용 패턴 자체입니다. 이는 기본 워크로드가 여러 샤드에 "쓰기를 분배"하고 있는지 또는 실제로 읽기 요청을 통합 할 때 "분산 수집"방식인지를 의미합니다. 이러한 시나리오에서

테스트, 테스트 및 다시 테스트

따라서 여기서의 마지막 요점은 스스로 설명하는 것이며 질문에 대한 제정신의 기본적인 합의에 이릅니다. 이것은 MongoDB 또는 다른 스토리지 솔루션에 새로운 것은 아니지만 실제 배치 환경은 핵심 구성 요소에서 예상되는 기능의 "단위 테스트"만큼이나 실제 환경에 가까운 "사용 패턴"에서 테스트해야합니다. 전체 결과 를 테스트 해야 합니다.

실제로 "이 방법으로 구성"또는 "이 방법으로 사용"이라고 말하는 "결정적인"진술은 실제로 예상대로 애플리케이션 성능 및 안정성에 대해 "실제로 가장 잘 작동하는"테스트와는 의미가 없습니다.

물론 "최상의 경우"는 항상 mongos"다수"응용 프로그램 서버 소스의 요청으로 인스턴스를 "군집"하지 않는 것입니다. 그런 다음 선택할 수있는 "자원 풀"을 "최소"로 유지하는 데 사용할 수있는 자원 워크로드에 의해 분배 될 수있는 자연스러운 "패리티"를 허용하기 위해, 실제로는 많은 경우에 이상적이지만 추가를 유도 할 필요는 없습니다 "네트워크 전송 오버 헤드".

이것이 목표이지만 이상적으로는 최종 배포 솔루션에 "최적의"솔루션을 제공하기 위해 다양한 인식 된 구성을 "실험실 테스트"할 수 있습니다.

또한 여러분의 지식 수준에 관계없이 이미 언급 한대로 "무료"(맥주 에서처럼) 과정을 강력히 추천합니다. 다양한 강의 자료 소스가 종종 "숨겨진 보석"을 제공하여 고려하지 않았거나 간과하지 않은 것들에 대한 통찰력을 제공합니다. M102 클래스 구성에 의해 실시 된 바와 같이 아담 Commerford 누구 내가 할 수있는 위해는 증명하여 MongoDB의 대규모 배포 및 다른 데이터 구조에 대한 지식의 높은 수준을 가지고있다. 적어도 당신이 이미 알고 있다고 생각하는 것에 대한 신선한 관점을 고려할 가치가 있습니다.

모범 사례는 "적절한 수의 몽고 프로세스가 응용 프로그램 및 배포의 특성에 달려 있음"을 제안하기 때문에 몽고 사용이 실제로 적절한 지 궁금해하기 시작했습니다.

나는 이것이 문서가 말하는 것처럼 궁극적으로 당신 만 대답 할 수있는 질문이라고 생각합니다.

권장되는 전략 중 하나는 mongos각 응용 프로그램 노드에 서비스를 제공하고 추가 가용성을 위해 추가 전용 노드를 제공하는 것입니다. 현재 이것을 가지고 있으므로 현재 배포에 아무런 문제가 없습니다. 아키텍처에서 변화가 없다면 현재 모범 사례 내에 있습니다. 하나...

Docker를 사용하는 경우 일반적으로 컨테이너 내에서 둘 이상의 프로세스를 실행하는 것이 좋습니다.

이후 mongos과정은 매우 리소스를 많이하지 않습니다, 당신은 또한 당신의 파편 각각의 인스턴스를 넣어 각각하도록 할 수 있습니다 mongod노드는 또한 역할 mongos노드입니다. 응용 프로그램 서버 아키텍처를 약간 더 복잡하게 만들면 더 의미가있을 수 있습니다.

개인적으로 이러한 제품에 익숙하지는 않지만 mongos나란히 실행할 수있는 대부분의 다른 프로세스보다 집중력이 떨어질 수 있으므로 해당 공급 업체의 권장 사항을 확인합니다 .

마지막으로, mongos규모, 자원 등에 따라 프로세스에 전용 노드를 사용하여 모범 사례에 속할 수도 있습니다. 여기서 실제로 취하는 것은 어딘가에mongos 프로세스가 많으면 잘하고 있다는 것입니다.

그래도 배포 규모와 SLA 요구 사항에 따라 달라지는 수는 얼마입니까? 샤드를 사용하면 충분할 것입니다. 그러나 전용 노드를 사용하려는 경우 가능한 한 많은 응용 프로그램 노드 수를 일치 시키려고합니다.

이 주제를 다루는 MongoDB M102 온라인 코스 에서이 비디오를 확인할 수 있으며 다음 번 세션에있을 때 (무료, 온라인) DBA 용 M102 클래스에 등록하려고 할 수 있습니다 .