[TIL] DB Replication이란? 읽기 부하를 줄이고 고가용성을 확보해보자

팀프로젝트를 하면서 구현했던 Redis master-slave 구조를 회고하다가 DB Replication(데이터베이스 복제) 에 대해서도 이번 기회에 정리해보려고 한다.
요즘 시스템 아키텍처를 고민하다보면 빠질 수 없는 주제 중 하나가 ‘데이터베이스의 고가용성과 확장성’인 것 같다. 이 두 가지를 동시에 잡으려고 할 때 꼭 등장하는 기술이 바로 Replication이다.

 

💡 DB Replication이란?

Replication은 한 데이터베이스에서 다른 데이터베이스로 데이터가 동기화되는 것으로, DB를 다중화하는 것을 말한다. 즉, 한 데이터베이스의 데이터를 다른 데이터베이스로 실시간 또는 주기적으로 복제하는 기술이다.

 

다시 또 쉽게 말하면, Master(DB 원본)에서 Slave(DB 복제본)로 데이터를 복제해서 여러 DB 인스턴스가 동일한 데이터를 가지도록 만드는 거다.

 

특히 대규모 애플리케이션 환경에서는 데이터의 지속적인 가용성과 신뢰성이 매우 중요하기 때문에, 원본 서버와 복제 서버 간의 데이터 동기화는 필수다. (쓰기 요청은 Master, 읽기 요청은 Slave 구조가 일반적이다)

 

 

💡어떻게 Replication 방식으로 과부하 문제를 해결할 수 있는걸까

Replication은 Master DB에는 Insert, Update, Delete 작업을 수행하도록 하고 Select 작업을 Slave DB에서 하도록 구성한다.

 

왜 Select 작업만 따로 뺄까에 대한 의문이 생길 수 있다. 그 이유는 보통 select 작업이 시간이 많이 걸리기 때문이다. (e.g. 데이터가 5만개가 있을때, Table Full Scan을 해야 한다면 매우 많은 시간이 소요될 것이고, 이 시간동안 다른 작업을 하지 못하게 되니 병목 현상의 주요 원인이 될 수 있는 것)

 

💡왜 Replication을 쓰는 걸까

1. 부하 분산 (Load Balancing)

위에서 설명한 것 처럼, 쓰기(INSERT/UPDATE/DELETE)는 Master에서, 읽기(SELECT)는 Slave에서 처리함으로써 성능 병목을 줄일 수 있다.

예를 들어, 상품 조회가 많은 이커머스 사이트에서 SELECT 쿼리를 전부 Master에서 처리하게 되면 금방 병목이 생길 수 있다. 이럴 땐 읽기 부하를 복제본으로 분산시키면 효과가 클 것이다.

2. 고가용성 (High Availability)

Master가 장애 나더라도 Slave를 승격시켜 서비스 중단 없이 운영할 수 있다.
(자동으로 Slave를 Master로 승격시킬 수 있음, 예를 들면 AWS RDS의 Multi-AZ 서비스나 Redis의 Sentinel 구조)

3. 데이터 백업 및 장애 복구

Master의 데이터를 실시간으로 복제해두면, 데이터 유실 시 Slave를 Master로 전환해서 빠르게 복구할 수 있다. 이를 통해 데이터 유실을 최소화할 수 있고, 백업 데이터가 있어 재해 복구에 용이하게 대처할 수 있다. 

(금융 서비스에서 데이터 손실 방지를 위해 Multi-Region Replication을 적용 가능하다)

4. 글로벌 서비스 대응

지리적으로 떨어진 지역에 Replica를 배포하면 사용자는 가까운 곳의 DB에서 빠르게 응답을 받을 수 있다.
(Netflix는 미국, 유럽, 아시아 등에 Replica를 배치하여 빠른 응답 속도를 제공해주고 있다)

 

💡언제 쓰면 좋을까

꼭 트래픽이 몰리는 상황이 아니더라도 다양한 상황에서 DB Replication을 통해 고가용성을 달성할 수 있다.

• 특정 시점에 트래픽 폭주가 예상되는 경우 (부하를 분산해야 할 경우)
• SELECT 쿼리 비중이 높은 서비스 (검색, 피드, 조회 등)
• 데이터 분석, 통계 작업 등 부하가 큰 작업을 따로 처리하고 싶을 때 
• 장애 복구 대비 백업 전략이 필요할 때 (e.g. 데이터베이스가 자꾸 죽을경우, 복제를 이용해 예비용 서버를 만들 수 있다)

즉, 읽기 부하가 많고 고가용성이 중요한 서비스에 적합하다.

 

💡장점 정리

여태까지 나온 DB Replication의 특징들로 장점을 정리해보자.

장점	설명
읽기 성능 향상	Replica에서 Select 처리 가능
고가용성 확보	장애 시 빠른 전환(failover) 가능
실시간 백업	데이터 유실 최소화
글로벌 서비스 대응	지연 시간(latency) 감소

 

장점이 있다면 단점도 존재하겠지? 단점 또한 알아봤다.

 

💡단점 정리

1. 데이터 정합성을 보장할 수 없음

Slave는 Master의 복사본을 사용하기 때문에 그것이 정말 완벽하다고 할 수 없다.

예를 들어 Slave가 Master의 쿼리 처리량을 따라가지 못한다면 데이터 정합성이 보장되지 않는다. (쇼핑몰에서 결제 완료 후에도 상품 재고 수량이 실시간으로 반영되지 않는 문제가 발생 가능하다)

2. Binary Log File 관리

Master는 Binary Log가 무분별하게 쌓이는 것을 막기 위해 데이터 보관 주기를 설정한다. 하지만 Master는 Slave까지 관리 하지 않기 때문에 Master에서 Binary Log File을 삭제했다고 Slave에서 Binary Log를 삭제하지 못한다.

3. 복잡한 관리 & 운영 비용 증가

기본적으로 master에서 에러가 발생해 서버가 내려갔을 경우 Slave로 Failover 하는 기능을 지원하지 않는다. 따라서 DB 장애 시 Replica 승격(Failover) 해주는 설정과 로드밸런싱 관리가 필요하다. 또 여러 개의 DB 인스턴스를 운영해야 하므로 관리 부담이 증가한다.

4. 쓰기 성능 저하 (쓰기 부하 분산 어려움)

쓰기(INSERT, UPDATE, DELETE) 요청은 Primary에서만 처리해야 하므로 부하가 집중될 수 있기 때문에, 쓰기 요청을 분산하려면 추가적인 샤딩 전략이 필요하다. (e.g. 고트래픽 서비스(예: SNS, 블로그)에서는 Replication 만으로는 쓰기 부하 해결이 어렵다)

5. 데이터 유실 가능성

비동기 복제 사용 중 Primary에 장애가 발생하면, 일부 데이터가 Replica로 복제되지 않을 위험이 있다. 동기 복제를 사용하면 해결 가능하지만, 쓰기 성능이 저하된다. (e.g. 트랜잭션이 Primary에만 커밋되고 Replica로 반영되지 않은 상태에서 장애 발생 시 데이터 유실 가능)

 

✏️ 결론

DB는 기본적으로 Read 작업에서 자원 소모가 많기 때문에 Read 작업이 많아 성능 이슈가 발생하는 경우 가장 먼저 고려해볼 전략이 DB 복제라고 생각한다. Replication을 적용하면 성능 향상을 체감할 수 있지만, 단점 또한 치명적이기 때문에 만능이라고 할 수는 없다.

위에서 정리한 것 처럼,

• 읽기 부하가 많은 서비스 → Replication 활용
• 쓰기 부하가 많은 서비스 → 샤딩(Sharding)과 함께 고려
• 장애 발생 시 데이터 정합성이 중요한 서비스 → 동기 복제 사용 고려

Use Case에 따라 적절한 Replication 전략을 선택하는 것이 중요할 것이다.