MongoDB Sharding(Shards, Config server, Mongos)

이전에 MongoDB의 사딩에 대해서 알아보았다.

 

이번에는 MongoDB 샤딩 클러스터의 요소인 Shards, Config server, Mongos에 대해 자세히 알아보겠다.

 

 

Sharding

샤드는 샤드 클러스터에서 샤드 데이터의 집합이라고 할 수 있다. 

각 샤드에 대한 관리는 샤드에 직접 연결하여야 하는데, 단일 샤드에 쿼리 작업을 수행하면 해당 샤드의 데이터만 반환이 된다.

만약, 클러스터단의 작업을 수행하려면 mongos에 연결하여 읽기와 쓰기 작업을 해야한다.

 

기본적으로 샤딩을 위해서는 2개 이상의 샤드가 필요하다. 

2개 이상의 샤드를 이용하기 위해서는 라우터가 필요하다. 라우터는 고가용성과 확장성을 확보할 수 있는데, 일반적으로 각 응용프로그램 서버에 라우터(Mongos)를 배치하여 사용한다. 

 

각 애플리케이션 서버에 Mongos를 배치하면 애플리케이션과 라우터 사이의 대기시간을 줄일 수 있다는 이점이 있다.

 

다른 방법으로는 전용 호스트에 mongos를 배치할 수 있는데, 이는 대규모 배포에 유용하게 적용된다.

대규모 배포에서 애플리케이션은 mongos 인스턴스의 수를 애플리케이션의 서버의 수와 분리 할 수 있기 때문에 연결을 효과적으로 제어할 수 있다.

 

개발과 테스트시에 아래와 같이 최소한의 구성으로 클러스터를 배포할 수 있다.

 

- 하나의 config server

- replica set 역할을 하는 하나 이상의 샤드

- 하나의 mongos 인스턴스

 

Config server

config server의 기능을 조금 더 샬펴보면, config server는 샤딩 클러스터의 메타데이터 즉, 클러스터 내의 모든 데이터 및 구성 요소에 대한 상태를 저장한다. 또한, Chunk에 대한 정보와 엑세스 제어 및 클러스터 내부 인증 설정도 저장한다.

 

Mongos는 이 config server의 데이터를 캐시하고, 읽기 및 쓰기작업을 위한 라우팅으로 할용한다.

 

Mongos

위에서 설명하듯, config server의 데이터를 이용하여 캐싱과 라우팅을 하는데, 기본적인 역할은 라우팅이 우선이다.

또한, 샤딩 클러스터를 사용할 때 응용프로그램은 샤드와 직접 연결되지 않으며 Mongos를 이용하여 데이터에 접근할 수 있다. 따라서 샤드 클러스터에 대한 유일한 인터페이스를 제공한다고 말할 수 있다. 

 

라우팅 프로세스는 다음과 같다.

 

1. 쿼리를 받아야하는 샤드 목록을 결정한다.

2. 대상이 되는 모든 샤드에 커서를 설정한다. 

 

다음으로 Mongos는 대상 샤드의 데이터를 병합하고 결과 문서를 리턴한다.

만약, 정렬과 같은 특정 쿼리에 대해서는 mongos가 결과를 검색하기 전에 먼저 샤드에서 수행을 한다.