에듀테크 프로젝트 대시보드
데이터베이스 복제 — Leader-Follower
데이터베이스가 딱 한 대뿐이면 그 서버가 죽는 순간 서비스 전체가 멈춘다. 이런 단일 장애점(SPOF)을 없애고, 읽기 요청을 여러 대로 분산하기 위해 같은 데이터를 여러 서버에 복제(Replication)한다. 가장 흔한 방식은 리더(Leader) 한 대가 쓰기를 전담하고, 여러 팔로워(Follower)가 리더의 변경 내역을 받아 따라가는 구조다.
클라이언트의 쓰기는 항상 리더로 간다. 리더는 자신의 WAL(Write-Ahead Log, 관련 주제: WAL)을 팔로워에 스트리밍하고, 팔로워는 그 로그를 똑같이 재적용해 리더를 "따라간다". 읽기는 아무 팔로워에서나 처리할 수 있어 부하가 분산된다.
팔로워가 로그를 받아 적용했다고 확인해야 리더가 클라이언트에 커밋 완료를 알린다. 데이터 유실 위험이 낮지만, 팔로워가 느리거나 멈추면 쓰기 전체가 지연된다.
리더는 로그를 보내자마자 바로 클라이언트에 커밋 완료를 알린다. 빠르지만 팔로워가 아직 못 받은 사이 리더가 죽으면 그 변경이 사라질 수 있다.
리더에 값을 쓰고, 팔로워에서 바로 읽어보자. 비동기 모드에서는 복제가 도착하기 전에 읽으면 낡은 값(stale read)이 보인다. 지연 슬라이더로 네트워크 상황을 바꿔가며 실험해 보자.
리더가 다운되면 팔로워 중 하나가 새 리더로 승격돼야 한다(Failover). 이때 "누가 가장 최신 데이터를 가졌는가"를 놓고 다수결(쿼럼)로 합의하는데, 과반수 투표 방식은 Raft 합의 알고리즘과 같은 원리다. 네트워크가 둘로 갈라져 양쪽에서 각자 리더를 뽑으면 스플릿 브레인(split-brain)이 생겨 데이터가 어긋날 수 있어, 반드시 과반수(quorum)의 동의가 필요하다.
| 장점 | 대가(trade-off) |
|---|---|
| 읽기 트래픽을 여러 팔로워로 분산해 처리량 증가. | 비동기 복제는 리더 장애 시 최신 쓰기 일부를 잃을 수 있음. |
| 리더가 죽어도 팔로워 승격으로 서비스 지속(가용성 ↑). | 동기 복제는 느린 팔로워 하나가 전체 쓰기 지연을 유발. |
| 지역별로 팔로워를 두면 사용자와 가까운 곳에서 읽기 가능. | 복제 지연 동안 읽기 일관성이 깨질 수 있음(stale read). |
관련 주제: 데이터베이스 샤딩 · MVCC · 2-페이즈 커밋 · Raft 합의 알고리즘 · CAP 정리 · WAL