티스토리 뷰
MongoDB 샤딩시 구성요소는 다음과 같다.
- Mongos
- ConfigServer
- Shard Cluster
Mongos
Application server에서 mongodb에 접근할때 mongos를 통해 접근한다.
공식 문서에 다음과 같이 잘 설명되어있다.
the mongos instances provide the interface between the client applications and the sharded cluster.
The mongos instances route queries and write operations to the shards.
From the perspective of the application, a mongos instance behaves identically to any other MongoDB instance.
Config Server
config 서버에서는 샤드에 대한 구성 등 metadata를 관리한다.
Config servers store the metadata for a sharded cluster.
Shard Cluster
샤드에 실제 데이터를 저장한다.
샤드 구성시 Replica 2 set을 사용했고, 각각의 set 구성은 Master - Slave - Arbiter 구조를 사용하였다.
여기서 생소한 부분은 Arbiter라는 부분이다.
Arbiter는 실제 데이터를 replication 하지 않고, Replica 구성에서 Election에만 참여한다.
데이터를 Replication 하지도 않는데 Arbiter를 쓰는 이유는 비용 절감 차원에 있다.
Arbiter는 election에만 참여하고 데이터를 가지고있지 않기때문에 Primary, Secondary보다 낮은 스펙의 장비를 사용해서 process만 띄워두고 쓸 수 있다. 또한, Replica 2 set을 구성한다고 했을때, 하나의 물리 장비에 Arbiter process 2대를 띄워두고 각각의 Replica 구성에 election만 참여시킬 수 있기 때문에 효율적으로 사용 할 수 있다.
요약
WAS 서버에서는 mongos만 바라보고, mongos는 config 서버를 통해 샤드 구성 등 metadata를 활용하며, 쿼리를 만들고, 명령을 수행한다. 이렇게되면 새로운 샤드가 추가되었을때, config server만 새로운 샤드 구성만 알면 되고, was서버와 mongos서버에서는 추가적으로 수행 할 작업이 없다.
즉, 각자의 역할을 분리함으로써 조금 더 유연하고 확장성 있는 구조가 된 것이다.
[참고]