Database Sharding(샤딩)이란?

DB Sharding이란?

shard의 사전적 의미는 (유리·금속 등의) 조각, 파편입니다. 데이터베이스의 측면에서 본다면 sharding은 데이터베이스를 조각으로 나누는 것으로 생각해볼 수 있습니다.

샤딩(Sharding)은 수평 분할(Horizontal Partitioniong)과 관련된 데이터베이스 아키텍처 중 하나로써  한 테이블의 row들을 여러 개의 서로 다른 테이블, 즉 파티션으로 분리하는 방식입니다.

 

 

DB Sharding을 하는이유?

하나의 DB에 데이터가 늘어나면 용량 이슈도 생기고, 느려지는 CRUD는 자연스럽게 서비스 성능에 영향을 주게 됩니다.

따라서 애플리케이션이 얼마나 인기를 끌지 또는 얼마나 오랫동안 그 인기를 유지할지 예측을 하기 어렵기 때문에 데이터베이스를 동적으로 확장할 수 있는 아키텍처를 선택합니다.

 

또한 DB를 분산하게 되면 특정 DB의 장애가 전면 장애로 이어지지 않는다는 장점도 있습니다.

즉, DB트래픽을 분산하기 위해 사용합니다.

 

 

Sharding vs Partitioning (샤딩과 분할)

분산 데이터베이스 시스템에서 샤딩과 파티셔닝이라는 단어가 혼란스럽게 다가올 수 있습니다.

 

파티셔닝이란 성능, 가용성, 정비 용이성을 목적으로 논리적인 데이터 엘리멘트들을 다수의 엔티티로 쪼개는 행위를 뜻하는 용어입니다.

 

예를 들어 다음과 같은 파티셔닝이 존재할 수 있습니다.

• 해쉬 코드
• 범위(월별, 분기별)
• 리스트(한국, 일본, 중국 -> 아시아, 노르웨이 , 스웨덴 , 핀란드 -> 북유럽)

이런 다양한 파티셔닝 중에서 샤딩은 수평 파티셔닝과 동일합니다.

 

Vertical Partitions vs Horizontal Partitions (수직 분할과 수평분할)

데이터베이스 샤딩 아키텍처는 수평 분할을 사용하는데 수평 분할이란 무엇이고 수직분할이란 무엇일까요?

 

Vertical Partitions(수직 분할)

• Vertical Partitioning의 경우 열 전체가 완전히 새로운 테이블로 분리됩니다.
• 테이블의 칼럼을 기준으로 나누어 분할합니다.
• 정규화하는 과정도 이와 비슷하다고 볼 수 있지만 Vertical Partitioning은 이미 정규화된 Data를 분리합니다.
• 자주 사용하는 칼럼 등을 분리시켜 성능을 향상할 수 있습니다.

https://nesoy.github.io/articles/2018-02/Database-Partitioning

Horizontal Partitions(수평 분할)

• 데이터의 개수를 기준으로 나누어 Partitioning 합니다.
• 데이터의 개수가 작아지고 따라서 index의 개수도 작아지게 되면서 성능이 향상됩니다.
• 하지만 예를 들어 최댓값을 구해야 한다면 데이터를 찾는 과정이 기존보다 복잡하기 때문에 latency가 증가됩니다.
• 하나의 서버가 고장 나게 되면 데이터의 무결성이 깨질 수 있습니다.

https://nesoy.github.io/articles/2018-02/Database-Partitioning

구현

주로 application level에서 실행됩니다.

여기서 application이란 어떤 shards에 읽기와 쓰기를 전송할지를 정의하는 코드를 포함하고 있는 것을 말합니다.

일부 DBMS에서는 지원하기도 합니다.

 

운영시 설정 정보 변경으로 쉽게 증설이 가능하도록 샤딩을 2가지 기법을 활용하여 설명한 글을 읽으시면 어떻게 이루어지는지 이해하실 수 있습니다.

https://techblog.woowahan.com/2687/

 

긴 글을 읽기 귀찮으신 분들을 위해서 요약하자면 application level에서 이루어진다는 것은 우리가 작성하는 비즈니스 로직에서 데이터베이스로 저장하기 전에 어떤 데이터베이스에 저장할지를 개발자가 구현해야 합니다.

 

 

Sharding의 장점과 단점

 

장점

• 수평적 확장(Scale out)이 가능하다. (서버의 하드웨어를 업그레이드하지 않고 서버에 DB를 1개 더 추가하는 방식)
• 스캔 범위를 줄이기 때문에 속도가 빨라진다.
• DB에 장애가 났을 때 애플리케이션이 일부라도 동작할 수 있도록 위험을 완하 시킵니다.

단점

• 데이터가 한쪽으로 쏠리게 되면 sharding이 무의미 해집니다.
• 한 번 쪼개게 되면 다시 un-sharded 구조로 돌리기 어렵다.
• Sharding-db 간에 조인이 불가능합니다.(shard의 목적이 대용량 데이터 처리이므로 데이터 처리와 데이터의 중복은 trade-off관계입니다. 처음부터 역정규화를 감수하거나 다른 방안을 모색해야 합니다.) line Manga에서는 Redis에 저장하여 조회하는 방식을 사용했습니다.

 

 

 

Sharding 기법들

여러 가지 Sharding 방법들이 있지만 2가지만 알아보겠습니다.

 

두 가지 기법의 공통된 요구사항은 아래와 같습니다.

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

 

 

Modular sharding

https://techblog.woowahan.com/2687/

모듈러 샤딩은 PK를 모듈러 연산한 결과로 DB를 특정하는 방식입니다.

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

 

모듈러 샤딩은 데이터량이 일정 수준에서 유지될 것으로 예상되는 데이터 성격을 가진 곳에 적용할 때 어울리는 방식입니다.

 

예를 들어 데이터의 유지기간이 24시간으로 제한되어 있다면 데이터가 항상 쌓이기만 하는 상황이 아닙니다.

이런 경우 모듈러 샤딩을 적용하기에 알맞습니다.

 

물론 데이터가 꾸준히 늘어날 수 있는 경우라도 적재 속도가 그리 빠르지 않다면 모듈러 방식을 통해 분산 처리하는 것도 고려해볼 법합니다.

 

 

Range sharding

https://techblog.woowahan.com/2687/

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

장점 : 모듈러 사딩에 비해 기본적으로 증설에 재정렬 비용이 들지 않습니다.

단점 : 일부 DB에 데이터가 몰릴 수 있습니다.

 

가장 큰 장점은 증설 작업에 드는 비용이 크지 않습니다.

데이터가 급격히 증가할 여지가 있다면 레인지 방식도 좋은 선택이 됩니다.

 

하지만 활성 유저가 몰린 DB로 트래픽이나 데이터량이 몰릴 수 있기 때문에 부하분산을 위해 해당 DB를 쪼개 재 정렬해야 할 수도 있습니다. 

 

또한 트래픽이 저조한 DB는 통합작업을 통해 유지비용을 아끼도록 관리해야 합니다.

 

 

 

결론

샤딩은 데이터베이스 수평 확장을 고려할 때 좋은 해결책이 될 수 있습니다.

하지만 일부 그룹에서는 샤딩이 주는 이점보다 샤딩 아키텍처를 만들고 유지하는데 드는 시간과 비용이 압도적일 수 있습니다.

 

또한 샤딩을 하기 전에 데이터베이스를 최적화할 수 있는 다른 옵션들도 검토해 보아야 합니다.

• 데이터베이스의 수직확장
• 읽기 퍼포먼스가 문제라면 캐싱 활용
• 읽기 DB와 쓰기 DB를 나누기

즉, 상황에 따라 유연하게 적용을 고려해야 합니다.

 

 

출처

https://techblog.woowahan.com/2687/

DB분산처리를 위한 sharding | 우아한형제들 기술블로그

https://velog.io/@matisse/Database-sharding% EC%97%90-%EB% 8C%80% ED%95%B4

(번역) Database sharding이란? 🔨

http://theeye.pe.kr/archives/1917

샤딩과 파티셔닝의 차이점 | 아이군의 블로그

https://engineering.linecorp.com/ko/blog/line-manga-server-side/

LINE Manga 데이터베이스 샤딩 – 서버 엔지니어 편 - LINE ENGINEERING