[DB] 부하 분산을 위한 읽기 복제와 샤딩

데이터베이스 부하 분산을 위해 스케일 아웃이 필요한 경우에 활용할 수 있는 방법을 소개한다.

1. Read Replication (읽기 복제)

Read Replication은 말 그대로 메인 DB의 복사본을 만들어 "읽기(조회) 작업만 전담"시키는 기술.

일반적인 웹 서비스의 트래픽 비율을 보면 조회(Read)가 약 70~80% 이상을 차지한다는 점에서 착안한 아키텍처이다.

💡 구조와 작동 원리

• Primary (Master) 서버: 데이터의 추가, 수정, 삭제(INSERT, UPDATE, DELETE) 등 쓰기 작업만 처리. 시스템에 단 1대만 존재한다.
• Secondary (Replica) 서버: 데이터 조회(SELECT) 등 읽기 작업만 처리. 트래픽 양에 따라 여러 대를 추가할 수 있음.
• 데이터 동기화: 사용자가 Primary에 글을 쓰면, 변경 사항이 로그를 통해 Secondary 서버들로 실시간 비동기 복제됨.

👍 장점

• 복제본 서버만 늘리면 되므로 읽기 트래픽 확장이 매우 쉬움.
• 무거운 통계/분석 쿼리를 특정 복제본 서버로 돌려, 일반적인 서비스에 영향을 최소화할 수 있음.
• Primary 서버가 죽어도 Secondary 중 한 대를 메인으로 승격(Failover)시킬 수 있어 고가용성(HA)이 보장됨.

👎 단점 및 한계

• Replication Lag (동기화 지연): 비동기 복제 특성상 Primary에 쓰인 데이터가 Secondary에 반영되기까지 미세한 딜레이가 있음. 이 순간 조회하면 방금 쓴 글이 안 보이는 현상이 생길 수 있음. 방금 반영된 데이터는 Primary서버에서 조회하도록 설정하는 등의 조치가 필요함.
• 쓰기 용량의 한계: 데이터 세트 전체를 그대로 복사하는 구조이므로, 쓰기(Write) 트래픽 자체나 전체 데이터 저장 용량이 크면 부담이 됨.

2. Sharding (샤딩)

Sharding은 거대한 데이터 세트를 "특정 기준에 따라 조각(Shard)으로 쪼개어 여러 서버에 나누어 저장"하는 기술.

읽기 복제로도 해결할 수 없는 '저장 공간 부족'과 '쓰기 부하'를 해결하기 위한 최종 단계의 스케일 아웃 방식.

💡 구조와 작동 원리

• 수평적 분할: 하나의 큰 테이블을 행(Row) 단위로 쪼개어 서로 다른 서버에 분산 저장.
• 샤드 키(Shard Key): 데이터를 나누는 기준이 되는 필드.
  • 레인지(Range) 샤딩: ID나 날짜의 범위(1~1000번, 1001~2000번)를 기준으로 분산
  • 해시(Hash) 샤딩: ID의 해시 결괏값(Hash(ID) % 서버 대수)을 기준으로 균등하게 분산
• 라우터(Router): 애플리케이션의 요청이 들어오면, 샤드 키를 확인하고 해당 데이터가 있는 정확한 서버 조각으로 연결해 주는 역할.

👍 장점

• 데이터가 물리적으로 분산되므로 하나의 서버가 감당해야 할 디스크 용량과 쓰기 부하가 획기적으로 감소.
• 이론적으로 서버를 계속 추가함으로써 무한한 확장이 가능합니다.

👎 단점 및 한계

• 복잡도 극대화: 데이터가 여러 서버에 찢어져 있기 때문에, 두 개 이상의 샤드에 걸친 데이터를 묶어서 조회하는 JOIN 연산이나 분산 트랜잭션 구현이 극도로 어렵고 성능이 떨어짐.
• 샤드 키 종속성: 한 번 결정한 샤드 키는 도중에 변경하기가 거의 불가능하며, 키를 잘못 설계하면 특정 샤드 서버에만 데이터가 몰리는 핫스팟(Hotspot) 현상이 발생할 수 있음.

3. Read Replication vs Sharding 비교 정리

비교 항목	Read Replication (읽기 복제)	Sharding (샤딩)
핵심 목적	읽기(조회) 트래픽 분산, 고가용성 보장	쓰기 트래픽 분산, 저장 용량 한계 극복
데이터 저장 방식	모든 서버가 동일한 전체 데이터를 가짐	각 서버가 전체 데이터의 **일부(조각)**만 가짐
확장 방향	읽기 전용 서버 추가 (비교적 쉬움)	데이터를 쪼갤 새로운 샤드 서버 추가 (매우 어려움)
적합한 상황	서비스 조회 요청이 많고 무거운 대규모 웹 서비스	데이터양이 페타바이트급이거나 쓰기 부하가 한계에 달했을 때
주요 단점	복제 지연(Lag)으로 인한 데이터 불일치 가능성	JOIN/트랜잭션 복잡도 상승, 인프라 관리 비용 폭증

🛠️ 결론: 아키텍처 도입의 정석 가이드

데이터베이스가 비명을 지르기 시작할 때, 무작정 복잡한 기술을 도입하면 오버헤드가 발생할 수 있다.

현업에서 추천하는 확장 테크트리는 보통 다음과 같다.

1. 1단계: SQL 최적화 및 인덱스(Index) 튜닝, 캐시(Redis 등) 도입 (소프트웨어 레벨 해결)
2. 2단계: DB 서버의 CPU, RAM, SSD 성능 업그레이드 (스케일 업)
3. 3단계: Read Replication 도입 (읽기 분산 및 고가용성 확보)
4. 4단계: Sharding 도입 (도저히 용량과 쓰기 부하를 감당할 수 없을 때)

기술의 장단점과 현재 서비스의 병목 구간(읽기 부하인가, 쓰기/용량 부하인가)을 명확히 파악하고 단계적으로 접근하는 것이 가장 안전한 인프라 확장 전략이다.