DB Clustering & Replication, DB must go on

서비스의 심장과도 같은 Database가 멈춘다면 어떻게 될까? 당연히 서비스는 제 기능을 하지 못할 것이고 멈춰있는 시간동안 서비스 기능 장애 뿐만 아니라, 데이터 손실 등의 문제에 직면하게 된다면 그 피해가 심각할 수도 있다.

심장은 계속 뛰어야만 한다, 그리하여 오늘은 DB 부하 분산 기법인 Clustering과 Replication 방식에 대해 알아보자.

Clustering

Clustering은 여러개의 DB 서버에 적절히 부하를 분산시키는 (로드밸런싱) 구조다.

당연히 DB 하나가 죽어도 곧바로 대비가 가능하며 고가용성을 보장한다.

보통 수평적 구조를 가지며 세부적으로 모든 DB 서버를 Active 상태로 둘 수도 있고 Active 상태와 Standby 상태를 섞어서 사용한다.

모든 DB 서버가 Active 상태라면 무중단 서비스 이용이 가능해지며, 같이 사용되어 성능적인 이득이 있지만, 저장소 하나를 공유하면 병목현상이 발생될 수 있다.

또한 비용이 많이 들게 된다.

Active 상태와 Standby 상태를 섞어서 사용한다면 당연히 적은 비용이 들게되겠지만, Standby 상태의 DB가 Active로 전환되는 소요시간이 존재하기 때문에 무중단 서비스는 어려워진다.

Replication

Replication은 두 개 이상의 DB를 Master DB와 Slave DB로 나누는 수직적 구조를 가진다.

각각의 Slave DB는 Master DB의 Replica다.

보통 Slave DB는 ReadOnly 설정을 하여 직접 수정사항을 반영하지않고 Masater DB에 수정사항이 생기면 복사한다.

즉, Master DB에는 CUD 작업을, Slave DB에는 Read 작업만을 하여 가장 부하가 심한 Select 작업을 따로 하게되어 DB 성능에도 도움이 된다.

복제는 MySQL의 경우 비동기 복제 방식을 사용하여, Master DB의 노드에서 변경되는 데이터에 대한 이력을 로그에 기록하고 Replication Master Thread가 비동기적으로 로그를 읽고 Slave DB로 전송한다.

만약 Master DB가 죽으면, 그 즉시 다른 Slave DB가 Master DB로 승격하여 가용성을 높여주도록 사용된다.

이러한 Replication 방식도 만능은 아니다.

Slave DB가 Master DB의 단순한 Replica인 것이 Replication 방식의 단점이다.

무슨 얘기냐하면 그 복제본이 정말 완벽하게 똑같지 않을 가능성이 있다는 것이다.


DB의 로드밸런싱을, 고가용성 등을 위한 여러가지 방식들이 있으니 적재적소에 필요한 DB 설계 구조를 가져가도록 하자.

Thanks for watching, Have a nice day.