# MongoDB Sharded Cluster 기본
MongoDB의 sharded cluster를 구성할 때, 3종류의 서버를 알아야한다.
1. mongos(=router)
2. config
3. shard(=replica set)
mongos 서버는 어플리케이션으로부터 쿼리를 받아서 각 샤드로 쿼리를 보내주는 역할이다.
데이터가 저장되어 있진 않고, 말그대로 router 역할을 해주기만 한다.
어플리케이션으로부터 쿼리가 오면 mongos는 config 서버에 메타정보를 요청한다.
이때, 메타정보는 데이터가 저장되어있는 shard 정보 및 sharding key 정보들이다.
만약 그대가 쿼리에 shard key를 고려했다면, mongos는 해당되는 샤드만 접근할 것이다.
mongos는 이러한 정보들을 이용해
특정 replica set에 접근하여 데이터를 요청한다.
각 shard 서버들이 데이터를 주면 mongos는 merge만 한다.
만약 집계와 같이 여러 샤드에서 온 데이터를 병합을 해야한다면,
무작위로 하나의 샤드서버가 선택되어 거기서 모든 데이터가 병합이 된다.
config 서버는 shard들의 메타데이터를 저장하는 서버이다.
메타데이터는 모든 샤드의 chunk 리스트와 chunk의 범위에 대한 정보이다.
mongos서버는 이 데이터를 이용해 적정한 shard에 쿼리를 전달하는데
각 shard들도 config 서버에서 chunk 메타데이터를 읽기도 한다.
shard 서버는 replica set으로 구성되어 있으며 실제 데이터가 저장되는 곳이다.
shard 서버의 데이터는 여러개의 조각으로 파티션되며
이 조각들이 여러 샤드 서버에 분산 저장되는데
이 데이터 조각을 chunk라고 한다.
이 chunk는 각 샤드서버에 균등하게 저장되어야 좋은 성능을 낼 수 있고
한 쪽 샤드에 chunk가 너무 몰려있으면
mongodb 자체적으로 백그라운드로 chunk를 균등하게 balancing 작업을 하기도 한다.
여기서 zone의 개념도 있다.
zone은 shard key에 기반하여 생성하는 것으로
각 샤드의 zone을 설정하여
zone에 포함되는 shard key를 가진 데이터를 저장하도록 유도하는 것이다.
참고로 동일한 zone이 여러 shard에 해당될 수 있고
하나의 shard가 여러 zone을 가질 수 있다.
그리고 각 shard는 replica set으로 구성되어 있는데
보통 primary-secondary-arbiter 혹은 primary-secondary-secondary로 구성된다.
여기서 arbiter는 데이터를 저장하지 않고 오로지 투표 역할만 한다.
이때, replica set은 최소 3개 이상의 홀수개로 구성해야한다.
replica set은 서로 자기들끼리 heartbeat를 보내는데
만약 한서버가 heartbeat를 보내지 않는다면, 죽은 서버로 판단이 된다.
만약 primary가 고장이나면 남은 구성원끼리 투표를 해야하는데
2대뿐이라면 나머지 1대 가지고는 다수결이 안된다.
그리고 남은 1대 secondary는 primary가 되지 못하고 고립된 노드로 남겨진다.
참고로 하나의 replica set은 최대 50개 member를 설정할 수 있으며,
투표 member는 최대 7개밖에 설정할 수 없다.
기본적으로 master-slave로 구성된 서버들은
Write 작업은 master로 Read 작업은 slave로 보내어 부하를 최소화 한다.
MongoDB는 이런 기능이 없을까?
mongo에는 read preference 설정이란게 있다
read 작업을 primary로 할건지 secondary로 보낼지 설정할 수 있다.
디폴트는 primary이다.
당연히 primary로 설정하는게 일관성 측면에서 좋긴 하다.
[참고자료]
MongoDB Document
https://sarc.io/index.php/nosql/1703-mongodb-chunk-1
To be continued.........
Made by 꿩