[MongoDB] Sharding
본 문서는 MongoDB "Sharding"을 참고하여 작성되었습니다.
https://www.mongodb.com/docs/manual/sharding/
Sharding
데이터를 여러대의 서버로 분산시켜 대용량 데이터 집합과 고 처리량 작업을 지원하는 기술
어떨때 샤딩을 고려할 수 있을까?
- 높은 쿼리 속도로 서버의 CPU 용량이 부족할 때
- 시스템 RAM보다 큰 작업 집합 크기로 디스크 I/O 용량을 초과할 때
스케일링 방법
수직 스케일링(Vertical Scaling)
- 단일 서버의 성능을 향상시키는 것을 의미
- 더 강력한 CPU 사용, 더 많은 RAM 추가, 또는 저장 공간을 늘리는 것과 같은 방법을 사용
- 작업 부하에 충분히 대응하지 못할 수 있으며, 클라우드 기반 제공업체는 사용 가능한 하드웨어 구성에 따라 스케일링의 제한이 있음
수평 스케일링(Horizontal Scaling) !! MondoDB의 샤딩 방법
- 시스템 데이터 집합과 부하를 여러 대의 서버로 나누며, 필요에 따라 추가 서버를 추가하여 용량을 증가
- 각 개별 기계의 속도나 용량이 높지 않을 수 있지만, 모두 함께 전체 작업 부하의 일부를 효율적으로 처리
- 용량을 확장하는 것은 서버를 추가하는 작업만 필요하며, 단일 기계의 고성능 하드웨어에 투자하는 것보다 비용 효율적인 솔루션
- 배포의 인프라 및 유지 관리에 더 많은 복잡성을 동반
MongoDB의 샤드 클러스터 구성
shard
- 샤드에는 샤딩된 데이터의 일부 포함
- 각 샤드는 레플리카 세트로 배포 가능
- MongoDB는 컬렉션 레벨에서 데이터를 샤딩하며, 컬렉션 데이터를 클러스터 내의 다른 샤드에 분산
mongos
- 몽고스는 쿼리 라우터 역할
- 클라이언트 애플리케이션과 샤드드 클러스터 간의 인터페이스 역할을 제공
- MongoDB 4.4부터 몽고스는 레이턴시를 최소화하기 위한 헤지드 리드(hedged reads)를 지원
config servers
- 구성 서버는 클러스터의 메타데이터와 구성 설정을 저장
Shard Keys
Shard Key Index
- 기존 데이터가 있는 컬렉션을 샤딩하려면 컬렉션은 샤드 키로 시작하는 인덱스 필요
- 컬렉션을 샤딩할 때 이미 지정된 샤드 키에 적합한 인덱스가 없다면 MongoDB는 지원 인덱스를 생성
Shard Key Strategy
- 샤드 클러스터의 성능, 효율성 및 확장성에 영향
- 뛰어난 하드웨어와 인프라를 갖춘 클러스터라도 샤드 키의 선택에 따라 병목 현상이 발생 가능
- 샤드 키와 해당 인덱스의 선택 클러스터가 사용할 수 있는 샤딩 전략에 영향
Chunks
* 분할된 sharded data
* 각 청크는 샤드 키를 기반으로 한 포함적인 하한값과 배타적 상한값을 가짐
밸런서
- 모든 샤드에 걸쳐 청크를 고르게 분배하기 위해 백그라운드에서 실행
- 청크를 샤드 간에 이동시킴
샤딩의 이점
Reads / Writes
* 샤드 클러스터의 샤드 간 읽기 및 쓰기 작업 부하 분배 -> 각 샤드가 클러스터 작업이 일부를 처리할 수 있도록 함
* 읽기 및 쓰기 작업은 더 많은 샤드를 추가하여 클러스터 전체에 수평 확장 가능
* 샤드 키 또는 복합 샤드 키의 접두사를 포함하는 쿼리의 경우, 쿼리를 특정 샤드에 집중시킬 수 있음 -> 효율 증가
Storage Capacity
* 데이터를 클러스터의 샤드로 분산시켜 각 샤드가 전체 클러스터 데이터의 일부를 포함하도록 함
* 데이터 집합이 커짐에 따라 추가 샤드를 통해 클러스터의 저장 용량을 늘릴 수 있음
High Availability
* 구성 서버와 샤드의 배포는 replica sets으로 제공되어 고가용성을 제공
* 하나 이상의 샤드 복제 집합이 완전히 사용 불가능해지더라도, 샤드 클러스터는 게속해서 부분적인 읽기 및 쓰기 수행 가능
Considerations Before Sharding
* 컬렉션이 샤딩된 이후에는 다시 되돌릴 수 없음