[MongoDB] 샤딩 구성

언제 샤딩해야 하나

• 사용 가능한 메모리를 늘릴 때
• 사용 가능한 디스크 공간을 늘릴 때
• 서버의 부하를 줄일 때
• 한 개의 mongod가 다룰 수 있는 처리량보다 더 많이 데이터를 읽거나 쓸 때

서버 시작

• 구성 서버는 클러스터 구성을 저장하는 일반 mongod 서버
• 클러스터 구성은 샤드를 호스팅하는 복제 셋, 샤딩된 컬렉션, 각 청크가 위치한 샤드 등을 포함

구성 서버

• 구성 서버는 어떤 서버가 무슨 데이터를 갖고 있는지에 대한 모든 메타 데이터를 보유
• mongos가 구성 서버로부터 구성을 가져오므로, 구성서버는 mongos 프로세스 앞서 시작해야함

3개의 개별 시스템에서 구성 서버 시작

• --configsvr 옵션은 mongod를 구성 서버로 사용하겠다는 뜻
• config 와 admin 이외의 데이터베이스에 데이터를 쓸 수 없음
• admin 데이터베이스는 인증 및 권한 부여와 관련된 컬렉션, 내부용 기타 system.* 컬렉션 포함
• config 데이터베이스는 샤딩된 클러스터 메타데이터를 보유하는 컬렉션 포함
• 청크 마이그레이션이나 청크 분할 후처럼 메타데이터가 변경될 때 config 데이터베이스에 데이터를 저장

> mongod --configsvr --replSet configRS --bind_ip localhost,198.51.100.51
> mongod --configsvr --replSet configRS --bind_ip localhost,198.51.100.52
> mongod --configsvr --replSet configRS --bind_ip localhost,198.51.100.53

복제 셋 멤버 중 하나에 연결

> mongo --host <호스트명> --port <포트>

rs.initiate() 보조자를 사용

> rs.initiate({
	_id: "configRS",
    configsvr: true,
    members: [
    	{_id:0, host:"cfg1.example.net:27019"},
        {_id:0, host:"cfg2.example.net:27019"},
        {_id:0, host:"cfg3.example.net:27019"},
    ]
})

mongos 프로세스

monogs 프로세스가 구성 서버들의 위치를 알아야 하므로 항상 --configdb 옵션으로 프로세스 시작

• mongos 자체는 데이터를 보유하지 않고, 시작할 때 구성 서버로부터 클러스터 구성을 가져옴
• 로그를 어딘가에 저장하기 위해 --logpath 설정
• 고가용성을 보장하려면 mongos 프로세스가 최소 두개 필요 (너무 많으면 리소스 경합을 유발)

> monogs --configdb configRS/cfg1.example.net:27019,\
    cfg2.example.net:27019,cfg3.example.net:27019,\
    --bind_ip localhost,198.51.100.100 --logpath /var/log/mongos.log

복제 셋으로부터 샤딩 추가

"rs0" 이라는 복제 셋 멤버 svr1.example.net, svr2.example.net, svr3.example.net 

mongo 셸로 멤버 중 하나에 연결

> mongo srv1.example.net

rs.status() 를 사용해 어떤 멤버가 프라이머리인지 확인

샤드용 mongod 인스턴스는 반드시 --shardsvr 옵션으로 구성

복제 셋의 각 멤버에 대해 --shardsvr 옵션을 사용해 각 세컨더리를 차례로 재시작

> mongod --replSet "rs0" --shardsvr --port 27017 --bind_ip localhost,<멤버IP>

프라이머리를 단계적으로 강등하고 --shardsvr 옵션을 사용해 재시작

> mongo svr1.example.net
> rs.stepDown()
> mongod --replSet "rs0" --shardsvr --port 27017 --bind_ip localhost, <이전 프라이머리 IP>

mongos의 admin 데이터베이스에 연결

> mongo mongos1.example.net:27017/admin

sh.addShard() 메서드로 클러스터에 샤드를 추가

• 복제 셋 멤버를 모두 지정하지 않아도 mongos는 시드 목록에 포함되지 않은 멤버를 자동으로 감지

> sh.addShard("rs0/sv1.example.net:27017,svr2.example.net:27017,svr3.example.net:27017")

복제 셋을 샤드로 추가했으면 애플리케이션이 복제 셋 대신에 mongos를 통해 접속

mongos는 복제 셋 내 모든 데이터베이스를 해당 샤드가 소유한다는 것을 등록

모든 쿼리를 새로운 샤드로 전달함

mongos는 클라이언트 라이브러리처럼 애플리케이션의 장애 조치를 자동으로 처리하며, 사용자에게 오류를 전달

MongoDB 3.6 이후 모든 샤드가 복제 셋이어야 한다

용량 추가

용량을 추가하려면 샤드를 추가

복제 셋을 생성해 빈 샤드를 새로 추가하고, 기존 샤드들과 다른 이름을 갖게 설정

샤드가 아닌 기존 복제 셋이 여러개 있으면, 데이터베이스 이름이 겹치지 않는 한 클러스터에 새로운 샤드로 추가 가능

데이터 샤딩

데이터를 어떻게 분산할지 안ㄹ려주기 전에는 자동으로 데이터를 분산하지 않는다.

music 데이터베이스의 artists 컬렉션을 "name" 키로 샤딩한다고 샤딩을 활성화

항상 데이터베이스 내 컬렉션보다 데이터베이스를 먼저 샤딩해야 한다.

> sh.enableSharding("music")

sh.shardCollections을 실행해서 컬렉션을 샤딩

"name" 필드에 인덱스가 있어야함

> sh.shardCollection("music.artists", {"name": 1})

샤딩할 컬렉션이 존재하지 않으면 mongos가 자동으로 샤드 키 인덱스를 만든다.

shardCollections 명령은 컬렉션을 청크로 나누다.

명령이 성공하면 클러스터의 샤드에 컬렉션을 분산

이 시점 이후에 로드된 데이터는 추가 밸런싱 없이 현재 샤드에 직접 삽입

 

몽고DB는 어떻게 클러스터 데이터를 추적하는가

몽고DB는 주어진 샤드 키 범위 내에 있는 도큐먼트를 청크로 나눈다.

하나의 청크는 항상 하나의 샤드에 위치하므로 몽고DB는 샤드에 매핑된 청크의 작은 테이블을 가진다.

청크가 일정 크기까지 커지면 몽고DB는 자동으로 두개의 작은 청크로 나눈다.

범위가 겹치는 청크는 가질 수 없다. 중복된 데이터를 찾으려면 두 청크를 모두 확인해야 하기 때문

배열 필드는 샤드 키로 사용할 수 없다.

청크 범위

새로 샤딩된 컬렉션은 단일 청크로부터 출발하며 모든 도큐먼트는 이 청크에 위치한다.

청크 정보는 config.chunks 컬렉션에 저장

복합 샤드 키의 경우, 샤드 범위는 두개의 키로 정렬할 때와 동일한 방식으로 작동

청크 분할

클라이언트가 청크에 쓰기를 하면 mongod는 청크의 분할 임계치를 확인

청크가 나뉘어야 한다면 mongod는 구성 서버에서 전역 청크 구성 값을 요청

청크 분할을 수행하고 구성 서버에서 메타데이터를 갱신

분할 임계치에 이르면 mongod는 최상위 청크를 이동하도록 밸런서에 요청을 보냄

샤드 키가 같은 두 도큐먼트는 같은 청크에 있어야 하기 때문에, 청크는 샤드 키 값이 변경되는 도큐먼트를 기준으로 분할

mongod가 분할을 시도할 때 구성 서버 중 하나가 작동하지 않으면 mongod는 메타데이터를 갱신 불가

mongod가 반복적으로 청크 분할을 시도하고 실패하는 과정을 분할 소동 split storm

분할 소동을 방지하는 유일한 방법은 가능한 시간만큼 구성 서버가 살아 있고 정상이게 하는 것

 

밸런서

밸런서는 데이터 이동을 책임진다.

주기적으로 샤드 간의 불균형을 체크하다가 불균형이면 청크를 이동하기 시작

밸런서는 구성 서버 복제 셋의 프라이머리 멤버에 있다.

일부 컬렉션이 임계치에 이르면 밸런서는 청크를 옮기기 시작

과부하된 샤드에서 청크를 선택하고, 옮기기 전에 샤드에 청크를 분할해야 하는지 물어본다.

분할해야 하면 더 적은 청크를 갖는 장비로 청크를 옮긴다.

 

콜레이션

콜레이션을 이용해 문자열 비교를 위한 언어별 규칙을 지정할 수 있다.

규칙의 예로 대소문자와 강세 부로를 비교하는 방법

 

스트림 변경

스트림 변경을 사용하면 애플리케이션이 데이터베이스 내 데이터의 실시간 변경 사항을 추적할 수 있다.

컬렉션, 컬렉션 집합, 데이터베이스 또는 전체 배포상의 모든 데이터 변경에 대한 구독 메커니즘을 제공

애플리케이션은 특정 변경 사항을 필터링하거나 수신된 변경 알림을 변환할 수 있다.