[Real MySQL 8.0 2] 16.1 복제 - 개요
데이터베이스를 사용하고 운영할 때 가장 중요한 두 가지 요소를 꼽으라면 바로 확장성(Scalability)과 가용성(Availability)이다. 서비스에서 발생하는 대용량 트래픽을 안정적으로 처리하기 위해서는 데이터베이스 서버의 확장이 필수적이며, 사용자가 언제든지 안정적인 서비스를 이용할 수 있게 하려면 DBMS 서버를 포함한 하위 시스템들의 가용성이 반드시 뒷받침돼야 한다. 이 두 요소를 위해 가장 일반적으로 사용되는 기술이 바로 “복제(Replication)”다. 이번 장에서는 MySQL에서 제공하는 복제는 어떤 것이고, 어떻게 구현돼 있으며, 어떻게 작동하는지, 복제를 활용해서 얻을 수 있는 이점은 무엇인지 자세히 살펴보겠다.
개요
복제는 한 서버에서 다른 서버로 데이터가 동기화되는 것을 말하며, 원본 데이터를 가진 서버를 소스(Source) 서버, 복제된 데이터를 가지는 서버를 레플리카(Replica) 서버라고 부른다. 소스 서버에서 데이터 및 스키마에 대한 변경이 최초로 발생하며, 레플리카 서버에서는 이러한 변경 내역을 소스 서버로부터 전달받아 자신이 가지고 있는 데이터에 반영함으로써 소스 서버에 저장된 데이터와 동기화시킨다.
대부분의 DBMS에서 복제 기능을 제공하며, 일반적으로 서비스에서 사용될 DB 서버를 구축할 때는 메인으로 사용될 소스 서버 한 대와 복제를 통해 소스 서버와 동일한 데이터를 가진 레플리카 서버를 한 대 이상 함께 구축한다. 이는 서비스의 메인 DB 서버인 소스 서버에 문제가 생겼을 때를 대비하려는 목적이 제일 크지만 그 외에도 이처럼 복제를 통해 레플리카 서버를 구축하는 데는 여러 가지 목적이 있다.
1. 스케일 아웃(Scale-out)
서비스를 운영하다 보면 사용자가 늘어나고, 이에 따라 DB 서버로 유입되는 트래픽도 자연히 증가해 DB 서버의 부하가 높아진다. 현재 서비스에서 사용되는 DB 서버가 한 대라고 가정해보자. 트래픽이 증가해 DB 서버의 부하가 높아지면 여러 가지 조치를 취할 수 있겠지만 하나의 해결 방법으로 서버의 사양을 업그레이드하기도 한다. 이를 스케일 업(Scale-up)이라고 한다. 이 방법은 애플리케이션 단의 큰 변화 없이 늘어난 트래픽을 처리할 수 있다는 장점이 있지만 일시적이라는 단점도 있다. 서버의 사양을 업그레이드한다 하더라도 한 대에서 처리할 수 있는 양에는 한계가 있기 때문이다. 만약 동일한 데이터를 가진 DB 서버를 한 대 이상 더 사용할 수 있다면 애플리케이션으로부터 실행되는 쿼리들을 분산시킬 수 있을 것이다. 이 같은 방법을 스케일 아웃(Scale-out)이라고 하며, 스케일 아웃은 스케일 업 방식보다 갑자기 늘어나는 트래픽을 대응하는 데 훨씬 더 유연한 구조다. 복제를 사용해 DB 서버를 스케일 아웃할 수 있으며, 이를 통해 서비스를 좀 더 안정적으로 운영할 수 있다.
2. 데이터 백업
DB 서버에는 다양한 종류의 데이터가 저장되는데, 사용자의 실수로 데이터가 삭제되면 서비스 운영에 치명적인 영향을 줄 수 있다. 이러한 경우에 대비하기 위해서는 DB 서버에 저장된 데이터들을 주기적으로 백업하는 것이 필수적이다. 백업에 사용되는 툴들을 DBMS마다 종류와 방식이 다르지만 보통은 데이터가 저장돼 있는 DB 서버에서 백업 프로그램이 실행되어 백업을 진행한다. 이처럼 동일한 서버 내에서 백업이 실행되는 경우 백업 프로그램과 DBMS가 서버의 자원을 공유해서 사용하기 때문에 백업으로 인해 DBMS에서 실행 중인 쿼리들이 영향을 받을 수 있으며, 심각한 경우에는 쿼리의 처리 속도가 느려져 서비스에 문제가 발생할 수도 있다. 이 같은 문제를 방지하기 위해 주로 복제를 사용해 레플리카 서버를 구축하고, 데이터 백업은 레플리카 서버에서 실행한다. 이렇게 구축된 백업용 레플리카 서버는 소스 서버에 문제가 생겼을 때를 대비한 대체 서버의 역할을 하기도 한다.
3. 데이터 분석
DB 서버에서는 기본적으로 서비스에서 사용되는 쿼리들이 실행되지만 차세대 비즈니스 모델을 발굴하기 위해서나 서비스를 좀 더 발전시킬 수 있는 인사이트를 얻기 위해 분석용 쿼리들을 실행하기도 한다. 이러한 분석용 쿼리는 대량의 데이터를 조회하는 경우가 많고, 또 집계 연산을 하는 등 쿼리 자체가 굉장히 복잡하고 무거운 경우가 대부분이라서 쿼리를 실행할 때 서버의 리소스를 많이 사용하게 된다. 이로 인해 서비스에서 직접적으로 사용되는 다른 쿼리들이 영향을 받을 수 있으므로 복제를 사용해 여분의 레플리카 서버를 구축해 분석용 쿼리만 전용으로 실행될 수 있는 환경을 만드는 것이 좋다.
4. 데이터의 지리적 분산
서비스에서 사용되는 애플리케이션 서버와 DB 서버는 지리적으로 근접한 위치에 존재할 수도 있고, 혹은 장거리로 떨어져 있을 수도 있다. DB 서버와 애플리케이션 서버가 서로 떨어져 있는 경우 두 서버 간의 통신 시간은 떨어진 거리만큼 비례해서 늘어난다. 서비스의 응답 속도는 애플리케이션 서버의 처리 속도와 더불어 이러한 서버 간의 통신 속도에도 영향을 받으므로 사용자에게 빠른 응답 속도를 제공하려면 애플리케이션 서버와 DB 서버가 가깝게 위치하는 것이 좋다. 만약 떨어져 있는 DB 서버의 위치를 이동시키지 못한다면 복제를 사용해 애플리케이션 서버가 위치한 곳에 기존 DB 서버에 대한 레플리카 서버를 새로 구축해 사용함으로써 응답 속도를 개선할 수 있다.
Ref
- Real MySQL 8.0 2 - p.428 ~ p.430