티스토리 뷰
5장. 복제 (Replication)
1. 복제를 사용하는 이유
데이터 복제는 하나의 데이터를 여러 서버에 저장하여 다음과 같은 목적을 달성하기 위해 사용된다.
- 내결함성 향상: 하나의 서버가 장애를 일으켜도 다른 복제본을 통해 서비스 지속 가능
- 지연 시간 단축: 사용자와 가까운 지역의 서버에서 응답 제공 가능
- 읽기 처리량 확장: 읽기 요청을 여러 서버에 분산
하지만 복제는 동기화 지연, 일관성 문제, 충돌 처리와 같은 복잡한 문제도 함께 수반한다.
2. 리더-팔로워 복제
구조
- 리더 서버에서만 쓰기 가능
- 팔로워 서버는 리더의 데이터를 복제하여 읽기만 수행
- 리더의 변경 사항은 로그를 통해 팔로워로 전달
데이터 흐름
- 클라이언트가 리더에게 쓰기 요청
- 리더가 데이터를 변경하고 로그에 기록
- 리더가 변경 로그를 팔로워에게 전송
- 팔로워가 로그를 읽고 데이터 반영
장점
- 구조가 단순하고 구현이 쉬움
- 읽기 부하 분산 가능
단점
- 리더 장애 시 리더 교체 과정 필요
- 복제 지연으로 인한 일관성 문제 발생 가능
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 |
---|
댓글