MongoDB의 배포 형태 (2/2)
1. 배포 형태의 중요성
운영 중인 서비스에서 서버를 내려야 하는 상황이 온다면 어떻게 될까?
서버를 내리면 DB에 작업을 할 수 없다. 서비스 자체가 내려가는 문제가 발생한다.
위의 용도는 사실상 Study를 하거나 Test를 할 때만 사용할 수 있다.
하지만 Replica Set을 사용하면
이런 형태로 배포를 만들 수가 있다. 몽고 DB를 3개 설치하여 복제를 시켜서 동일하게 유지한다.
현업에서 가장 많이 사용하는 방식으로 이러면 HA(High Availability). 고가용성이 보장된다. Scale up을 통해 스토리지 용량을 늘릴 수 있지만, 이 방식도 한계가 있을 수가 있다.
데이터와 트래픽에 관한 분산을 해야돼서 scale out으로 확장해야 하는데. 이걸 몽고 DB에서
Sharded Cluster라고 한다. HA을 보장하며, 분산에 대한 솔루션이다.
2. Replica Set
1) 정의
Replica Set은 아래와 같은 특성을 가지고 있다.
- Primary
- Read/Write 모두 처리
- write를 유일하게 처리한다.
- Replica Set에 하나만 존재
- Secondary
- Read만 처리
- 복제로 Primary와 동일한 데이터 셋
- Replica Set에 여러 개가 존재
각 멤버는 상태값이 존재한다. 하나의 Replica Set 안에 무조건 Primary가 있어야 한다. Replica set은 각각 다른 서버에 설치되어야 한다.
Read with Read Preference 설정을 안 하면 Primary가 읽기와 쓰기를 모두 처리하고, 읽기 분산 처리를 못한다. 반면 Secondary는 페일오버 용도밖에 사용 못한다.
2) 페일오버(Fail-Over)
위는 Fail-Over를 나타내며, 멈춤없이 서비스를 지속적으로 운영하여 HA를 보장한다. Heartbeat로 서로 살아있는 걸 확인.
3) Replica Set Arbiter
위는 Replica Set Arbiter이다. Arbiter는 데이터를 들고 있지 않고, 프라이머리 선출에만 사용된다. 서버 비용이 부담되면 P-S-A를 사용. 그러나 권장되지 않는다. P-S-S는 Secondary 하나가 죽어도 Primary의 부하가 늘지 않는다.
반면 P-S-A 배포는 읽기 쓰기의 요청이 다 Primary에 가서 부하가 높아져서 서비스 장애가 될 가능성이 높아진다. 가능하면 P-S-S를 사용해야 한다.
4) Replica Set Oplog
아니면 Replica Set Oplog 형태로 동일하게 유지할 수 있다.
5) 요약
- Replica Set은 HA 솔루션으로 멤버 상태는 Primary와 Secondary가 있다.
- Secondary는 선출을 통해 과반수의 투표를 얻어 primary가 될 수 있고, Arbiter는 데이터를 들고 있지 않고 Primary 선출 투표에만 참여하는 멤버이다.
- Replica Set은 local DB의 Oplog Collection을 통해 복제를 수행한다.
3. Sharded Cluster
1) 정의
분산을 위한 배포 형태로 모든 Shard는 Replica Set으로 구성됐다.
Sharding은 하나의 큰 데이터를 여러 개로 분할한다. 분할된 데이터 셋의 모음을 shard라고 한다.
분산이 되는 기준을 shard key라고 한다. Shard key는 컬렉션의 필드에 생성된 인덱스로 활성화한다. Shard 클러스트는 분산을 위한 솔루션 HA를 보장한다.
정리하면 Replica는 HA을 위한 솔루션이고, Sharding은 분산 처리 혹은 Scale out을 위한 솔루션이다.
Sharded Cluster는 아래의 장단점을 가지고 있다.
- 장점
- 용량의 한계를 극복할 수 있다.
- 데이터 규모와 부하가 커도 처리량이 좋다.
- 고가용성을 보장한다.
- 하드웨어 제약을 해결
- 단점
- 관리가 복잡하다.
- Replica set과 비교하면 쿼리가 느리다.
전체적으로 Sharded Cluster는 구성이 복잡해서 관리가 복잡하다. 운영 입장에서는 보통 replica set을 사용한다.
쿼리가 느린 이유로는 각각 샤드가 다른 데이터를 갖고 있어서, 어느 샤드에 가서 찾을지 추가적인 지연이 발생한다. Sharded cluster는 대량으로 늘어나는 데이터 저장, 라이트에 대한 부담이 늘어날 때 적합하다.
sharde와 replica를 전체적으로 비교해보면
Sharded Cluster는 분산처리를 위한 솔루션임을 알 수가 있다.
2) Architecture
Config Server는 샤드의 메타 데이터 가진다.
전체적인 플로우는
사용자 => router => config server=> 어떤 shard에요청할지확인 => router가 shard에접근 => 사용자에게 다시 반환을 한다.
내부적으로 shard가 균등하게 데이터를 갖게끔 작업을 한다.
3) Sharding Collections
샤딩이 느린 이유는 데이터가 분산되어 있어서 데이터를 조회하고 merge하는 시간을 소모하기 때문이다.
메타 데이터는 하나의 샤드에만 지정하면 훨씬 좋은 성능을 갖게 할 수 있다.
4) Ranged Sharding
치명적인 단점으로 데이터가 균형있게 분산되지 않을 가능성이 높다. 이에 가능하면 해시 샤딩을 권장한다. 해시 샤딩이 불가능한 경우에만 ranged sharding을 사용한다.
5) Hashed Sharding
매우 균등하게 분산이 잘 된다.
6) Zone Sharding
글로벌하게 latency를 낮춰서 빠른 응답을 받을 수 있다. 깊게 들어갈수록 여러 개념들이 나온다.
7) 정리
- Sharded Cluster는 MongoDB의 분산 Solution으로 Collection 단위로 Sharding이 가능하다.
- Sharding은 Sharded Key를 선정해야하고, 필드에는 Index가 만들어져야 한다.
- 꼭 Router를 통해서 접근해야 하는데 그 이유는 router를 사용 안 할 경우, 고아 document들이 보일 수가 있기 때문.
- Range와 Hashed Sharding 두 가지 방법이 있으며, 가능하면 Hashed Sharding을 통해 분산해야 한다.
4. Replica Set vs Sharded Cluster
이 둘의 선택 기준에는 먼저 1) 서비스의 요구사항 확인. 2) 배포 환경 확인 3) DB 배포를 고려해야 한다.
3가지 예시를 통해 선별 기준이 무엇인지 간략히 알아보자.
1) Example 1
매일 1GB씩 데이터가 증가하고, 3년간 보관. => 환경에 따라 다르다.
2) Example 2
Write 요청이 압도적으로 많은 서비스 => Sharded Cluster.
보통 증권 어플에 쓰기 요청이 높으며, 이럴 때는 Sharded를 사용한다.
그 이유는 Replica Set은 Write에 대한 분산이 불가능하기 때문이다.
3) Example 3
논리적인 데이터베이스가 많은 경우 => 여러 Replica Set으로 분리
4) Replica set vs Sharded Cluster
(1) 장단점
Replica Set은 운영이 쉽고, 장애 발생 시 문제 해결 및 복구가 쉽다. 또한 서버 비용이 적게 들고, 성능이 좋으며 개발 시 설계가 용이하다. 단점으로는 Read에 대한 분산이 가능하지만, Write에 대한 분산이 불가능하다.
Sharded Cluster는 Scale out이 가능하고, Write에 대한 분산이 가능하다. 단점으로는 Replica Set의 장점이 많기에 상대적으로 단점이 된다.
(2) 성능 비교
엄청 차이나지 않는다. 대체적으로 replica-set의 수행속도가 좀 빠르다.
Aggregation도 비슷한 양상을 보이는데
Insert는 확실히 많이 차이가 난다. 전체적으로 replica set이 월등히 좋은 건 아니더라도 대체로 좋다.
※위의 차트는 샤드를 2개만 사용해서 크게 차이가 나지 않았을 가능성이 높고, 10개 - 20개하면 더 차이가 있을 수가 있다.
5. 결론
항상 Replica Set으로 검토하고,
서비스 요구사항이 Replica Set으로 충족이 안 되면 Sharded Cluster를 사용하자!
출처: FastCampus 대용량 데이터 & 트래픽 처리