[DB]분산 저장 기법(파티셔닝,샤딩,레플리케이션)의 개념
개 요
개발을 하는데에 있어서 서비스의 성능향상 또는 안정화에 관한 문제는 항상 고려해야하고 그만큼 중요하다. 가령 대부분의 서비스에서 클라이언트-서버와 통신을 할 때 데이터 I/O는 필수적이라고 볼 수 있고 그만큼 이용하는 유저들이 늘어났을 때의 트래픽을 감당하기 위한 적절한 조치와 방법을 찾아야한다. 다양한 방법이 존재하지만 이 포스팅에서는 서버가 DB와 통신해 데이터 I/O 작업을 할 때 이슈를 최소화하고 성능을 향상시키는 대표적인 방법(파티셔닝, 샤딩, 레플리케이션)에 대해서 알아보려고 한다.
개 념
파티셔닝(Partitioning)
파티셔닝이란 데이터베이스를 특정 조건을 적용해 여러 부분으로 분할하는 것이다. 하나의 DBMS에 데이터가 너무 큰 테이블이 들어가면서 용량과 성능 측면에서 이슈가 발생할 때 테이블이나 인덱스를 작은 파티션 단위로 나누어 사용하는 기법이다.
샤딩(Sharding)
샤딩이란 같은 테이블 스키마를 가진 데이터들을 다수의 DB에 분산해서 저장하는 기법을 뜻한다. Shard key 라고 알려진 키를 기준으로 데이터가 나뉘며 Shard key 알고리즘에 따라 여러 샤딩이 존재한다. 또한 샤딩은 여러 서버에 스키마가 복제된다.
레플리케이션(Replication)
여러 개의 DB를 수직적인(Master - Slave)구조로 구축하는 방식, Master Node에서는 쓰기 작업만, Slave Node에서는 읽기 작업만 처리하며 비동기 방식으로 Replication해서 각 노드들 간의 데이터를 동기화한다.
단, Replica와 Replication은 단어는 비슷해보이지만 각기 다른 개념이다. Replication은 완전 복제는 아니고 동일한 DB서버가 Active-StandBy 환경일 때 주로 사용된다. CDC(Change Data Capture의 약자로 로그파일을 읽어 데이터를 긁어오는 방식)가 대표적인 Replication에 해당된다. Replication은 데이터를 읽어서 대상에 복제하는데에 딜레이가 생기기 때문에 메인 서버에 문제가 발생할 경우 Slave서버에 모든 데이터가 반영됐다는 보장이 없다. 반면 Replica는 완전한 복제로 Commit된 순간부터 두 개의 DB 인스턴스는 동일한 데이터를 가져야하고 데이터의 원자성(모두 반영되거나 안되거나)이 유효해야한다. 때문에 Acitve-Active 환경으로 구조를 구성할 수 있다.
그렇다면 여기서 한 가지 의문점이 들 것이다.
"파티셔닝과 샤딩은 비슷한거 같은데?"
얼핏 보기에는 나눈다는 기준에서 보았을 때는 비슷해 보일수도 있지만 파티셔닝 종류 중에서도 수평 파티셔닝은 같은 스키마에 다른 테이블로 쪼개서 저장하고 샤딩은 나눈 데이터들을 Shard key를 기준으로 스키마를 복제하여 다른 DB에 저장한다는 차이점이 있다.
왜 사용하는 걸까?
위와 같은 방식의 데이터 분산저장기법을 왜 사용하고 또 어떤 상황일 때 사용해야 하는 걸까? 큰 틀에서 보자면 한 저장공간에 너무 많은 데이터가 들어가게 되면 데이터의 I/O 작업에서 성능저하 등의 이슈가 생겨 데이터를 분할하는 기법을 사용하는 것이다. 각 기법별 세부적으로 사용이유(또는 장점)에 대해 알아보자.
파티셔닝
- 파티션별 연산으로 I/O분산이 가능하여 성능이 향상
- 파티션별로 백업 및 복구가 가능
- 전체 데이터를 손실할 가능성이 줄어든다.
하지만 테이블이 여러개로 나누어지기 때문에 테이블간 JOIN연산에 대한 비용이 증가하고 테이블과 인덱스를 별도로 파티셔닝할 수 없다.
샤딩
- Request에 대한 부하를 서로 다른 샤드가 있는 여러 서버에 분산이 가능하다.
- DB 스키마를 유지하기 때문에 DB확장에 용이하다.
- 이 외 수평 파티셔닝과 동일하다.
하지만 프로그램 복잡도가 높아지고 서버 간의 연결 과정이 많아져 비용이 증가한다. 또한 하나의 서버가 고장나면 데이터 무결성이 깨질 수도 있으며 한번 샤딩을 사용하면 샤딩 이전의 구조로 돌아가기가 힘들다. 때문에 잘못 사용할 경우 리스크가 크다.
레플리케이션
- DB작업의 대부분이 Select(읽기) 작업이기 때문에 Replication만으로도 충분히 성능을 높일 수 있다.
- 비동기 방식으로 동기화되어 지연시간이 거의 없다.
- Master DB가 장애가 발생할 경우 MHA를 이용해 Slave DB를 Master DB로 승격시켜 빠른 서비스 복구가 가능하다.
하지만 각각 다른 서버에서 운영하다보니 버전 동기화를 해야하고 최소 Slave버전이 Master버전보다 높아야한다. 또한 비동기 방식으로 데이터를 동기화하면 일관성있는 데이터를 얻어오지 못할 수 있다. 마지막으로 Master DB가 장애가 발생하면 복구 및 대처가 까다롭다는 단점이 있지만 MHA를 이용해 해결이 가능하다.
각 기법별 종류(방법)는?
파티셔닝
Column을 기준으로 나누는 수직 파티셔닝, Row를 기준으로 나누는 수평 파티셔닝이 있다.
수평 파티셔닝은 데이터의 갯수를 기준으로 나누어 파티셔닝을 하고 때문에 데이터와 인덱스의 갯수가 줄어들어 성능 향상에 도움이되지만 데이터를 찾는 과정이 기존보다 복잡하기 때문에 레이턴시가 증가한다.
수직 파티셔닝은 같은 타입의 데이터가 저장되어 데이터 압축률을 높일 수 있고 조회 시 필요 없는 컬럼을 조회하지 않아도 되므로 성능향상에 도움이 된다. 하지만 수평 파티셔닝과 동일하게 데이터를 찾는 과정이 기존보다 복잡하다.
또한 파티셔닝에서 데이터를 분할하는 4가지 분할기준이 있다. (수평 분할에 해당)
1. 범위분할(Range)
- 연속적인 숫자나 날짜를 기준으로 파티셔닝(ex : 분기별)
- 분할 키 값이 범위 내에 있는지 여부로 구분
- 우편번호, 날짜 등의 데이터에 적합
2. 목록 분할(List)
- 값 목록에 파티션을 할당하고 분할 키 값을 그 목록에 비추어 파티션을 선택한다. (ex : Country컬럼 값이 Norway, Finland, Sweden인 값들을 묶으면 임의의 기준을 가지고 북유럽 국가 파티션이라는 이름으로 나눔)
3. 해시 분할(Hash)
- 파티션 키의 해시 값에 의한 파티셔닝(인덱스를 해시함수를 통해 분류)
- 균등한 데이터 분할 가능
- 데이터 관리보다는 성능향상에 목적
- 특정 데이터가 어느 Hash 파티션에 있는지 판단 어려움
- 범위가 없는 데이터에 적합
4. 합성 분할(Composite)
- 위 분할법들을 조합하여 파티셔닝
5. 라운드로빈(Round Robin)
- CPU 스케줄링 알고리즘에서 알고 있는 라운드로빈 방식과 동일하다. (하나의 중앙처리장치를 여러 프로세스들이 조금씩 돌아가며 할당받아 실행)
- 파티션에 행의 고른 분포를 원할 때 사용한다.
- 회전하면서 새로운 행이 파티션에 할당된다.
샤딩
1. 해시샤딩(Hash Sharding) (모듈러 샤딩이라고도 함)
- Shard Key는 DB id(pk)를 Hashing하여 결정
- 레인지샤딩에 비해 데이터가 균일하게 분산된다
- 클러스터가 포함하는 Node갯수를 변경하면 해시크기가 변경되고 key또한 변경되어 ReSharding이 필요
- 일정 수준에서 유지될 것으로 예상되는 데이터 성격을 가진 곳에 적절
2. 레인지 샤딩(Range Sharding)
- 해시샤딩에 비해 기본적으로 증설작업에 재정렬 비용이 들지 않고 증설작업에 드는 비용이 크지 않다.
- 활성유저가 몰린 일부 DB에 데이터가 편향될 수도 있다.
마치며
서버 개발자의 꽃은 적은 비용으로 최대한의 부하를 잡는 것이라고 생각한다. 지금도 전 세계 여러 훌륭한 개발자분들이 다양한 방법을 연구하고 끊임없이 새로운 기술이 도입되고 있기 때문에 항상 관심을 가지고 있어야한다고 생각한다. 오늘 포스팅 했던 이 방법들은 널리 알려져 있고 또 쓰이는 방법들이니 꼭 숙지해야한다고 생각하며 이번 포스팅에는 분산 저장 기법의 대표적인 방법에 대한 개념을 포스팅 했지만, 조만간 사이드 프로젝트에서 분산 저장기법을 사용하여 그 과정들을 따로 포스팅 할 예정이다.
참고 포스팅
https://yunamom.tistory.com/291
https://soye0n.tistory.com/267
https://silight.tistory.com/21
https://tecoble.techcourse.co.kr/post/2021-09-18-replication_clustering/
https://cornswrold.tistory.com/561
https://gmlwjd9405.github.io/2018/09/24/db-partitioning.html
https://code-lab1.tistory.com/202
https://bryceyangs.github.io/study/2021/06/01/Database-Sharding-&-Replication-&-Clustering/