Clustering, Replication, Sharding

단일 DB 서버로 구성된 상황에서 트래픽이 몰리거나, 더 이상 단일 서버로 운영하기 어려워질 수 있습니다. 상황에 따라 필요한 방법은 다르지만, 대표적으로 쓰이는 Clustering, Replication, Sharding에 대해 설명합니다.

 

Clustering

클러스터링은 하나가 아닌 여러 개의 서버로 구성하는 것을 말합니다.

주목적: 가용성 + 부하 분산 예시: 서버 A가 죽어도 B가 요청을 이어받아 서비스가 멈추지 않고(가용성), 평소에는 두 서버가 요청을 나눠 처리한다(부하 분산).

위 상황은 단일 DB 서버를 통해 DB 스토리지에서 원하는 데이터를 서빙하는 상황입니다. 이때 DB 서버에 문제가 생길 경우, 해당 문제는 곧 서비스 전체 장애로 이어질 수 있습니다.

따라서 위와 같은 상황을 막기 위해 단일 DB 서버가 아닌, 2개 이상의 DB 서버를 사용할 수 있습니다.

 

Active & Active

2개 이상의 DB 서버를 동시에 운영한다면, A 서버에 장애가 발생해도 B 서버가 요청을 처리하여 서비스를 이어갈 수 있습니다.

또한 두 서버가 요청을 나누어 처리하므로, 기존 하나의 DB 서버가 받던 부하를 분산시킬 수 있습니다.

단점 또한 존재합니다.

1. 두 서버를 동시에 운영하는 만큼 서버 비용이 증가합니다.
2. 그림처럼 A 서버와 B 서버가 하나의 DB 스토리지를 공유한다면, 두 서버를 운영하더라도 같은 데이터에 대한 Lock 경합과 스토리지 부하가 남아 있을 수 있습니다. 즉 DB 서버를 늘려도 공유 스토리지가 병목 지점이 될 수 있습니다.

 

Active & Stand-By

Active & Stand-By는 평소에는 하나의 서버만 요청을 처리하고, 다른 서버는 장애에 대비해 준비해 두는 방식입니다. Active & Active처럼 두 서버가 동시에 트래픽을 나누어 처리하지는 못하지만, Active 서버에 장애가 발생하면 Stand-By 서버로 Failover하여 서비스를 이어갈 수 있습니다.

A 서버가 정상적으로 운영 중일 때는 B 서버가 사용자 요청을 처리하지 않습니다. A 서버에 문제가 생기면 Failover하여 B 서버가 Active 역할을 맡을 수 있습니다.

다만 Stand-By 서버가 항상 꺼져 있다는 뜻은 아닙니다. 장애를 얼마나 빨리 넘길지에 따라 준비 방식이 나뉩니다.

• Cold Standby: B 서버를 꺼 두거나 즉시 요청을 처리할 준비가 되지 않은 상태로 둡니다. A 서버에 문제가 생긴 뒤 B 서버를 시작하고 필요한 준비를 해야 하므로, 그 시간만큼 서비스가 중단될 수 있습니다.
• Hot Standby: B 서버를 이미 실행해 두고, 장애 발생 시 빠르게 Active 역할로 전환할 수 있도록 준비합니다. 전환 시간은 짧아지지만, B 서버를 계속 운영하는 비용이 필요합니다.

즉 Cold Standby는 비용을 줄이는 대신 장애 전환 시간이 길어질 수 있고, Hot Standby는 빠른 전환을 위해 비용을 더 지불하는 방식입니다.

또한 Active & Stand-By에서는 Stand-By 서버가 평소 사용자 요청을 처리하지 않으므로, 트래픽을 분산하는 목적으로는 사용할 수 없습니다.

 

Replication

Replication은 말 그대로 데이터를 복제하는 것을 의미합니다. 일반적으로 Master(Primary) 서버의 변경 데이터를 Slave(Replica) 서버에 전달하여, 여러 DB가 같은 데이터 사본을 유지하도록 합니다.

주목적: 읽기 확장 (부수적으로 가용성) 예시: 쓰기는 Master가, 조회는 여러 Slave가 나눠 맡아 조회 트래픽이 몰려도 견딤!

위 그림과 같이 쓰기를 처리하는 Master 서버와, Master 서버의 데이터를 복제한 Slave 서버로 나뉘게 됩니다.

대부분의 서비스는 글 작성보다 글 조회가 훨씬 많습니다. 따라서 Master가 모든 쓰기와 조회를 처리하는 대신, Slave에게 조회를 맡기면 Master는 데이터 변경에 집중할 수 있습니다.

또한 Master DB에 문제가 생겼을 때 Slave DB를 새로운 Master로 승격하여 Failover할 수 있도록 구성할 수 있습니다. 다만 승격과 애플리케이션의 연결 전환은 별도로 준비해야 합니다.

비동기로 복제하는 경우 Master의 변경 내용이 Slave에 반영되기까지 시간이 걸릴 수 있습니다. 이를 Replication Lag 라고 부릅니다.

즉 Replication은 조회 성능과 읽기 확장에는 좋지만, Slave에서 조회한 데이터가 항상 가장 최신 데이터는 아닐 수 있다는 점을 고려해야 합니다.

 

Sharding

Sharding은 데이터를 복사하는 것이 아니라, 여러 DB에 나누어 저장하는 방식입니다. 어떤 DB에 저장할지는 userId와 같은 Sharding Key를 기준으로 결정합니다.

주목적: 쓰기·저장 용량 확장 예시: 회원 200만 명 데이터를 한 DB가 감당 못 할 때, userId 기준으로 Shard 1·2에 나눠 저장합니다.

위 예시에서는 userId가 1부터 1,000,000까지인 데이터는 Shard 1에, 1,000,001부터 2,000,000까지인 데이터는 Shard 2에 저장합니다.

앞서 다룬 Replication에서는 Master와 Slave가 같은 회원 정보 전체를 들고 있지만, Sharding에서는 각 DB가 자기 몫의 데이터만 들고 있습니다. 따라서 데이터가 커, 하나의 DB 저장 공간이나 쓰기 처리량만으로 감당하기 어려울 때 Sharding을 고려할 수 있습니다.

다만 Sharding에도 단점이 존재합니다. 애플리케이션은 어떤 사용자의 데이터가 어느 Shard에 있는지 알아야 하며, 서로 분리된 Shard의 데이터를 함께 조회하거나 Join해야 하면 처리가 복잡하고 비용이 커집니다.

 

Partitioning

Partitioning도 데이터를 나누는 방법이지만, 하나의 DB 서버 안에서 테이블을 여러 조각으로 나누는 방식입니다. 반면 Sharding은 데이터를 물리적으로 여러 DB 서버에 나누어 저장합니다.

따라서 하나의 DB 서버 자원으로 감당 가능하고, 파티션 키를 기준으로 조회 범위를 줄일 수 있다면 Partitioning을 고려할 수 있습니다. 반면 저장 용량이나 쓰기 처리량 자체가 서버 한계에 도달했다면 Sharding을 고려해야 합니다.

 

결론

결론적으로 Clustering은 서버 장애·부하, Replication은 읽기 부하, Sharding은 쓰기·용량 한계를 담당합니다.

상황	더 어울리는 방법
조회 요청이 너무 많음	Replication
데이터 용량, 쓰기 요청이 한 DB 한계를 넘음	Sharding
서버 장애에도 서비스를 유지하고 싶음	Active & Stand-By 또는 Active & Active
Shard 하나가 장애 나도 대비하고 싶음	각 Shard에 Replication 적용