MongoDB의 샤딩에 대해 알아보기

샤딩의 개념과 정의

샤딩의 목적 - 데이터의 분산 저장

• 단 한대의 서버에 빅데이터를 저장하는 것은 불가능하다.
  • 서비스의 성능 저하를 유발 : 초당 발생하는 엄청난 양의 insert 동작 시, Write scaling 문제 발생
  • 디스크를 사용하는 하드웨어의 한계성
• 데이터를 분산하여 순차적으로 저장한다면 한 대 이상에서 트래픽을 감당하기에 부하를 분산시키는 효과

---

샤딩의 목적 - 백업과 복구 전략

• 데이터 분산이라는 샤딩의 가장 대표적인 기능을 통해 얻는 효과
  • 시스템의 성능 향상
  • 데이터 유실 가능성으로부터 보호
• 서버의 데이터가 유실된다면 그 데이터의 양은 상상을 초월할 것이고 시스템 복구에 엄청난 비용 소요
• 미리 데이터를 분산하여 저장해둔다면 리스크로부터 보호받고 효과적인 시스템 운영이 가능

---

샤딩의 목적 - 빠른 성능

• 여러 대의 독립된 프로세스가 병렬로 작업을 동시에 수행하기 때문에 이상적으로 빠른 처리 성능을 보장

---

샤딩 시스템 구조

• mongos - 라우터
• mongos는 3대의 shards를 가짐
• mongos 는 client로부터 받은 데이터를 3대의 shards에 분산하여 저장
• 하나의 shards 안에서는 데이터 분실 방지를 위해 mongod를 이용하여 레플리카셋을 구성
• Config Servers - 전체적인 메타데이터 관리 / 어떤 데이터가 어디에 분산되어 저장되어 있는지

---

샤딩 시스템의  특징

• 샤딩 시스템은 분산처리를 통한 효율성 향상을 가장 큰 목적으로 한다.
  • 가능한 성능 보장을 위해 3대 이상의 서버를 샤드로 활용하는 것을 추천
  • 최소 2대만 있으면 샤드 서버 구축 가능
• 샤드 서버로 운영하게 되면 기존에 한 대의 서버로 운영할 때 보다 메모리를 20-30% 정도 추가 사용
  • 샤드 시스템 구축 시 사용하는 라우팅 서버인 mongos와 OpLog, Balancer 프로세스가 추가로 메모리를 사용하기 때문
  • 기존에 싱글 서버보다 20-30% 정도 추가 메모리를 준비 필요

---

Config 서버 개요

• 샤드 시스템 구축 시 필요한 Config 서버 특징
  • Config 서버는 샤드 시스템에 대한 메타 데이터 저장/관리 역할
  • 샤드 서버의 인덱스 정보를 빠르게 검색 가능케 함
  • 샤드 서버와 별도의 서버에 구축이 기본
  • 장애 발생에 대비하여 최대 3대 이상 사용 ( 최소 1대만으로도 운영 가능 )
  • 샤드 서버에 비해 저사양 서버 사용 가능

---

mongos 서버 특징

• mongos 애플리케이션의 주요 특징
  • 하나 이상의 프로세스를 사용
  • Config 서버의 MetaData를 캐시 한다.
  • 빅데이터를 샤드 서버로 분산해주는 프로세스
• Config 서버는 각 샤드 서버에 어떤 데이터들이 어떤 식으로 분산 저장되어 있는지에 대한
  Meta 데이터가 저장되어 있는데, mongos 서버를  통해 데이터를 읽고 쓰는 작업이 가능하다.
• 또한 mongos는 각 서버에서 어떤 일을 하는지 개발자가 모르게 해주는 역할을 한다.
  mongos를 통해 지금 샤딩 상태인지 리플리케이션 상태인지 개발자는 알 필요가 없다.

---

샤딩 시스템 계층

• 중개자 계층은 샤딩 시스템의 가장 핵심적인 부분으로,
  샤드 메타 정보를 저장하여 응용 계층으로부터 전달된 질의를 분석하여 적절한 샤드에 명령을 수행시키고
  그 결과를 응용계층으로 다시 전달

---

Shard key 구성

• Shard key 구성 방법이 MongoDB 샤딩 시스템을 구축할 때 가장 중요하다.
• Shard key는 여러 개의 Shard 서버로 분할될 기준 필드를 가리키며,
  앞으로 partition과 load balancing의 기준이 된다.
• 때문에 MongoDB 데이터의 저장과 성능에 절대적 영향을 미친다.
• Shard key는 cardinality를 보고 적절한 선택이 필요하다.
• 데이터 분포가 넓으면 Low Cardinality라고 표현하고, 높으면 High Cardinality 라고 표현한다.
• 사원번호는 고유한 값으로 구성되어 높은 카디널리티를 가지게 된다.
• 남 / 여 라는 필드로 샤드키를 구성하면 검색 시 인덱스의 도움을 받을 수 없다.

 

• Shard key는 Chunk migration의 횟수와 빈도를 결정한다.
  • migration : 서버에 균등하게 데이터를 재조정하는 과정
• 하나의 서버에 저장되는 데이터들을 여러 개의 논리적 구조로 분할 저장하다가,
  일정한 데이터 양에 도달했을 경우 두,세번째 서버로 데이터를 분할하여 저장하며,
  이 분할단위를 Chunk라고 부른다.
• Chunk의 크기는 기본적으로 64MB( or 100,000row) 단위로 분할되며,
  필요 시 64MB 이상의 Chunk 크기를 갖는 것도 가능하다.
• 기본 설정 단위보다 빈번히 Chunk migration이 발생한다면, Chunk의 크기를 크게 설정
• 하나의 서버에만 데이터가 집중되고 전체 샤드 서버에 골고루 데이터가 분산되지 않는다면,
  Chunk의 크기를 더 작게 설정해 효율적으로 데이터 분산이 필요

---

샤딩 시스템 구성

데이터 저장 공간 생성

• 샤드 서버용 저장 공간 생성

mkdir C:\mongodb\shard1
mkdir C:\mongodb\shard2
mkdir C:\mongodb\shard3

• Config 서버용 저장 공간 생성

mkdir C:\mongodb\config1
mkdir C:\mongodb\config2

• 샤드 서버 실행

Mongod -shardsvr -dbpath c:\mongodb\shard1 -port 40001
Mongod -shardsvr -dbpath c:\mongodb\shard2 -port 40002
Mongod -shardsvr -dbpath c:\mongodb\shard3 -port 40003

• config 서버 실행

mongod --configsvr --replSet replica --dbpath C:\mongodb\config1 --port 50001
mongod --configsvr --replSet replica --dbpath C:\mongodb\config2 --port 50002

---

mongos 서버 실행

• mongos 서버 실행

Mongos -configdb replica/localhost:50001,localhost:50002 -port 50000 -chunkSize 1
mongo --port 50000

• 샤드 서버 추가 ( 서버 구동 시에도 샤드 서버 추가 가능 )

db.runCommand({addshard : "localhost:40001"});
db.runCommand({addshard : "localhost:40002"});
db.runCommand({addshard : "localhost:40003"});

• 샤드 키 지정

db.runCommand({enablesharding : "person"})
db.runCommand({shardcollection : "person,users", key:{_id:1}})

---

데이터 저장

• 다량의 데이터 입력

use person
for (var i=0; i<1000000; i++) { db.users.save({name:"name"+i}) }

• 현재 샤드 상태 조회

printShardingStatus();

---

데이터 확인

• 첫 번째 샤드 저장 데이터 확인

mongo localhost:40001
use persion
db.users.count()

• 두 번째 샤드 저장 데이터 확인

mongo localhost:40002
use persion
db.users.count()

---

샤드 서버 삭제

db.runCommand({"removeshard" : "localhost:40000"});

---

샤딩의 한계

MongoDB 샤딩의 한계

• 한 청크에 저장될 수 있는 BSON 객체의 개수는 250,000개 이다.
• 한 청크에 설정할 수 있는 분할 지점의 최대 개수는 8,192 개다.
• 몽고디비로 설정할 수 있는 샤드 노드의 개수는 1000개가 목표이다.
• 원인을 알 수 없는 문제로 마스터 서버가 fail 되어도 mongos는 쓰레드
  ReplicaSetMonitorWatcher가 수행되기 전까지 여전히 fail된 mongod를 마스터로 간주할 수 있다.
  이 시점에 응용 계층에서 전달된 질의를 수행하면 에러가 발생한다.
  또한, 새로운 마스터가 선출되기 전에 삽입하고자 했던 데이터가 사라졌다는 것을 인식할 수 없어 데이터 유실 가능성이 발생한다.
• 몽고디비의 mongos는 마스터 선출에 관여할 수 없기 때문에 ,
  마스터가 없을 때 슬레이브가 읽기 연산 모드를 지원해주지 않는다면 전체 시스템이 다운될 수 있다.