[MongoDB] MongoDB 배포 형태

Real MongoDB의 책 내용 중 일부를 정리한 내용입니다. http://www.yes24.com/Product/Goods/58142119

1. 단일 노드 (Standalone 형태)

구성 요소

• 아무런 관리용 컴포넌트가 필요하지 않다.

특징 및 한계점

• 복제를 위한 로그(OpLog)를 별도로 기록하지 않으며, 다른 노드와의 통신도 필요하지 않음.
• Application의 MongoDB 드라이버가 MongoDB 서버로 직접 연결하게 되며, 별도의 레플리카 셋을 가지지 않으므로 MongoDB 서버가 응답 불능 상태라 하더라도 자동 페일오버나 HA 기능이 작동할 수 없음.

2. 단일 레플리카셋 (Simple Replica-set)

구성 요소

• 단일 레플리카 셋에서도 별도의 관리용 컴포넌트가 필요하지 않지만, 레플리카 셋의 구축을 위해 추가로 MongoDB 서버가 필요.
• 레플리카 셋은 특정 서버에 장애가 발생했을 때, 자동 복구를 위한 최소 단위이므로 자동 복구가 필요하다면 항상 레플리카 셋으로 MongoDB를 배포해야 한다.
• MongoDB 드라이버는 직접 MongoDB 서버로 접속하지만, 단일 노드로 접속할 때와 달리 레플리카 셋 옵션을 사용해야 한다.

프라이머리 노드와 세컨더리 노드의 차이점

• 레플리카 셋에는 항상 하나의 프라이머리 노드와 1개 이상의 세컨더리 노드로 구성되며, 프라이머리 노드는 사용자의 데이터 변경 요청을 받아서 처리하고, 세컨더리 노드는 프라이머리 노드로부터 변경 내용을 전달받아서 서로의 데이터를 동기화한다.
• 읽기 쿼리는 프라이머리 노드뿐만 아니라 필요하면 세컨더리 노드로 요청할 수도 있다.

프라이머리 노드 선출 방식으로 레플리카셋은 홀수 개로 구성하는 것이 좋다.

• MongoDB 레플리카 셋은 항상 레플리카 셋에 포함된 노드 간 투표를 통해서 프라이머리 노드를 결정하므로, 가능하면 홀수 개의 노드로 구성하는 것이 좋다. (짝수 개의 노드로 레플리카 셋을 구축할 수도 있지만, 서버의 낭비를 유발함 → 예를 들어 3대인 경우, 1대의 노드의 장애까지 허용하는데, 레플리카 셋을 4대로 구축해도 역시 1대의 노드까지의 장애만 허용한다. (과반수 이상 통신 할 수 있는 상태여야만 투표를 실행할 수 있어서)

아비터 모드

• 레플리카 셋을 3대의 서버로 구축하는 것은 떄로는 서버의 낭비로 보일 수도 있는데, 이런 경우 MongoDB 서버를 아비터 모드로 실행할 수도 있다.
  • 아비터 모드로 시작된 MongoDB는 레플리카 셋의 노드들과 하트 비트만 주고받으며, 프라이머리 노드가 불능일 때, 프라이머리 노드의 선출에만 참여한다.
  • 아비터 노드는 로컬 디스크에 데이터를 저장하지 않고, 프라이머리로부터 데이터를 주고받지 않기 때문에 고 사양의 장비가 필요하지 않고, 이러한 이유로 프라이머리 노드로 선출될 수도 없다.

 

3. 샤딩된 클러스터 (Sharded Cluster)

구성 요소

• 샤딩된 클러스터 구조에서는 하나 이상의 레플리카 셋이 필요하며, 각 레플리카 셋은 자신만의 파티션 된 데이터를 가지게 된다.

Config Server

• 샤딩된 클러스터에 참여하고 있는 각각의 레플리카 셋을 샤드라고 하는데, 이 샤드들이 어떤 데이터를 가지는지에 대한 정보는 MongoDB Config 서버가 관리한다.

mongos

• 샤딩된 클러스터 구조에서는 Application MongoDB Driver가 직접 MongoDB 서버로 연결하도록 해서는 안되고, MongoDB 라우터(mongos)로 연결하고 MongoDB 라우터는 자동으로 Config 서버로부터 각 샤드가 갖고 있는 데이터에 대한 메타 정보들을 참조하여 쿼리를 실행한다.
• 사용자로부터 요청된 쿼리를 실제 데이터를 가지고 있는 샤드로 전달하는 역할을 수행.
• 사용자를 대신하여 모든 샤드로 쿼리를 요청하고 결과를 정렬 및 병합해서 반환하는 처리도 수행.
• 각 샤드간의 데이터가 재분배되는 시점에도 동일한 역할을 수행하여, 투명하게 데이터 밸런싱 작업을 처리한다.