샤딩이란?

샤딩의 목적

 

DB 샤딩은 데이터가 급격히 증가하게 되거나 트래픽이 특정 DB로 몰리는 상황을 대비해 빠르고 유연하고 안전하게 DB 를 증설 할 수 있게 한다.

전테 데이터베이스에 모든 데이터를 한 테이블 혹은 데이터베이스에서 관리하기 어려워 진다. 

데이터베이스 볼륨이 커지면 커질수록 데이터베이스 읽기/쓰기 성능은 감소할 것이고, 데이터베이스가 병목 지점이 될 것이다.

따라서 이를 적절히 분할할 필요가 있다. 데이터베이스를 분할하는 방법은 크게 샤딩과 파티셔닝이 있다.

이 두가지 기술은 거대한 데이터셋을 서브셋으로 분리하여 관리하는 방법이다.

 

---

샤딩이란?

 

샤딩(Sharding)은 DB 트래픽을 분산할 수 있는 중요한 수단이다. 특정 DB의 장애가 전면 장애로 이어지지 않게 하는 역할도 한다.

샤딩은 동일한 스키마를 가지고 있는 여러대의 데이터베이스 서버들에 데이터를 작은 단위로 나누어 분산 저장하는 기법이다. 이때 작은 단위를 샤드라고 한다. 해당 데이터에 접근할 때는 샤딩키를 이용하여 동적으로 DB 서버를 매핑하는 과정이 필요하다.

 

어떻게 보면 샤딩은 수평 파티셔닝의 일종이다. 차이점은 파티셔닝은 모든 데이터를 동일한 컴퓨터에 저장하지만 샤딩은 데이터를 서로 다른 컴퓨터에 분산한다는 점이다. 물리적으로 서로 다른 컴퓨터에 데이터를 저장하므로, 쿼리 성능 향상과 더불어 부하가 분산되는 효과까지 얻을 수 있다. 즉 샤딩은 데이터 베이스 차원의 수평 확장(Scale-out)인 셈이다.

 

요약하자면 샤딩과 수평적 파티셔닝과 차이점은 수평적 파티셔닝은 동일한 DB 서버 내에서 테이블을 분할하는 것이고 샤딩은 DB 서버를 분할한다는 것이다. 즉, DB 서버의 부하를 분산할 수 있다.

 

샤딩을 하기 위해서는 공통 요구사항이 필요하다.

 라우팅을 위해 구분할 수 있는 유일한 키값이 있어야 한다.

 설정으로 쉽게 증설이 가능해야 한다.

 

주의점

 

데이터를 물리적으로 독립된 데이터베이스에 각각 분할하여 저장하므로, 여러 샤드에 걸친 데이터를 조인하는 것이 어렵다.

또 한 데이터베이스에 집중적으로 데이터가 몰리면 Hotspot이 되어 성능이 느려진다. 따라서 데이터를 여러 샤드로 고르게 분배하는 것이 중요하다. 또 Celebrity Problem 등 다양한 문제가 존재한다.

 

---

모듈러 샤딩 (Hash Sharding)

 

모듈러 샤딩은 PK를 모듈러 연산한 결과로 DB를 라우팅하는 방식이다.

이 방식의 특징은 다음과 같다.

•  레인지 샤딩에 비해 데이터가 균일하게 분산된다.
•  DB를 추가 증설하는 과정에서 이미지 적재된 데이터의 재정렬이 필요하다.

 

데이터가 늘어남에 따라 샤딩을 추가적으로 해야하는 상황이 자주 생기면 큰 부하가 발생한다. 그렇기 때문에 모듈러 샤딩은 데이터량이 일정 수준에서 유지될 것으로 예상되는 데이터 성격을 가진 곳에 적용할 때 어울린다.

 

데이터가 균일하게 분산된다는 점은 트래픽을 안정적으로 소화하면서도 DB 리소스를 최대한 활용할 수 있다는 것을 의미한다.

 

요약하자면 총 데이터베이스 수가 정해져 있을 때 유용하고, 데이터의 재정렬이 필요하다.

 

---

레인지 샤딩

 

레인지 샤딩은 PK 범위를 기준으로 DB를 특정하는 방식이다.

 

특징은 아래와 같다.

•  모듈러 샤딩에 비해 기본적으로 증설에 재정렬 비용이 들지 않는다.
•  일부 DB에 데이터가 몰릴 수 있다.

 

레인지 샤딩의 가장 큰 장점은 증설 작업에 드는 큰 비용이 들지 않는다는 점이다. 데이터가 급격히 증가할 여지가 있다면 레인지 방식은 좋은 선택이 될 것이다.

 

다만 활성 유저가 몰린 DB로 트래픽이나 데이터량이 몰릴 수 있다. 그러면 또 몰리는 DB는 분산되고 트래픽이 저조한 DB는 통합시키는 과정이 필요하다. 따라서 적절한 Range 기준을 잡는 것이 중요하다.

 

ex) 이렇게 분산을 시켜놨는데 특정한 데이터베이스에만 부하가 몰릴 수 있다. 예를 들어 페이스북 게시물을 레인지 샤딩했다고 가정한다. 대부분의 트래픽은 최근에 작성한 게시물에서 발생할 것이다. 그렇다면 특정 샤드에만 부하가 몰릴 것이고, 부하 분산을 위해 데이터가 몰리는 DB는 다시 재샤딩하고 트래픽이 저조한 데이터베이스는 다시 통합하는 작업이 필요할 것이다.

 

---

디렉토리 샤딩

 

디렉토리 샤딩은 별도의 조회 테이블을 사용해서 샤딩을 하는 경우다.

 

특징은 아래와 같다.

 샤딩에 사용되는 시스템이나 알고리즘을 사용할 수 있다.

 샤드를 동적으로 추가하는 것도 비교적 쉽다.

 모든 읽기 및 쓰기 쿼리 전에 조회 테이블을 참조해야 하므로 오버헤드가 발생한다.

 

 

---

샤딩과 복제 비교

 

데이터베이스 샤딩은 동일한 정보의 복사본을 생성하지 않는다. 대신 하나의 데이터베이스를 여러 부분으로 분할하여 서로 다른 컴퓨터에 저장한다. 복제와 달리 데이터베이스 샤딩은 고가용성을 제공하지 않는다. 샤딩을 복제와 함께 사용하면 확장성과 고가용성을 모두 실현할 수 있다.

 

경우에 따라 데이터베이스 특정 데이터 세트의 복제본으로 샤딩을 구성할 수 있다. 예를 들어 미국과 유럽 고객 모두에게 제품을 판매하는 소매점은 사이즈 변환표의 복제본을 두 리전의 서로 다른 샤드에 저장할 수 있다. 이 경우 애플리케이션은 다른 데이터베이스 서버에 액세스하지 않고도 변환표의 복제본을 사용하여 치수를 변환할 수 있다.

 

---

정리

 

샤딩은 일반적으로 DBMS가 지원하는 기능이 아니다. 그래서 ORM을 사용하거나 DB에 접근하는 서버에서 구현해주는 작업이 필요하다.

샤딩을 사용하면 DB의 트래픽을 분산 시킬 수 있게 큰 역할을 한다. 추가적으로 DB의 테이블 크기를 줄이게 되고 DB의 장애를 국소화 시키는 부수적인 역할도 한다.

 

하지만 샤딩은 파티셔닝이나 복제보다 신중하게 결정해야한다. 샤딩은 실제 구현이 복잡하다.

잘못 수행하면 데이터가 손실되거나 테이블이 손상되거나 부하의 불균형 등이 발생할 수 있다. 이를 샤딩 전 원래 DB 구조로 되돌리는 작업은 매우 복잡하고 어렵다.

 

조회할 레코드를 줄이기 위해서는 일반적으로 파티셔닝을 적용할 수 있다. 장애를 방지하고 DB 부하를 분산시키기 위한 목적으로는 복제를 사용할 수 있다. DB 서버에도 MSA 를 적용하고 분산 트랜잭션으로 잘 풀어나가는 방법도 있다.

 

하지만 정말 그렇게 해도 안될 경우가 있다. 가령, 전 세계적으로 데이터를 관리하는 경우 당연히 서버가 지역별로 많이 분포되어 있을 수록 좋다. 이때는 샤딩을 사용할 수 있다. 미친듯이 사용자가 많고 레코드 수가 많아서 Master DB 하나로 도저히 받지 못할 때도 샤딩을 사용할 수 있다.

 

DB 서버 뿐만 아니라 어떠한 서버에도 Scale-up 은 한계가 있다. DB 서버에서의 Scale-out은 동기화라는 제약이 따르게 되는데 전 세계의 뿔뿔이 흩어진 수 천, 수 만개의 DB를 동기화 하는 과정은 결코 쉽지 않다. 그래서 DB 서버의 샤딩은 대규모 시스템 설계와 확장성 확보에 필수 불가결인 요소가 된다.

 

---

참고링크

https://aws.amazon.com/ko/what-is/database-sharding/

데이터베이스 샤딩이란 무엇인가요? - DB 샤딩 설명 - AWS

https://jaehoney.tistory.com/245

Database - 샤딩이란 무엇인가?! (+ 샤딩의 다양한 기법, 각 기법 비교)

https://hudi.blog/db-partitioning-and-sharding/

데이터베이스 파티셔닝과 샤딩