[MongoDB] Sharding (Shard, Config Server, Mongos)

1. Sharding

Shard는 Shard Cluster에서 Shard 데이터의 집합이라고 할 수 있다. 각 Shard에 대한 관리는 Shard에 직접 연결해야 하는데, 단일 Shard에 쿼리 작업을 수행하면 해당 Shard의 데이터만 반환 된다. 만약 클러스터단의 작업을 수행하려면 Mongos에 연결하여 읽기와 쓰기 작업을 해야한다.

 

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

 

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

 

다른 방법으로는 전용 호스트에 Mongos를 배치하면 애플리케이션과 라우터 사이의 대기시간을 줄일 수 있다는 이점이 있다. 대규모 배포에서 애플리케이션은 Mongos 인스턴스의 수를 애플리케이션의 서버의 수와 분리할 수 있기 때문에 연결을 효과적으로 제어할 수 있다.

 

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

• Config Server 1개
• Replica Set 역할을 수행하는 하나 이상의 Shard
• Mongos 인스턴스 1개

 

최소한의 구성

 

 

 

2. Config Server

Config Server는 Shard Cluster에서 사용자가 생성한 데이터베이스와 컬렉션들의 목록과 그 이외에도 많은 정보를 관리한다. 여기서 관리한다는 말은 모든 데이터베이스와 컬렉션의 목록을 관리하는 것이 아닌 Sharding이 활성화된 데이터베이스와 컬렉션의 정보만 관리한다.

 

Config Server의 데이터는 직접 로그인해서 확인할 수 있지만, 일반적으로 라우터(Mongos)를 이용하여 MongoDB Cluster에 로그인한 다음 Config 데이터베이스로 이동하면 필요한 데이터를 조회할 수 있다. 즉, 라우터의 Config 데이터베이스는 Shard 서버가 아닌 Config Server로 접속하여 결과를 가져오게 되며, 그 이외의 모든 사용자 데이터베이스와 컬렉션은 Shard 서버로 쿼리를 요청한다.

 

Config Server에는 버전마다 차이가 존재하지만 database, collections, chunks, shards, mongos, settings, version, lockpings, locks, changelog 컬렉션들은 모두 Config Server에만 저장된다.

 

다시 정리해서 말하자면, Config Server는 Sharding Cluster의 메타데이터, 즉, 클러스터 내의 모든 데이터 및 구성 요소에 대한 상태를 저장한다. 또한 Chunks에 대한 정보와 액세스 제어 및 클러스터 내부 인증 설정도 저장한다. Mongos는 이 Config Server의 데이터를 캐시하고 읽기 및 쓰기 작업을 위한 라우팅으로 활용한다.

 

 

 

3. Mongos

Mongos는 Config Server의 데이터를 이용하여 캐싱과 라우팅을 하는데, 기본적인 역할은 라우팅이 우선이다. 또한 Sharding Cluster를 사용할 때 응용프로그램은 Shard와 직접 연결되지 않으며 Mongos를 이용하여 데이터에 접근할 수 있다. 따라서 Shard Cluster에 대한 유일한 인터페이스를 제공한다고 말할 수 있다.

 

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

• 쿼리를 받아야하는 Shard 목록을 결정한다.
• 대상이 되는 모든 Shard에 커서를 설정한다.

이 후 Mongos는 대상 Shard 데이터를 병합하고 결과 문서를 반환한다. 만약 정렬과 같은 특정 쿼리에 대해서는 Mongos가 결과를 검색하기 전에 먼저 Shard에서 수행을한다.

---

[참고] junghwanta.tistory.com/42?category=857330