클러스터링, 레플리카, 그리고 샤딩

 

클러스터링

 

예시를 하나 들어보자. DB를 한 대만 운영 할 경우 문제점은, DB 서버가 죽으면 관련된 서비스 전체가 중단된다는 점이다.

이에 대한 가장 간단한 방안으로 DB 클러스터(Cluster)가 있다.

 

클러스터를 구성하는 것이 클러스터링이다.

 

동일한 DB 서버를 두 대를 묶고 두 DB 서버를 Active-Active 상태로 운영하면, 하나의 DB서버가 죽더라도 나머지 DB 서버가 살아있기 때문에 정상적으로 서비스가 가능하다. 또한 이전에 하나의 서버가 부담하던 부하를 두 개의 DB에 나눠서 감당하므로 CPU, Memory 관리 차원에서 효율적이다.

 

단점으로는 DB 스토리지를 두 DB 서버가 공유하기 때문에 병목이 발생할 수 있다는 점이다.

그리고 DB를 1개만 사용하는 것 보다는 2대 이상을 운용하는 것이 더 많은 비용이 발생한다. 

 

병목현상을 해결하기 위해서는 두 DB 중 한 대를 Stand-by로 두는 것이다. 말 그대로 준비 상태로 두고 Active 상태의 DB에 문제가 발생할 경우 Fail Over을 통해 두 서버가 Active와 Stand-by 상태를 상호 전환홤으로써 장애를 대응하는 것이다.

 

물론 여기에도 자잘한 문제점은 있다. Fail Over가 이뤄지는 수초 ~ 수분 간의 시간 동안에는 영업 손실이 필연적으로 발생한다는 점이다.

또한 결론적으로는 DB 서버 2대를 구비해야하기 때문에 비용은 전과 동일하지만 효율은 이전보다 약 1/2이하로 나온다는 것이다.

 

 

레플리케이션이란?

 

 

클러스터링을 보완하기 위해 나타난 개념이다.

유저가 마스터 DB 서버에 DML(Select, Insert, Update, Delete) 작업을 진행하면 Master DB는 그 데이터를 Slave에 데이터를 복제한다. 이를 통해 DB 스토리지가 한 대여서 발생할 수 있는 데이터 손실을 방지할 수 있다.

 

위 구성의 단점은 Slave인 DB 서버가 놀게 된다는 점이다.

그래서 Master DB 서버에는 Insert, Update, Delete 작업을 하고 Slave DB 서버에는 Select를 함으로써 양쪽 DB 서버에 분산을 할 수 있다. 

 

단, 여기서도 세세한 단점이 발생하는데, 만약 테이블 자체에 데이터가 엄청나서 Slave DB 서버를 N대 늘려도 원하는 데이터를 테이블로부터 찾는데 많은 시간이 소요된다는 점이다.

 

 

샤딩

 

레플리케이션을 보완할 수 있는 것이 샤딩이다.

 

샤딩은 테이블을 특정 기준으로 나눠서 저장 및 검색하는 것이다. 샤딩의 핵심은 Data를 어떻게 잘 분산시켜 저장할 것인지, 그리고 어떻게 잘 읽을 것인지에 대한 결정이다. 

 

어떻게 데이터를 분산시킬것인가, 그에 대한 기준은 Shard Key 이다.

 

 

참고 자료

 

Jordy Tovalds Tech의 "Clustering vs Replication vs Sharding"

Clustering vs Replication vs Sharding