MongoDB Sharded Cluster

이번 포스트에서는 MongoDB 의 Sharded Cluster 배포 형태에 대해 알아보겠다.

 

사용 목적

Sharded Cluster 의 사용 목적은 다음 상황에 적절하다...

기존에 Replica Set 을 잘 이용하고 있다가..

서비스가 잘 커서 MongoDB 에 많은 양의 데이터가 추가 되어

더이상 감당 할 수 없게 되었다..

이 때, Sharding 을 통해 데이터를 샤드 키로 분산하여

여러개의 Replica Set 묶음으로 적재 할 수 있도록 할 수 있다.

 

 

아래 그림을 통하여 더 자세히 알아보도록 하자..

위 그림은 대표적인 MongoDB 의 Sharded Cluster 형태를 나타낸다.

각 샤드는 내부에서 Replica Set 을 이루고 있다.

 

Application 은 mongos 라는 라우터를 통해 데이터에 접근 할 수 있다.

mongos 는 쿼리를 샤드로 전달하고 결과를 merge 하여 application 에게 반환 해준다.

 

Config Server 는 어떤 샤드가 어떤 데이터를 가지고 있는지.. 클러스터 상태는 어떤지.. 등을 가지고 있는

메타 데이터를 소유하는 컴포넌트이다.

Config Server 또한 Replica Set 형태를 가진다.

 

데이터를 분산하는 기준을 샤드 키라 부르며

샤드 키는 Collection 의 필드에 생성된 인덱스를 이용하여 활성화 된다.

따라서, 컬렉션 단위로 샤딩이 되는 것이다.

(물론, Sharded Cluster 형태라고 하여도.. 모든 컬렉션이 무조건 샤딩이 될 필요는 없다.(선택))

 

Sharded Cluster 장단점

장점

대용량 데이터를 분산 할 수 있다. (데이터 관점의 Scale-Out)

내부적으로 Replica Set 의 형태로 되어있어서 HA 가 보장된다.

 

단점

데이터가 분산되어 있어서 Replica Set 에 비교하여 조회가 느릴 수 있다.

-> 조회 시, Config Server 의 메타 정보를 이용해야 하며..

-> 여러 샤드에 걸친 데이터는 합치는 작업이 추가가 될 것이고.. 등등의 부가작업이 존재

 

결국..

Write 성능(대 용량 처리)를 위해서 Read 성능을 포기 한 것으로 볼 수 있다..

역시, 모든 것은 Read/Write Trade-Off 이다.

(실무에서 대부분의 경우.. Replica Set 을 선택한다..)

 

 

Sharding Strategy 2가지

1. Ranged Sharding

샤드 키 값을 바탕으로 청크 범위를 할당하는 방식이다.

즉, 데이터를 샤드에 분배하는데 샤드 키 값을 그대로 사용하는 방법이다.

 

참고>

MongoDB는 샤드 키를 기반으로 데이터를 청크라는 단위로 분할한다.

각 청크는 특정 범위의 샤드 키 값을 포함한다.(1~1000, 1001~2000)

청크는 샤딩된 데이터베이스에서 데이터를 관리하는 데 사용되는 논리적 단위이다.

하나의 샤드에는 여러 개의 청크가 있을 수 있다.

하나의 샤드에 너무 많은 청크가 몰려있다면 리벨런싱을 통해 청크를 다른 샤드로 이동 시킬 수 있다.

 

장점

데이터의 범위가 정해져있으므로

데이터가 있는 샤드에만 쿼리를 요청하는 타겟 쿼리가 가능해진다.

 

단점

데이터가 균형있게 분산되지 않을 가능성이 높다.

(실제 데이터의 분산은 균형잡혀 있지 않을 가능성이 높다.)

-> 그래서, 자체적으로 다른 샤드로 데이터를 넘기는 분산 마이그레이션을 하는데 부하가 크다.

 

2. Hashed Sharding

실무에서 가장 많이 사용되는 방법이다.

샤드 키의 해시 값을 기반으로 데이터를 분배하는 방법이다.

데이터를 균등하게 분산할 확률이 높은 방법이다.

키의 순서를 유지하지 않기 때문에 범위 쿼리 시, Broadcast 쿼리를 많이 날리게 된다..

 

3.

Zone 기반 샤딩, Directory 기반 샤딩 전략 등은 자주 쓰이지 않으므로..

생략 하겠다.