이번 포스팅에서는, 데이터베이스 복제(Replication)에 대해 개념 설명과, 복제를 하는 목적을 설명하도록 하겠습니다.

복제란?

복제란 데이터베이스를 복제하는 것입니다.이렇게 말하면 큰일나겠죠?

데이터베이스 사용 및 운영에서 가장 중요한 두 요소는 확장성과 가용성입니다. 확장성은 대용량 트래픽을 안정적으로 처리하기 위해 서버를 확장하는 것이고, 가용성은 사용자가 언제든지 안정적인 서비스를 이용할 수 있는 것이죠. 이 확장성과 가용성을 얻기 위해 일반적으로 사용되는 기술중 하나가 복제입니다.

복제는 한 서버에서 다른 서버로 데이터베이스를 동기화시키는 기술입니다. 원본 데이터를 가진 서버를 소스 서버, 혹은 마스터 서버라고도 부르며, 복제된 데이터를 가진 서버를 레플리카 서버, 혹은 슬레이브 서버라고도 부릅니다.

윤리적인 문제로 요즘은 마스터-슬레이브 워딩을 잘 사용하지는 않는다고 하는데,이건 그냥 알아두기만 하면 될 것 같습니다ㅎㅎ

복제를 왜 쓸까?

그럼 복제를 왜 써야 하는지, 혹은 복제를 통해 어떻게 확장성과 가용성을 얻을 수 있는지 알아볼까요?

스케일 아웃

여러분의 서비스에 사용자 유입이 증가해서, 부하가 늘어나게 된다면, 서버 사양을 높여 해결하는 방법을 생각할 수 있을 것입니다. 이 방법은 애플리케션 단의 변화 없이도 트래픽을 처리할 수 있다는 점에서 안전하겠죠.

그러나 서버의 사양은 한계가 존재합니다. 서버가 람보르기니 같은 고급 사양을 가져도 결국 트래픽이 계속해서 늘어나면, 어느 시점에서 펑 하고 터져버리게 될 것입니다.

하지만 동일한 데이터를 가진 db 서버 한대를 더 사용할 수 있다면, 애플리케이션에서 실행되는 쿼리 요청을 분산할 수 있겠죠. 그만큼 서버가 가진 부하도 분산할 수 있을 것입니다. 이렇게 서버를 늘려 부하를 분산시키는 방법을 스케일 아웃이라고 합니다. 갑자기 늘어나는 트래픽을 처리하는데 훨씬 유연한 구조이죠.

따라서 복제를 통해 db서버를 스케일 아웃하여 서비스를 안정적으로 운영할 수 있습니다.

데이터 백업

하지만 여러분들이 운영하는 서비스에는 정말 많은 부하가 일어나고 있나요? 시비거는 건 아닙니다^^

그러나 실제로 서버에 문제가 생길 만큼의 트래픽이 없다면, 굳이 복제가 필요하지 않다고 생각할 수 있습니다. 하지만 사용자가 많지 않더라도, 복제가 할 수 있는 역할이 있습니다. 바로 데이터를 백업할 때인데요. db 서버에서는 데이터의 손실이 언제든 발생할 수 있으므로, 데이터의 주기적 백업은 중요합니다. 데이터 손실이 생기면 서비스 운영의 치명적 손실이 일어날 수 있기 때문이죠.

mysql에서는 바이너리 로그가 변경 사항을 기록하고 있지만, 바이너리 로그에 저장되는 크기는 용량 문제로 제한시키고 있으므로, 모든 변경 내용을 기록하고 있지 않습니다. 따라서 mysqldump와 같은 명령어를 통해 데이터를 백업합니다.

데이터의 백업은 보통 데이터가 저장된 db서버 내에서 진행됩니다. 하지만 이 경우 백업 프로그램과 dbms는 서버의 자원을 공유해서 사용합니다. 그래서 백업으로 인해 dbms에서 실행 중인 쿼리들이 영향을 받을 수 있습니다. (mysqldump와 같은 명령어를 사용할 때는 mysql 서버 전체에 글로벌 락을 걸게 됩니다.) 따라서 소스 서버에서 백업을 진행하면, 처리 속도가 느려지는 등 서비스에 문제가 갈 확률이 높습니다.

이 때, 복제를 사용해 레플리카 서버를 구축하고 데이터 백업을 이 곳에서 실행하면, 소스서버의 데이터 접근 및 조작에 문제가 갈 확률은 자연스럽게 줄어들 수 있겠죠. 또한 소스 서버에 문제가 생겼을 경우, 레플리카 서버를 소스 서버로 승격시켜 대체 서버의 역할을 할 수도 있을 것입니다.

데이터 분석

db 서버에는 보통 서비스 로직 처리를 위한 쿼리가 들어오지만, 새로운 비즈니스 모델을 발굴하기 위한 분석용 쿼리를 사용할 수도 있을 것입니다.

하지만 분석용 쿼리는 보통 대량의 데이터를 조회하거나, 집계 연산을 사용하는 등 무거운 작업을 수행하는 경우가 대부분입니다. 그만큼 서버의 리소스도 많이 사용하게 되겠죠?

따라서 분석용 쿼리는 레플리카 서버로 전송하도록 하면서, 서비스 로직을 처리하는 db 서버에 영향을 주지 않도록 할 수도 있습니다.

데이터의 지리적 분산

애플리케이션 서버와 db 서버는 지리적으로 가까울 수도, 멀 수도 있을 것입니다. 두 서버의 통신 시간은 떨어진 거리에 비례하겠죠? 만약 여러분의 서비스가 어마무시하게 유명해서 아프리카에서도 사용하게 된다면, 아프리카의 유저들은 우리나라 유저보다 느린 응답을 받을 수 밖에 없을 겁니다.

따라서 해당 국가에 복제 db서버와 애플리케이션 서버를 두어 응답 속도를 개선할 수 있을 것입니다. cdn과 비슷한 방식이죠.

다음 포스팅에서는 Mysql8.0 버전 이상을 기준으로, 복제가 진행되는 아키텍처에 대해 알아보도록 하겠습니다.