MongoDB의 배포 형태

Replica Set

사진 : 패스트캠퍼스 -  백엔드 개발자를 위한 한 번에 끝내는 대용량 데이터 & 트래픽 처리

하나의 mongoDB를 사용한다고 할 때 db의 점검이 필요하면 서비스를 중단해야하기 때문에 실제 배포를 할 때에는 위와 같이 mongoDB 3개를 띄우고, 하나의 db에 write를 하면 나머지 2개의 mongoDB에 복사가 되는 형태로 배포한다고 한다.

 

위와 같은 형태를 Replica Set이라고 한다.

 

 

Replica Set은 HA 솔루션이다. 멈춤 없이 지속적으로 운영되어야 하는 서비스에서의 최소 조건이다. 각각 member는 각각 다른 서버에 띄어져있어야지 요구사항에 일치하는 것이다. member들 중에 하나는 무조건 primary이며, 유일하게 write를 할 수 있다. Secondary는 읽기 상태만 할 수 있고, local database의 Oplog Collection을 통해 primary를 복제하여 유지된다.

 

쿼리를 날릴 때 그냥 read를 하는 것이 아니라 Read Preference를 통해 Secondary 쪽으로 read를 해서 읽기의 트래픽을 분산하게 된다.

 

만약에 Primary가 사용할 수 없게 되면 Secondary 중 하나가 Primary가 된다.

 

 

 

Sharded Cluster

그럼에도 불구하고 서비스가 확장되어서 대용량 트래픽이 요구되면 Sharded Cluster를 이용한다.

 

사진 : 패스트캠퍼스 -  백엔드 개발자를 위한 한 번에 끝내는 대용량 데이터 & 트래픽 처리

각각의 Shard가 Replica Set이라고 생각하면 되고 scaling out을 통해 분할해서 Shard를 여러개로 둔 것이다.

 

Sharded Cluster는 너무 어려운 개념이기 때문에 간단한게만 설명할 것이다.

 

 

장점

용량의 한계를 극복

데이터 규모와 부하가 크더라도 처리량이 좋음

고가용성을 보장

하드웨어에 대한 제약을 해결

 

 

단점

관리가 복잡

Replica Set과 비교할 때 느린 쿼리

 

 

각각의 Shard가 내부적으로 균등한 데이터를 갖도록 하고, mongos라는 router가 각각의 Shard들과 application의 중간단계 역할을 한다. Collection 단위로 Sharding이 가능하며 Sharding은 Sharding Key를 선저해야하고 해당 필드에는 인덱스가 만들어져 있어야한다.