티스토리 뷰

5장. 복제 (Replication)

1. 복제를 사용하는 이유

데이터 복제는 하나의 데이터를 여러 서버에 저장하여 다음과 같은 목적을 달성하기 위해 사용된다.

  • 내결함성 향상: 하나의 서버가 장애를 일으켜도 다른 복제본을 통해 서비스 지속 가능
  • 지연 시간 단축: 사용자와 가까운 지역의 서버에서 응답 제공 가능
  • 읽기 처리량 확장: 읽기 요청을 여러 서버에 분산

하지만 복제는 동기화 지연, 일관성 문제, 충돌 처리와 같은 복잡한 문제도 함께 수반한다.

 

2. 리더-팔로워 복제

구조

  • 리더 서버에서만 쓰기 가능
  • 팔로워 서버는 리더의 데이터를 복제하여 읽기만 수행
  • 리더의 변경 사항은 로그를 통해 팔로워로 전달

데이터 흐름

  1. 클라이언트가 리더에게 쓰기 요청
  2. 리더가 데이터를 변경하고 로그에 기록
  3. 리더가 변경 로그를 팔로워에게 전송
  4. 팔로워가 로그를 읽고 데이터 반영

장점

  • 구조가 단순하고 구현이 쉬움
  • 읽기 부하 분산 가능

단점

  • 리더 장애 시 리더 교체 과정 필요
  • 복제 지연으로 인한 일관성 문제 발생 가능

 

3. 리더 장애 상황 처리

리더 장애 시

  • 새로운 리더를 선출해야 함
  • 리더가 전파하지 못한 변경 사항은 유실 가능
  • 가장 최신 로그를 가진 팔로워가 리더로 선출되어야 안전

클라이언트 관점 문제

  • 리더에 쓰기 요청을 보낸 직후 리더가 죽으면
    • 변경 내용이 복제되지 않았을 수 있음
    • 클라이언트는 성공 응답을 받았지만 데이터는 손실될 수 있음

 

4. 로그를 통한 복제

트랜잭션 로그 기반

  • 리더 서버의 트랜잭션 로그를 그대로 팔로워가 수신해 재실행

변경 내용 캡처(Change Data Capture, CDC)

  • 리더의 변경 로그를 외부에서 캡처해 다른 시스템으로 전파

 

5. 다중 리더 복제

개념

  • 여러 리더가 동시에 쓰기 요청을 처리할 수 있음
  • 각 리더는 자신의 변경 내용을 다른 리더로 복제
  • 지리적으로 분산된 환경에서 유리

장점

  • 로컬 서버에서 빠르게 쓰기 가능
  • 네트워크 지연 시간 최소화

단점

  • 동일한 데이터에 대해 서로 다른 리더가 동시에 변경하면 충돌 발생
  • 충돌을 자동 혹은 수동으로 해결해야 함

충돌 해결 방식

  • 최종 쓰기 우선 (Last Write Wins): 가장 마지막 변경을 우선시
  • 버전 벡터를 통한 충돌 감지
  • 애플리케이션 수준 병합 로직 필요

 

6. 리더 없는 복제

개념

  • 모든 노드가 동등한 역할을 수행하며, 특정 리더가 없음
  • 클라이언트는 여러 노드에 쓰기/읽기 요청을 보냄
  • 다수의 응답으로 정합성을 결정

장점

  • 높은 내결함성
  • 네트워크 분할 상황에서도 일부 기능 유지 가능

단점

  • 충돌 가능성 높음
  • 데이터 버전 관리가 복잡함

예시 시스템

  • Amazon Dynamo, Apache Cassandra, Riak

7. 복제와 읽기 일관성

복제는 읽기 일관성에 영향을 준다. 다음은 주요 읽기 일관성 모델이다:

1) 선형화 가능성

  • 가장 직관적인 일관성 모델
  • 어떤 사용자가 쓴 값을, 다른 사용자도 바로 읽을 수 있어야 함

2) 자신의 쓰기 읽기 보장

  • 사용자가 자신이 작성한 데이터를 다시 읽을 때 반드시 반영되어 있어야 함

3) 순차적 읽기 보장

  • 이전에 읽은 값보다 오래된 값이 다시 반환되면 안 됨

4) 순차적 쓰기 보장

  • 사용자의 쓰기 작업 순서가 뒤바뀌지 않고 반영되어야 함

'스터디' 카테고리의 다른 글

데이터 중심 애플리케이션 1,2장  (0) 2025.04.22
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2025/05   »
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
글 보관함