[데이터베이스] 클러스터링 & 리플리케이션 & 샤딩

 

목차

1. 클러스터링(Clustering)
2. 리플리케이션(Replication)
3. 샤딩(Sharding)

 

 

---

1. 클러스터링(Clustering)

클러스터링이란 여러 개의 DB 서버가 하나의 데이터베이스를 공유하도록 구성하는 것을 의미한다. 아래와 같이 DB 서버 1개에 데이터베이스가 1개인 경우 DB 서버가 죽어버리면 서비스를 할 수 없게 된다. 이를 해결하기 위해 2개 이상의 DB 서버를 두어 가용성을 향상시키는 클러스터링이라는 방법을 사용한다.

단일 서버 - 단일 DB

 

클러스터링의 운영 방식은 Active-Active 방식와 Active-Stand by 방식으로 나뉜다. 

 

Active-Active 방식

두 개의 DB 서버가 존재한다고 가정할 때, 두 개의 서버 모두 작동시키는 방식이며, 아래와 같은 장단점을 가진다.

장점
1. 가용성이 높다
2. 두 개의 서버를 통해 로드밸런싱이 가능하다.

단점
1. 두 개의 서버가 자원에 접근하기 때문에 병목이 발생할 수 있다.
2. 두 개의 서버를 동시에 작동시키기 때문에 비용이 많이 든다.

 

 

Active-Stand by 방식

한 개의 DB 서버만 작동시키고, 다른 하나의 서버는 대기를 시켜서 작동 중인 서버에 장애가 발생할 때 대기중인 서버를 작동시키는 방식이다. Active- Stand by 방식의 특징은 아래와 같다.

장점
1. 하나의 서버만 작동하기에 병목이 상대적으로 적다.
2. 하나의 서버만 운영하기에 비용이 적게 든다.

단점
1. 가용성이 상대적으로 낮다(대기 -> 작동 까지의 시간동안 서비스 불가)
2. 로드밸런싱이 불가능하다

 

 

클러스터링 정리

클러스터링(Clustering) - 1개의 DB에 여러 개의 DB 서버와를 두는 방식

종류
1. Active-Active : 두 개의 서버 모두 작동
2. Active-Stand by : 한 개만 작동시키고, 한 개의 서버는 대기

장점
여러 개의 서버를 두어 가용성을 향상시킨다.

 

 

---

2. 리플리케이션(Replication)

클러스터링을 통해 서버의 개수만 늘린다고 해서 모든 문제가 해결된 것은 아니다. 하나뿐인 데이터베이스에서 장애가 발생하게 된다면 서비스가 제대로 되지 않는 것은 마찬가지이다. 이를 위해 백업용 DB를 두는 리플리케이션이라는 개념이 등장한다. 기존 DB를 Master, 백업용 DB를 Slave라고 하는 Master - Slave 구조를 통해 리플리케이션을 활용한다.

 

 

백업용 DB를 만들어서 데이터 손실을 방지할 수 있게 되었으나, 위 구성의 단점은 DB 서버가 존재함에도 놀고만 있다는 것이다. 이를 개선하기 위해 검색 작업은 Slave 쪽에서 처리하게 함으로써 트래픽을 분산시킨다.

 

리플리케이션을 사용하여 데이터를 백업, 트래픽 분산, 가용성 향상 등의 이점이 생기지만 단점 역시 존재한다. 우선, Slave의 경우 비동기 방식으로 Master 와 동기화하기 때문에 데이터의 동기화를 보장하지 못한다. 또한, Master 에서 장애가 발생하는 경우 복구 및 대체가 까다롭다는 특징이 있다.

 

 

리플리케이션 정리

리플리케이션(Replication) - DB 장애에 대비해서 여러 개의 DB를 두는 작업
특징
1. Master - Slave 구조
2. Master: INSERT,UPDATE,DELETE 작업 수행
   Slave : SELECT 작업 수행

단점
1. 비동기방식으로 동기화를 하기 때문에 동기화를 보장하지 못한다.
2. Master에 장애 발생 시 복구 및 대처가 까다롭다.

 

 

---

3. 샤딩(Sharding)

앞서 클러스터링과 리플리케이션이 가용성 향상을 위한 아키텍처라면, 샤딩은 검색 성능 향상을 위한 아키텍처이다. 만약 DB에 100억, 1000억개의 데이터가 존재한다고 가정할 때, 해당 DB에서 검색을 하게 되면 많은 시간이 소요될 것이다. 이를 위해 테이블을 특정 기준으로 나눠서 저장 및 검색을 하게 된다. 이때, 나눠진 테이블 조각을 샤드(Shard)라고 한다.

 

 

테이블을 여러 개의 샤드를 두어 저장할 때, 어떤 기준을 가지고 데이터를 분산시킬지 고려해야한다. 이때의 분산 기준을 샤드키(Shard Key) 라고 하며, 대표적으로 3가지 방식이 존재한다. 1,2번은 NoSQL에서 사용이 되며, 3번은 RDBMS에서 활용된다. 상황에 따라 1,2,3 중 하나를 선택하면 된다.

1. Hash Sharding
2. Dynamic Sharding
3. Entity Group

 

 

1. Hash Sharding

샤드의 개수를 통해 해시함수를 만들고, id를 해시함수에 넣어 해당 결과값을 통해 데이터를 분산시키는 방식이다. 아래 그림처럼 4개의 샤드가 존재할 때, [ id % 샤드 수 ]라는 해시함수를 통해 결과값에 해당하는 샤드로 데이터를 분산시킨다.

 

해시 샤딩은 간단하지만 확장성이 낮다는 단점이 존재한다. 샤드의 수를 증가시키면 해시함수를 변경해야하며, 샤드간 데이터의 양도 불균형이 발생하기 때문에 Resharding 이 필요하다. 

 

 

2. Dynamic Sharding

해시 샤딩의 단점을 보완하기 위한 방식이 동적샤딩(Dynamic Sharding)이다. 아래 그림과 같이 Locator Service 라는 테이블을 두어 데이터 분산을 관리한다.  

동적 샤딩은 샤드 수가 증가하더라도 샤드키만 추가하면 되기 때문에 확장이 유연하다는 장점을 가진다. 하지만, Locator Service에 장애가 발생하는 경우 나머지 샤드에서도 문제가 발생한다는 단점이 존재한다.

 

 

3. Entity Group

엔티티 그룹은 연관성이 있는 엔티티들을 한 샤드에 두는 방식이며, 빠른 검색이 가능하다는 특징을 가진다. 데이터는 사용자 별로 분리되어 특정 샤드에 저장이 된다. 

 

 

엔티티 그룹은 같은 샤드에 있는 데이터를 조회시 효과적이지만, 다른 샤드에 있는 데이터를 같이 조회하는 경우 성능이 떨어진다는 단점을 가진다.

 

 

샤딩 정리

샤딩(Sharding) - 테이블을 여러 개로 나누는 작업

종류
1. 해시샤딩(Hash Sharding)
> 간단하지만 확장성이 낮음
> NoSQL에서 사용

2. 동적샤딩(Dynamic Sharding)
> Locator Service라는 테이블을 두어 확장성을 높임
> Locator Service가 단일 장애점이 될 수 있음
> NoSQL에서 사용

3. 엔티티그룹(Entity Group)
> 연관성 있는 데이터는 같은 샤드에 두는 방식
> 다른 샤드에 있는 것을 같이 참조시 성능이 떨어짐
> RDBMS에서 사용

 

 

 

[참고 링크]

https://jordy-torvalds.tistory.com/94

https://www.whatap.io/ko/blog/172/

https://nesoy.github.io/articles/2018-05/Database-Shard