mongodb 서비스 구성

노트북에서 MongoDB를 사용해 보고 싶으신가요? 명령을 실행하기만 하면 가볍고 독립적인 샌드박스가 생성됩니다. 완료되면 수행한 작업에 대한 모든 흔적을 삭제할 수 있습니다.

여러 환경에서 동일한 애플리케이션 스택 복사본을 사용하고 싶으십니까? 자체 컨테이너 이미지를 구축하고 개발, 테스트, 운영 및 지원 팀이 동일한 환경 복제본을 사용할 수 있도록 하세요.

컨테이너는 초기 기술 실험 및 개념 증명부터 개발, 테스트, 배포 및 지원에 이르기까지 전체 소프트웨어 수명 주기에 혁명을 일으키고 있습니다.

오케스트레이션 도구는 여러 컨테이너를 생성, 업그레이드하고 가용성을 높이는 방법을 관리하는 데 사용됩니다. 또한 오케스트레이션은 여러 마이크로서비스 컨테이너에서 복잡한 애플리케이션을 구축하기 위해 컨테이너가 연결되는 방식을 제어합니다.

다양한 기능, 간단한 도구, 강력한 API 덕분에 컨테이너 및 오케스트레이션 기능은 DevOps 팀이 CI(지속적 통합) 및 CD(지속적 전달) 워크플로에 통합하려는 첫 번째 선택이 됩니다.

이 문서에서는 컨테이너에서 MongoDB를 실행하고 조정할 때 직면하게 되는 추가 과제를 살펴보고 이를 극복하는 방법을 설명합니다.

컨테이너 및 오케스트레이션을 사용하여 MongoDB를 실행하는 경우 몇 가지 추가 고려 사항이 있습니다.

MongoDB 데이터베이스 노드는 상태 저장형입니다. 컨테이너가 실패하고 일정이 변경되면 데이터가 손실되므로(복제본 세트의 다른 노드에서 복구할 수 있지만 시간이 소요됨) 이는 바람직하지 않습니다. 이 문제를 해결하려면 Kubernetes의 볼륨 추상화와 같은 기능을 사용하여 컨테이너의 임시 MongoDB 데이터 디렉터리를 영구 위치에 매핑하여 데이터가 컨테이너 오류 및 일정 변경 프로세스에서 살아남도록 할 수 있습니다.
복제본 세트의 MongoDB 데이터베이스 노드는 일정 변경 이후를 포함하여 서로 통신할 수 있어야 합니다. 복제본 세트의 모든 노드는 모든 피어의 주소를 알아야 하지만 컨테이너가 다시 예약되면 다른 IP 주소로 다시 시작될 수 있습니다. 예를 들어 Kubernetes Pod의 모든 컨테이너는 IP 주소를 공유하며 Pod가 재구성되면 IP 주소가 변경됩니다. Kubernetes를 사용하면 Kubernetes 서비스를 각 MongoDB 노드와 연결하여 이를 처리합니다. 이는 Kubernetes DNS 서비스를 사용하여 "호스트 이름"을 제공하여 재조정 시에도 서비스를 변경하지 않고 유지합니다.
각 개별 MongoDB 노드가 실행되면(각각 자체 컨테이너에서) 복제본 세트를 초기화하고 각 노드를 여기에 추가해야 합니다. 이를 위해서는 오케스트레이션 도구 외부에서 몇 가지 추가 처리가 필요할 수 있습니다. 특히 rs.initiate 및 rs.add 명령을 실행하려면 대상 복제본 세트의 MongoDB 노드를 사용해야 합니다.
오케스트레이션 프레임워크가 컨테이너(예: Kubernetes)의 자동 재조정을 제공하는 경우 실패한 복제본 세트 구성원이 자동으로 다시 생성될 수 있으므로 MongoDB의 탄력성이 향상되어 사람의 개입 없이 전체 중복성 수준을 복원할 수 있습니다.
오케스트레이션 프레임워크는 컨테이너의 상태를 모니터링할 수 있지만 컨테이너 내부에서 실행되는 애플리케이션을 모니터링하거나 해당 데이터를 백업할 가능성은 거의 없습니다. 이는 MongoDB Enterprise Advanced 및 MongoDB Professional에 포함된 MongoDB Cloud Manager와 같은 강력한 모니터링 및 백업 솔루션을 사용하는 것이 중요하다는 것을 의미합니다. 선호하는 MongoDB 버전과 MongoDB 자동화 에이전트가 포함된 자체 이미지를 생성해 보세요.

이전 섹션에서 언급했듯이 분산 데이터베이스(예: MongoDB)는 오케스트레이션 프레임워크(예: Kubernetes)를 사용하여 배포할 때 약간의 주의가 필요합니다. 이 섹션에서는 이를 달성하는 방법을 자세히 설명합니다.

단일 Kubernetes 클러스터(일반적으로 지리적 중복성을 제공하지 않는 데이터 센터 내)에서 전체 MongoDB 복제본 세트를 생성하는 것부터 시작합니다. 실제로는 여러 클러스터에서 실행되도록 변경할 필요가 거의 없으며 이러한 단계는 나중에 설명됩니다.

레플리카 세트의 각 구성원은 자체 포드로 실행되며 노출된 IP 주소와 포트로 서비스를 제공합니다. 이 "고정" IP 주소는 외부 애플리케이션과 다른 복제본 세트 구성원 모두 포드 일정 변경 시 변경되지 않은 상태로 유지될 수 있기 때문에 중요합니다.

아래 이미지는 포드 중 하나와 관련 복제 컨트롤러 및 서비스를 보여줍니다.

그림 1: Kubernetes Pod로 구성되고 서비스로 노출되는 MongoDB 복제본 세트 멤버
그림 1: Kubernetes Pod로 구성되고 서비스로 노출되는 MongoDB 복제본 세트 멤버
이 구성에 설명된 리소스에 대한 단계별 소개:

코어부터 시작하면 mongo-node1이라는 컨테이너가 있습니다. mongo-node1에는 Docker Hub에서 호스팅되는 공개적으로 사용 가능한 MongoDB 컨테이너 이미지인 mongo라는 이미지가 포함되어 있습니다. 컨테이너는 클러스터의 포트 27107을 노출합니다.
Kubernetes의 데이터 볼륨 기능은 커넥터의 /data/db 디렉터리를 mongo-pertant-storage1이라는 영구 저장소에 매핑하는 데 사용되며, 이 영구 저장소는 다시 Google Cloud에서 생성된 mongodb-disk1이라는 디스크에 매핑됩니다. MongoDB가 컨테이너를 다시 조정한 후에도 유지되도록 데이터를 저장하는 곳입니다.
컨테이너는 mongo-node라는 라벨과 Rod라는 (임의의) 예시가 있는 Pod에 보관됩니다.
mongo-node1 포드의 단일 인스턴스가 항상 실행되도록 mongo-node1 복제 컨트롤러를 구성합니다.
mongo-svc-a라는 로드 밸런싱 서비스는 IP 주소와 포트 27017을 외부에 개방하며, 이는 컨테이너의 동일한 포트 번호에 매핑됩니다. 이 서비스는 선택기를 사용하여 포드 레이블을 일치시켜 올바른 포드를 결정합니다. 외부 IP 주소와 포트는 애플리케이션과 복제 세트 구성원 간의 통신에 사용됩니다. 각 컨테이너에는 로컬 IP 주소도 있지만 컨테이너가 이동되거나 다시 시작되면 이러한 IP 주소가 변경되므로 복제본 세트에 사용되지 않습니다.
다음 다이어그램은 복제 세트의 두 번째 구성원의 구성을 보여줍니다.

그림 2: Kubernetes Pod로 구성된 두 번째 MongoDB 복제본 세트 멤버
그림 2: Kubernetes Pod
로 구성된 두 번째 MongoDB 복제본 세트 멤버 구성의 90%는 동일하며 다음 변경 사항만 있습니다:

디스크 및 볼륨 이름은 고유해야 하므로 mongodb-disk2 및 mongo-pertant-storage2가 사용됩니다
Pod에는 인스턴스: jane 및 이름: mongo-node2라는 라벨이 할당되므로 선택기를 사용하여 그림 1에 표시된 로드 Pod와 새 서비스를 구별할 수 있습니다.
복사 컨트롤러의 이름은 mongo-rc2
입니다. 서비스 이름은 mongo-svc-b이며 고유한 외부 IP 주소가 제공됩니다(이 경우 Kubernetes에는 104.1.4.5가 할당됨)
세 번째 복제본 구성원의 구성은 동일한 패턴을 따르며 아래 이미지는 전체 복제본 세트를 보여줍니다.

그림 3: Kubernetes 서비스로 구성된 전체 복제본 세트 구성원
그림 3: Kubernetes 서비스로 구성된 전체 복제본 세트 구성원
3개 이상의 노드로 구성된 Kubernetes 클러스터에서 그림 3에 표시된 구성을 실행하는 경우에도 Kubernetes는 동일한 호스트에서 2개 이상의 MongoDB 복제본 세트 구성원을 오케스트레이션할 수 있으며 종종 그렇게 합니다. 이는 Kubernetes가 세 개의 포드를 세 개의 별도 서비스에 속하는 것으로 취급하기 때문입니다.

영역 내 중복성을 추가하기 위해 추가 헤드리스 서비스를 생성할 수 있습니다. 새로운 서비스는 외부 세계에 어떤 기능도 제공하지 않지만(IP 주소도 없음) Kubernetes가 3개의 MongoDB 포드에 서비스를 형성하도록 알릴 수 있으므로 Kubernetes는 이를 다른 노드에서 조정하려고 시도합니다.

그림 4: 동일한 MongoDB 복제본 세트의 구성원을 피하는 헤드리스 서비스
그림 4: 동일한 MongoDB 복제본 세트의 구성원을 피하는 헤드리스 서비스
MongoDB 복제본 세트를 구성하고 실행하는 데 필요한 실제 구성 파일과 명령은 마이크로서비스 활성화: 컨테이너 및 오케스트레이션 설명 백서에서 찾을 수 있습니다. 특히 세 개의 MongoDB 인스턴스를 기능적이고 강력한 복제본 세트로 결합하려면 이 기사에 설명된 특수 단계 중 일부가 필요합니다.

위에서 생성된 복제본 세트는 모든 것이 동일한 GCE 클러스터에서 실행되고 따라서 동일한 가용성 영역에 있기 때문에 위험합니다. 주요 이벤트로 인해 가용 영역이 오프라인 상태가 되면 MongoDB 복제본 세트를 사용할 수 없게 됩니다. 지리적 중복이 필요한 경우 3개의 포드가 3개의 서로 다른 가용 영역 또는 지역에서 실행되어야 합니다.

놀랍게도 세 지역으로 분할된 유사한 복제본 세트를 생성하려면 변경 사항이 거의 필요하지 않았습니다(세 클러스터 필요). 각 클러스터에는 해당 복제본 세트의 한 멤버에 대해서만 Pod, 복제 컨트롤러 및 서비스를 정의하는 자체 Kubernetes YAML 파일이 필요합니다. 그런 다음 각 지역에 대한 클러스터, 영구 저장소 및 MongoDB 노드를 생성하는 것은 간단합니다.

그림 5: 여러 가용성 영역에서 실행되는 복제본 세트
그림 5: 여러 가용성 영역에서 실행되는 복제본 세트
다음 단계
컨테이너 및 오케스트레이션(관련 기술 및 이들이 제공하는 비즈니스 이점)에 대해 자세히 알아보려면 마이크로서비스 활성화: 컨테이너 및 오케스트레이션 설명 백서를 읽어보세요. 이 문서에서는 이 문서에 설명된 복제본 세트를 가져와 Google Container Engine의 Docker 및 Kubernetes에서 실행하는 방법에 대한 전체 지침을 제공합니다.

작가 소개:

Andrew는 MongoDB의 제품 마케팅 총괄 관리자입니다. 그는 지난 여름 Oracle에서 MongoDB에 합류하여 고가용성에 중점을 둔 제품 관리 분야에서 6년 이상을 보냈습니다. @andrewmorgan이나 그의 블로그(clusterdb.com)에 댓글을 달아 그에게 연락할 수 있습니다.

위 내용은 mongodb 서비스 구성의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!