[mongoDB] 샤딩(Sharding)

• 1) 샤딩(Sharding)이란?
  • 1.1) 샤딩의 필요성
  • 1.2) 샤딩의 종류
• 2) MongoDB 샤딩 아키텍처
  • 2.1) 컨피그 서버
    • 컨피그 서버의 복제 방식
• 2.2) 라우터
  • 주요 역할
  • 쿼리 분산
  • 배포
• 3) 샤딩 알고리즘
  • 청크
  • 3.1) 레인지 샤딩(Range Sharding)
  • 3.2) 해시 샤딩(Hashed Sharding)
    • 제약 사항
  • 3.3) 지역 기반 샤딩(Zone Sharding)
    • 사용 목적
• 4) 프라이머리 샤드
• 5) 청크 밸런싱
  • 5.1) 샤드 클러스터 밸런서
  • 5.2) 청크 스플릿(Chunk split)
• 6) 샤딩으로 인한 제약
  • 6.1) 트랜잭션
  • 6.2) 샤딩과 유니크 인덱스
  • 6.3) 조인과 그래프 쿼리
• 참고자료

---

1) 샤딩(Sharding)이란?

샤딩이란 데이터를 여러 서버에 분산해서 저장하고 처리할 수 있도록 하는 기술을 말한다.

MongoDB의 복제는 고가용성을 위한 솔루션이며, 샤딩은 분산 처리를 위한 솔루션이다.

 

MongoDB에 샤딩을 적용하려면 샤드 클러스터(Sharded Cluster)를 구축해야 한다.

1. 라우터(Router)
2. 샤드 서버(Shard server)
3. 컨피그 서버(Config server)

1.1) 샤딩의 필요성

기술 발전에 따라 인터넷이 가능한 단말기는 기하급수적으로 늘어나고 있다. 그만큼 애플리케이션도 많이 출시되고, 몇백만 몇천만의 사용자를 확보하는 것도 예삿일이다.

그만큼 사용자의 데이터를 저장하고 처리하는 기술이 중요해졌다.

일반적인 데이터베이스 서버는 응용 프로그램이 작동하는 데 필요한 모든 데이터를 영구적으로 가지고 있어야 하므로 단순히 서버만 투입한다고 해서 확장되지는 않는다. 데이터베이스 서버를 확장하려면 데이터베이스의 데이터가 여러 서버로 분산될 수 있게 미리 응용 프로그램을 설계하고 개발해야 하는데 이를 샤딩이라고 한다.

처음에 샤딩을 고려하지 않았던 서비스에서 샤딩의 필요성을 느낀다 → 이미 데이터베이스 서버의 처리량 한계에 다다름

개발 생산성 vs 많은 사용량 딜레마. 처음부터 샤딩을 적용할지에 대한 고려 사항은 피할 수 없는 설계 과정이다.

1.2) 샤딩의 종류

종류특징

1	수평(Horizontal) 일반적인 방식	하나의 컬렉션에 저장된 도큐먼트들을 영역별로 파티셔닝해서 1/N개씩 각 샤드가 나눠 가지는 방식 기준이 되는 필드(컬럼) 선정이 매우 중요함. 파티션 키에 따라 각 샤드의 부하가 균등해질 수도 있고, 그렇지 않을 수도 있다.
2	수직(Vertical)	기능별로 컬렉션을 그룹핑하여 그룹별로 샤드를 할당 장점 구현이 간단 응용 프로그램의 변화 최소화 단점 컬렉션별로 쿼리 샤용량이 같지 않으므로 샤드 간 부하의 불균형이 잦음

2) MongoDB 샤딩 아키텍처

1. 라우터(Router)
   1. 영구적 데이터를 가지지 않음
   2. 사용자의 쿼리를 어떤 샤드로 전달할지 정하고, 각 샤드로부터 받은 쿼리 결과 데이터를 병합해서 사용자에게 되돌려주는 역할
   3. 샤드간 청크 밸런싱 및 청크 스플릿 수행
   4. 일종의 프록시 역할
2. 샤드 서버(Shard server)
   1. 영구적 데이터 저장
   2. 실제 사용자의 데이터 저장
3. 컨피그 서버(Config server)
   1. 영구적 데이터 저장
   2. 샤드 서버에 저장된 사용자 데이터가 어떻게 스플릿 되어서 분산돼 있는지에 관한 메타 정보를 저장

청크(Chunk) : 컬렉션을 여러 조각으로 파티션하고 각 조각을 여러 샤드 서버에 분산해서 저장한다. 이러한 데이터 조각을 청크라고 한다.

 

라우터 결과 반환 과정

1. 사용자 쿼리가 참조하는 컬렉션의 청크 메타 정보를 컨피그 서버로부터 가져와서 라우터의 메모리에 캐시
   1. (라우터가 청크 메타 정보를 가지고 있지 않거나, 청크 메타 정보가 오래돼서 맞지 않을 때에만 수행됨) → 컨피그 서버는 일반적으로 서버의 부하가 거의 없는 상태를 유지
2. 사용자 쿼리의 조건에서 샤딩 키 조건을 찾음
   1. 쿼리 조건에 샤딩 키가 있으면 해당 샤딩 키가 포함된 청크 정보를 라우터의 캐시에서 검색하여 해당 샤드 서버로만 샤용자 쿼리 요청
      
      1. 샤딩 키 조건에 포함된 청크가 여러 샤드에 걸쳐 있다면 대상이 되는 여러 샤드 서버에 쿼리를 요청
   2. 쿼리 조건에 샤딩 키가 없으면 모든 샤드 서버로 사용자의 쿼리 요청
3. 쿼리를 전송한 대상 샤드 서버로부터 쿼리 결과가 도착하면 결과를 병합하여 사용자에게 쿼리 결과를 반환

2.1) 컨피그 서버

샤딩된 클러스터를 운영하는 데 있어서 필요한 모든 정보를 저장 (databases, collections, chunks, chards, mongos)

일반적으로 라우터(mongos)를 이용해서 MongoDB 클러스터에 로그인한 다음 'config' 데이터베이스로 이동하면 원하는 데이터를 조회할 수 있다. 즉 라우터의 'config'는 컨피그 서버로 접속하여 결과를 가져오게 된다. 그 이외의 모든 사용자 데이터베이스와 컬렉션은 샤드 서버로 쿼리를 요청한다.

컨피그 서버의 복제 방식

1. SCCC(Sync Cluster Connection Config) - 3.2 버전부터 Deprecated
   1. 미러링 방식으로 컨피그 서버의 데이터를 동기화
   2. 미러링 방식: 서로 전혀 관계 없이 작동하는 컨피그 서버를 각각 따로 설치하고 응용 프로그램(라우터: mongos)에서 컨피그 서버에 모두 접속하여 각 서버의 데이터를 동기화하는 방식.
   3. 라우터 서버가 청크 정보를 변경하고자 하면, 모든 컨피그 서버에 접속하여 청크 정보 변경(update)문장을 각각 실행함. 완료되면 커밋을 수행하는 분산 트랜잭션을 실행함 →  컨피그 서버가 복잡해질수록 구현이 어렵고 동기화 문제 자주 유발.
      1. ex) 잠금 테이블(locks, lockpings)을 동기화하지 못해 라우터 서버가 청크 스플릿이나 밸런싱을 실행하지 못함.
2. 레플리카 셋(CSRS: Config Servers as Replica Sets)
   1. 샤드 서버처럼 레플리카 셋으로 구현 가능. 즉 샤드 서버와 구성 방식이 같아짐.
   2. 조건
      1. 컨피그 서버는 반드시 WiredTiger 스토리지 엔진을 사용해야 한다.
      2. 레플리카 셋은 아비터를 가질 수 없다
         1. 아비터 : 레플리카 셋의 멤버로 프라이머리 선출 관여. but, 실제 사용자 데이터 관여 X, 멤버로부터 Oplog 가져오지도 않음
      3. 레플리카 셋은 지연된 멤버를 가질 수 없다.
      4. 최소 3개 이상의 멤버로 구성해야 한다.(권장)
   3. 클라이언트는 컨피그 서버의 프라이머리 멤버로 접속하여 쿼리나 변경 명령을 실행
   4. Read Concern 이나 Write Concern 은 majority 로 설정. → 프라이머리 멤버가 일시적인 장애로 복구됐을 떄 롤백되는 데이터가 발생하지 않도록 하기 위함
      
      1. 레플리카 셋 멤버의 과반수에 접근할 수 있어야만 쿼리를 수행할 수 있다는 것을 의미함
      2. 컨피그 서버가 2대일 떄는 멤버 중 하나만 연결되지 않아도 메타 정보 조회와 삭제를 할 수 없게 된다.

 

 Read Concern

 

2.2) 라우터

사용자의 쿼리 요청을 샤드 서버로 전달하고, 샤드 서버로부터 쿼리 결과를 모아서 다시 사용자에게 반환하는 프록시 역할을 수행한다.

주요 역할

• 사용자 쿼리를 전달해야 할 샤드 서버를 결정하고 해당 샤드로 쿼리 전송
• 샤드 서버로부터 반환된 결과를 조합하여 사용자에게 결과 반환
• 샤드간 청크 밸런싱 및 청크 스플릿 수행

컨피그 서버로부터 클러스터의 메타 정보를 메모리에 캐시하고 있어서 사용자 쿼리를 받으면 그 쿼리를 어느 샤드 서버로 전달해야 할지 판단할 수 있다.

샤드 서버가 가지지 말아야 할 데이터인지 판단하고, 가지지 말아야 할 데이터라면 그 데이터를 제거하는 작업도 수행한다.

이러한 잘못된 데이터는 1. 청크 마이그레이션 도중에 실패했거나, 2. 각 샤드로 접속하여 강제로 데이터를 저장하는 경우에 충분히 발생할 수 있다.

이런 필터링을 처리하지 않으면 중복된 데이터나 삭제된 데이터가 사용자에게 반환될 수 있다.

쿼리 분산

샤드 키 조건을 가진 사용자 쿼리에 대해서 샤드 서버들을 제한할 수 있다.

• 타겟 쿼리
  • 소량의 데이터를 읽는 쿼리가 아주 빈번하게 유입되는 서비스에서 유리
• 브로드캐스트 쿼리
  • 대량의 데이터를 읽어가지만 빈번하지 않은 배치 형태의 프로그램에서는 모든 샤드를 골고루 활용할 수 있도록 유도하는 것이 좋다.
  • 샤드 키를 쿼리 조건으로 가지지 않아 작업 범위를 특정 샤드로 줄일 수 없다.

배포

일반적으로 응용 프로그램 서버와 함께 라우터를 배포함 - MongoDB 에서 권장하는 방식

장점

• 고가용성
• 네트워크 레이턴시 최소화
  • 응용 프로그램 서버와 MongoDB 라우터가 같은 물리 서버에 위치함

단점

• 응용 프로그램 서버의 대수가 늘어나면 늘어날 수록 MongoDB 샤드 서버 입장에서는 커넥션의 개수가 많이 늘어나게 된다.
• 실행 중인 MongoDB 라우터만 응답할 수 없는 상태가 되면 응용 프로그램 서버가 어떻게 처리해야 하는지에 대한 부분
  • 응용 프로그램 서버는 정상적으로 작동 → 사용자 요청은 유입, 실제 처리는 하나도 완료하지 못함.
  • 사용자 요청이 더이상 유입되지 않도록 하는 등의 처리가 필요함.

 

그 외로 전용 라우터 서버 배포, L4와 함께 배포 방식 등이 있다.

 배포 방식

 

3) 샤딩 알고리즘

MongoDB 의 가장 큰 장점 중 하나는 바로 데이터의 분산 처리다. 데이터 분산 처리의 근간은 바로 여러 샤드로 데이터를 분산시키는 기준이며, 데이터의 분산 기준을 샤딩 알고리즘이라고 한다.

1. 레인지 샤딩
2. 해시 샤딩 (권장)
3. 지역 기반 샤딩

청크

컬렉션을 샤드 키를 기준으로 여러 조각으로 파티션하고 각 조각을 여러 샤드 서버에 분산해서 저장한다. 이러한 데이터 조각(파티션)을 청크라고 한다.

청크는 샤드 키의 원본 값 또는 해시 값의 일정 범위를 가진다. 청크의 실체는 컨피그 서버의 메타 데이터로만 존재하고, 실제 각 MongoDB의 샤드 서버는 청크라는 개념에 대해서 알 필요도 없다.

하지만 청크가 논리적으로만 존재하느 ㄴ개념이기 때문에 샤드간 청크 밸런싱 문제가 발생할 수 있다.

청크 개수 불균형→ 다른 샤드로 옮겨짐 → MongoDB 샤드 서버에서는 INSERT와 DELETE가 실행된다.

기본적으로 64MB 정도까지 커질 수 있으며 그 이상으로 커지면 밸런서에 의해서 자동으로 스플릿된다.

3.1) 레인지 샤딩(Range Sharding)

샤드의 키 값을 기준으로 범위를 나누고, 사용자 데이터가 어느 청크에 포함될지 결정하는 샤딩 알고리즘

샤드 키 값이 그 자체로 정렬돼서 각 청크의 범위가 결정된다.(어느 샤드 서버로 저장될지는 레인지 샤딩의 목적이나 역할이 아님. 단순 청크의 범주 값을 결정)

장점

• 범위 검색 쿼리를 타겟 쿼리(Target Query)로 실행 가능

단점 

• 샤드에 데이터가 균형 있게 분산되지 않을 가능성이 높다.
  • 한 범위에 속하는 데이터가 많아지면, 데이터 불균형 → 점보 청크 문제, 샤드 서버의 자원을 균형 있게 사용하지 못함 → 불균형이 심해지면 클러스터의 성능이 나아지지 않음.
  • 잘못 선택된 샤드 키로 인해 데이터의 불균형과 샤드 간 청크 이동 문제가 발생하고, 제대로 사용자 쿼리를 처리하지 못하는 상황이 발생할 수 있음.

→ 가능한 해시 샤딩을 사용하고 해시 샤딩을 사용할 수 없을 때 레인지 사용하기를 권장

3.2) 해시 샤딩(Hashed Sharding)

샤드 키 값의 해시값을 이용해서 청크를 할당하는 샤딩 방식 MD5 해시 함수를 이용한다. 요즘에는 충돌이슈로 리버스 해시를 많이 사용하지만, 샤드 키는 암호화가 목적이 아니라 데이터의 분산이 주목적이기 때문에 MD5 해시를 사용한다.

해시 샤딩도 결국 레인지 샤딩의 일종이다. 64bit 정수가 가질 수 있는 값으 ㅣ모든 범위를 커버하고 있으며, 각 청크는 64bit 정수의 연속된 값을 담당하고 있으므로 레인지 샤딩과 동일하다고 볼 수 있다. 하지만 샤드 키의 해시 결괏값으로 레인지 샤딩을 적용하는 것이다.

대부분의 암호화 해시 함수는 지정된 범위 내에서 매우 균등하게 분포된 값을 반환하기 때문에 샤드 키의 값이 비슷한 값을 가진다 하더라도 해시 함수의 결괏값은 매우 다른 값을 반환한다. 그래서 해시 함수를 거친 샤드 키 값은 전체 범위에 대해서 골고루 분산되는 효과를 내게 된다.

→ 레인지 샤딩이 가지는 대표적인 단점을 제거 1. 샤드 키 값이 특정 범위에 집중되어 있을 때 발생하는 데이터 불균형 2. 연속된 샤드 키 액세스로 인한 특정 샤드 서버의 부하 편중

제약 사항

• 범위 검색 쿼리는 브로드캐스트 쿼리로 실행
  • 샤드 키의 원본이 아닌 해시 함수의 결괏값으로 청크를 분산하기 떄문에 원본값의 범위 검색을 할 때 특정 청크를 한정할 수 없어 타겟 쿼리로 실행하지 못한다.
• 샤드 키 필드에 대해서 해시 인덱스를 생성해야 함
  • 샤드 키 필드에 대해 해시 인덱스를 만들어야만 해시 샤딩을 이용할 수 있다. → 해시 인덱스의 제약 사항이 동일하게 적용된다.
  • 해시 인덱스
    • 단일 필드에 대해서만 해시 인덱스를 생성할 수 있음
    • 멀티 키 필드에 대해서는 해시 인덱스 생성 불가
    • 부동 소수점 필드는 소수점 이하를 버리고 해시 함수 수행
    • 2^53보다 큰 부동소수점에 대해서는 해시 인덱스를 지원하지 않음

3.3) 지역 기반 샤딩(Zone Sharding)

레인지 샤딩이나 해시 샤딩과 반드시 함께 사용해야 한다. 레인지 샤딩이나 해시 샤딩은 샤딩 알고리즘이 모든 데이터를 커버할 수 있어야 하지만, 지역 기반 샤딩은 선택적으로 적용할 수 있다. 마치 옵션처럼.

즉, 관심 대상의 데이터에만 샤딩 알고리즘을 적용할 수 있다.

사용 목적

• 지역 기반으로 사용자 데이터의 구분
• 특정 사용자 데이터를 지정된 샤드 서버로 구분해서 관리
• 샤드 서버의 클래스(샤드 서버의 처리 능력이나 저장공간)별로 저장할 데이터를 구분

 

지역 기반 샤딩을 사용하려면 레인지 샤딩이나 해시 샤딩을 한 상태에서 추가로 두 가지 준비가 필요하다.

1. 샤드별로 태그를 할당하고
2. 샤드 키 범위별로 태그를 할당한다.

샤드별로 태그 할당

mongos> sh.addShardTag("shard-01", "KR") mongos> sh.addShardTag("shard-02", "KR") mongos> sh.addShardTag("shard-03", "US")

 

4) 프라이머리 샤드

샤드 클러스터의 모든 데이터베이스는 프라이머리 샤드를 가진다.

프라이머리샤드란 샤드 클러스터에서 샤딩 되지 않은 컬렉션들을 저장하는 샤드를 뜻함. 레플리카 셋의 프라이머리와는 전혀 무관하다.

 

샤드 클러스터에서 처음 데이터베이스가 생성되면 각 샤드 중에서 데이터를 가장 적게 가진 샤드를 선택해서 생성되는 데이터베이스의 프라이머리 샤드로 설정한다.

샤딩되지 않은 컬렉션을 어느 샤드에 저장할지 결정해야 하는데, 이때 기준이 되는 정보가 각 데이터베이스의 프라이머리 샤드다.

 

프라이머리 샤드는 다른 샤드로 옮겨질 수 있는데, 이렇게 프라이머리 샤드를 옮기는 작업은 MongoDB 샤드 클러스터에서 특정 샤드를 제거하고자 할 때 필요하다.

movePrimary 라는 명령어를 MongoDB 라우터에서 실행하면 가능하다. 하지만 이 명령으로 옮겨지는 컬렉션에 대해서는 데이터의 일관성을 보장하지 않는다.

또한 샤딩되지 않은 컬렉션이 새로운 프라이머리 샤드로 옮겨지고 난 이후에 해당 컬렉션의 인덱스 생성이 실행돼야 한다. 그런데 이 인덱스 생성은 포그라운드(Foreground) 모드로 생성되므로 생성 시간 동안 그 컬렉션이 가진 데이터베이스에 대해서 읽기와 데이터 변경을 수행할 수 없다. 만약 프라이머리 샤드의 변경으로 옮겨져야 하는 컬렉션이 크고 많다면 해당 컬렉션이나 데이터베이스의 읽기나 변경 쿼리를 일시적으로 멈추거나 서비스 전체를 점검 모드로 전환해야 할 수도 있다.

또한 모든 MongoDB 라우터에게 특정 데이터베이스의 프라이머리 샤드가 변경됐다는 것을 알려줘야 한다. 이렇게 갱신하는 방법은 2가지가 있다.

1. 모든 MongoDB 라우터 재시작
2. 모든 MongoDB 라우터에서 flushRouterConfig 명령 실행
   1. 각 데이터베이스의 프라이머리 샤드 정보만 갱신하는 것이 아니라 샤딩된 모든 컬렉션의 메타 정보(컬렉션의 청크 목록과 각 청크의 최솟값, 최댓값 정보)를 모두 갱신한다. 그래서 동시에 수백 대의 MongoDB 라우터에서 실행할 때에는 컨피그 서버의 부하가 높아질 수 있다.

프라이머리 샤드를 변경하는 작업은 서비스에 많은 영향을 미치는 작업이다. 샤딩되지 않은 컬렉션이 빈번하게 사용된다면 점검 모드를 고려하도록 하자. 그리고 샤드 클러스터 환경에서 샤딩되지 않은 컬렉션은 보호받지 못하는 존재와 같다. 그래서 가능한 샤딩을 적용하도록 하자.

5) 청크 밸런싱

MongoDB의 각 샤드 서버는 가능하다면 서로 균등한 수준의 데이터를 가지고 사용자의 요청을 처리하려고 노력한다. 샤드 클러스터의 모든 샤드가 동등한 부하의 사용자 요청을 처리할 때 그 샤드 클러스터가 최고의 성능을 발휘할 수 있기 때문이다. 하지만 각 샤드가 가진 데이터의 불균형은 언제든지 발생할 수 있다.

MongoDB는 이러한 샤드 간 데이터 불균형 현상을 피하기 위해서 최대한 각 샤드가 가진 청크의 개수를 동일하게 만들려고 노력한다. 또한 청크가 너무 커지면 샤드 서버는 청크 하나의 이동에 너무 많은 시스템 자원을 소모하게 된다. 이러한 현상을 막기 위해 각 청크에 데이터가 저장되거나 변경될 때마다 청크를 스플릿해야 할지 체크하는 작업을 수행한다.

5.1) 샤드 클러스터 밸런서

밸런서는 각 샤드간 청크의 개수를 모니터링하다가 각 샤드의 청크 개수가 일정 수치 이상 차이나면(불균등해지면) 적절히 청크를 옮겨서 샤드 간 부햐의 균형을 맞춘다.

불균형을 판단하는 기준은 청크를 가장 많이 가진 샤드와 청크를 가장 적게 가진 샤드의 청크 개수가 임계치 이상 차이가 나면 청크 이동을 실행한다.

전체 청크 수기준 치(Threshold)

20개 미만의 청크를 가진 컬렉션	2
20개~79개 사이의 청크를 가진 컬렉션	4
80개 이상의 청크를 가진 컬렉션	8

임계치를 정해둔 이유는 청크 이동 비용이 매우 크기 때문이다.

데이터가 저장, 삭제되면서 청크는 계속 커질 수 있고, 이로 인해 청크가 스플릿되어 전체적으로 샤드의 청크 개수가 늘어날 수 있다. 그런데 모든 샤드의 청크가 동일 시점에 스플릿되는 것은 아니기 때문에 일시적으로 2~3개 이상의 차이가 발생할 수 있다. 이렇게 일시적으로 발생할 때마다 청크를 이동하는 것은 샤드 서버에 너무 많은 부담을 주기 때문에 컬렉션의 청크 개수를 기준으로 임계치를 설정해 두었다.

밸런서가 실행되면 각 샤드가 가진 청크의 개수 차이가 기준치 이하로 떨어질때까지 청크를 이동해서 분산시킨다.

밸런서가 청크의 불균형을 감지하여 청크 이동을 시작하고 끝날 때까지를 밸런싱 라운드(Balancing Round)라고 한다. 

MongoDB 3.2까지는 밸런서가 라우터에서 실행됐는데, 클러스터에 라우터가 많이 존재할 수 있다. 수많은 라우터 인스턴스들이 서로 청크 이동을 동시에 수행하지 않도록 라우터는 밸런싱 라운드를 시작하기 전에 먼저 config 데이터베이스의 locks 컬렉션에서 잠금을 획득해야 한다. 

단점

• 어떤 라우터가 청크 밸런싱을 하는지 예측하기 어려움
• 라우터는 Stateless하계 설계되었고 관리상 중요하지 않은 프로세스에 속한다. 이러한 라우터가 청크 밸런싱을 담당하게 되면 관리상의 어려움을 유발
• 라우터는 컨피그 서버와 완전히 분리된 서버에서 작동 → 서버간 통신상 신뢰성이 낮아질 가능성이 있음

따라서, MongoDB 3.4 버전부터는 밸런서 프로세스를 컨피그 서버에서 수행하도록 아키텍처를 개선했다.

개선

• 밸런스 잠금 획득을 위해서 서로 경합할 필요가 없어짐
• 자기 자신이 메타 데이터를 가지고 있기 때문에 로컬 데이터를 변경하므로 메타 데이터 변경 단계에서 실패할 가능성이 획기적으로 줄어듦
• 청크 밸런스 작업에서 라우터가 관여 X. 오직 사용자 쿼리만 샤드로 전달하는 역할만 처리. 언제든지 재시작해도 되는 컴포넌트가 됨

5.2) 청크 스플릿(Chunk split)

청크는 샤드 간의 데이터 균형을 위해서 관리되는 가장 작은 데이터 조각(partition)이다. 그래서 청크는 샤드 간의 이동할 때 샤드 서버에 최소한의 영향을 미치도록 적절한 크기를 유지해야 한다.

청크는 자동 또는 수동으로 스플릿될 수 있는데, 자동 스플릿은 청크에 도큐먼트가 INSERT되거나 UPDATE될 때에만 해당 청크를 스플릿할지 결정한다. 

청크 스플릿 기준

• 컨피그 서버의 settings 컬렉션에서 balancer 에 설정된 청크 사이즈보다 현재 청크 크기가 클 때
• 청크 이동의 최대 도큐먼트 건수보다 많은 도큐먼트를 현재 청크가 가지고 있을 때

 

주의

청크 사이즈가 증가하는 이유는 해당 청크에 도큐먼트가 INSERT되거나 UPDATE되면서 용량이 증가하기 때문이다.

MongoDB 매뉴얼에서 명시하는 것과 같이 청크의 크기나 도큐먼트의 건수를 기준으로 INSERT 되거나 UPDATE될 때마다 자동으로 스플릿할 것인지 판단한다면 항상 모든 청크는 청크 이동이 가능한 적정 크기를 유지해야 한다. 이는 동일한 샤드 키를 가지는 도큐먼트가 많지 않은 컬렉션에 대해서는 이론적으로 청크 이동이 청크의 크기나 도큐먼트 건수로 인해서 실패해서는 안된다는 의미다.

하지만 실제로 운영해 본 경험에 비추어보면, 청크의 크기나 도큐먼트의 개수가 많아서 청크 이동에 실패하는 경우를 수 없이 경험했다. 매뉴얼대로 작동하지 않는 부분이 있는 것으로 보인다. 어쨌거나 청크의 자동 스플릿만 믿고 있어서는 안된다. 그래서 데이터가 아주 빨리 증가하는 컬렉션에 대해서는 각 청크의 크기를 주기적으로 모니터링할 필요가 있다.

 

하나의 청크는 64MB 정도의 데이터 조각으로 유지하려고 한다. 그 이상으로 커지면, 청크를 쪼개서 2개 이상의 새로운 청크로 분리한다. 이렇게 쪼개는 과정을 스플릿이라고 하고, MongoDB에서 스플릿은 두 단계로 나뉜다.

• splitVector
  • 하나의 청크를 최대 청크 크기(64MB)의 절반 크기(32MB)로 나누기 위해서 위치를 찾는 과정이다.
  • 리턴 값이 청크를 스플릿할 수 있는 유효한 포인터를 포함한다면 다음 명령어 실행
    • 스플릿 포인트를 찾지 못했다면 라우터나 컨피그 서버의 로그 파일로 기록
  • 샤드 키 인덱스의 일부(분할 대상이 되는 청크의 시작 키 값과 끝나는 지점의 키 값까지)만 스캔 → 상대적으로 가볍게 처리
  • 튜닝 대상으로 고려할 필요는 없다.
• splitChunk
  • 청크의 메타 정보를 새로운 청크 정보로 대체
  • 단계
    • 컨피그 서버의 메타데이터 잠금 획득
    • 메타 데이터 변경을 위해서 배치 업데이트 명령 실행
    • 컨피그 서버의 변경 이력 저장(changelog 컬렉션)

6) 샤딩으로 인한 제약

6.1) 트랜잭션

트랜잭션 속성으로 ACID(Atomicity, Consistency, Isolation, Durability)를 주로 언급한다.

MongoDB 에서 분산 트랜잭션을 지원하지 않아 원자성을 보장할 수 없었지만,

4.0 버전이 릴리즈되면서 Replica Set에서 작동하는 다중 도큐먼트 트랜잭션에 대한 지원이 추가되었다. 또한, 4.2 버전에서 다중 도큐먼트 트랜잭션에 대한 지원이 Sharded Cluster로 확장되어 ACID 트랜잭션을 지원함.

6.2) 샤딩과 유니크 인덱스

샤딩된 데이터 간의 유니크 인덱스 생성은 제약을 가지게 된다.

샤딩된 컬렉션에서 유니크 인덱스는 샤드 키를 포함하는 인덱스에 대해서만 적용할 수 있다.

MongoDB의 프라이머리 키는 샤딩과 무관하게 항상 유니크해야하며, 세컨드리 키 중에서도 유니크 옵션이 설정되는 경우에는 프라이머리 키와 동일하게 중복을 허용하지 않도록 처리돼야 한다.

6.3) 조인과 그래프 쿼리

여러 컬렉션의 데이터를 조인해서 쿼리할 수 있도록 $lookup 오퍼레이션 제공, 계층형 재귀 쿼리나 그래프 데이터를 쿼리할 수 있도록 $graphLookup 오퍼레이션을 지원하고 있다.

계층형 재귀 쿼리와 조인 쿼리 모두 하나 이상의 컬렉션을 대상으로 실행되고, 계층형 재귀 쿼리도 결국 조인 쿼리의 또 다른 형태라고 생각할 수 있다.

해당 오퍼레이션에 모두 "from" 인자에 주어지는 컬렉션은 샤딩된 컬렉션을 사용할 수 없다.

샤드 서버는 데이터 처리를 위해서 다른 샤드 데이터를 참조할 수 없기 때문이다.

 

 

---

참고자료

RealMongoDB