[MongoDB] Sharded Cluster

ReplicaSet 배포형태에 이어 분산을 위한 배포 형태인 Sharded Cluster에 대해 알아보자.

Sharded Cluster

 

용어부터 정리하면, 샤딩은 하나의 큰 데이터를 여러 장비에 걸쳐서 데이터를 분할하는 과정을 의미. 분할된 데이터셋의 모음을 샤드라고 한다. 분산이 되는 기준을 샤드키라고 하는데, 샤드키는 컬렉션의 필드에 생성된 인덱스를 이용해서 활성화한다.

각각 샤드는 레플리카셋으로도 관리 된다. "복제: for HA, 샤딩: for 분산처리(scale-out)"

장점

• 용량의 한계를 극복할 수 있다.
• 데이터 규모와 부하가 크더라도 처리량이 좋다.
• 고가용성을 보장한다.
• 하드웨어에 대한 제약을 해결할 수 있다.

단점

• 관리가 비교적 복잡하다.
• Replica Set과 비교해서 대체적으로 쿼리가 느리다.
• 요청이 들어왔을 때 어느 샤드에 가서 찾아야할지 라우팅해주는 시스템이 필요해서 추가적인 지연이 발생할 수 있다. 범위가 큰 데이터를 쿼리하는 경우에, 여러 샤드에 걸쳐서 데이터를 찾고 머지해서 다시 사용자한테 보여주기 때문에 단순한 쿼리는 오히려 더 오래 걸릴 수 있다.

Sharded Cluster는 대량으로 늘어나는 데이터를 저장하고, write에 대한 부하가 클 때 적합하다.

(Replica Set은 Secondary를 아무리 늘려도 write는 Primary 한대만 받기 때문이다.)

 

여기서 잠깐!
샤딩(Sharding)과 파티셔닝(Partitioning)의 차이를 알아보자

- Sharding: 하나의 큰 데이터를 여러 서브셋으로 나누어 여러 인스턴스에 저장하는 기술
- Partitioning: 하나의 큰 데이터를 여러 서브넷으로 나누어 하나의 인스턴스의 여러 테이블로 나누어 저장하는 기술

Sharding은 여러 장비로, Partitioning은 하나의 장비 아래 여러 테이블로 나누는 차이가 있다.

 

Sharded Cluster Arhitecture

https://www.mongodb.com/docs/manual/core/sharded-cluster-components/

Config Server

Sharded Cluster의 메타데이터를 소유하고 있는 컴포넌트다.

어떤 샤드가 어떤 데이터를 가지고 있는지나 클러스터의 상태 등 중요한 정보의 데이터를 들고 있어서 Config Server도 HA를 보장해주는 레플리카셋으로 구성되어 있다.

 

아키텍처에 따라 전체 흐름을 살펴보자

1. 사용자가 Client Driver를 통해서 Mongo 라우터(Mongos)에 요청하게 된다.
2. Mongos는 Config Server의 메타데이터 정보를 확인해서, 내가 찾으려고 하는 데이터를 어느 샤드에 요청해야할지 확인한다.
3. Mongos가 샤드에 직접 접근해서 필요한 데이터를 받아오고 merge에서 사용자에게 반환한다.

 

다음은 컬렉션 단위로 샤딩된 모습 표현한 그림이다. 분산을 컬렉션 단위로 할 수 있다.

Sharding Collection

일부 컬렉션에 대해서는 샤딩을 활성화하지 않고, 하나의 샤드에서만 관리되도록하는 것이 유리할 수 있다.

샤드 클러스터가 레플리카셋과 비교해서 느린데, 데이터가 분산되어 있어서 데이터를 각각 샤드에서 조회하고 머지하는 시간이 소요되기 때문이다. 만약에 서버에서 메타성 정보를 저장해야할 때 (데이터는 적고, 접근을 많이 할 때) 하나의 샤드에서만 관리하면 훨씬 더 좋은 성능을 낼 수 있다.

 

샤딩 전략

Ranged Sharding

샤드키의 값을 기준으로 chuck의 범위를 할당한다.

이 모델에서는 샤드 키 값이 가까운 문서가 동일한 청크 또는 샤드 에 있을 가능성이 높다.

이를 통해 연속 범위 내의 대상 문서를 읽는 효율적인 쿼리가 가능하다.

 

범위 분할은 다음 특성을 가질 때 효율적이다.

• Large Shard Key Cardinality
• Low Shard Key Frequency
• Non-Monotonically Changing Shard Keys

 

하지만 이 방식은 치명적 단점이 있다.

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

X가 순차적으로 늘어나는 값이라면 마지막 샤드인 C에만 데이터가 쌓이니까 C가 핫스팟이 될 수 있고, 데이터 불균형을 해소하기 위해 다른 샤드로 데이터를 마이그레이션을 내부적으로 한다. 이는 부하가 크기 때문에 사용자 쿼리에도 문제가 생길 수 있다.

가능하면 분산이 잘되는 Hash Sharding 방식을 사용하는 것을 권장한다.

Hashed Sharding

샤드키 값의 해시값을 이용해서 chuck에 할당한다. 데이터가 균등하게 잘 분산되는 방식이다.

 

원본값이 같으면 해시값도 같으니까 데이터의 선택도 cardinality가 낮으면 부하평준을 완전히 막을 순 없다.

그리고 ranged sharding 처럼 데이터가 연속되어있지 않고 분산되어있어서 모든 샤드에 다 요청해서 필터링해가야할 수 있다 (broadcasting operation)

범위 조건으로 조회할 때, 거의 모든 샤드에 분산되어있을 확률이 높아서 많은 샤드를 읽게 돼서 targeting operation 성능의 차이가 크게 된다.

균등하게 데이터를 분산하는 게 목적이라 거의 대부분 hash sharding을 사용한다.

Zone sharding

range sharding와 hash sharding과 함께 사용하게 된다

글로벌하게 지역별로 데이터를 분산시켜야하는 경우, IP를 기준으로 zone sharding을 함께 주로 사용해서 네트워크에 대한 레이턴시를 낮출 수 있다.