티스토리 뷰
리더 기반 복제 (Leader-Based Replication)
리더(Primary)가 쓰기 작업을 처리하고, 팔로워(Replica)는 리더의 로그를 따라감
일관성을 비교적 쉽게 유지할 수 있는 구조
장점
쓰기 순서를 리더가 결정하므로 순차성 보장
클라이언트는 리더로만 쓰기 요청 → 충돌 방지
단점
리더 장애 시 리더 선출 필요 (합의 알고리즘 필요)
팔로워가 리더와 동기화되지 않으면 최신 데이터 보장 안 됨
클라이언트 쓰기 옵션
리더에게만 쓰기
팔로워 읽기 허용 vs 제한 (Read Your Writes 등 보장 여부)
일관성 모델 (Consistency Model)
어떤 시점에 어떤 노드가 어떤 데이터를 읽을 수 있는가에 대한 규칙
강한 일관성 (Strong Consistency)
모든 노드가 항상 같은 값을 읽음
장점: 단순함
단점: 성능 저하, 지연 증가
약한 일관성 (Weak Consistency)
읽는 시점에 따라 다른 값을 볼 수 있음
장점: 빠름
단점: 복잡한 로직 필요
최종 일관성 (Eventual Consistency)
시간이 지나면 결국 모든 노드가 같은 값을 가지게 됨
예: DNS, S3, Cassandra
세부 모델
Read-Your-Writes
Monotonic Reads
Causal Consistency (인과 일관성)
→ 사용자 경험 개선에 유용
다중 리더 복제 (Multi-Leader Replication)
여러 노드가 동시에 쓰기를 받아들이는 구조
장소/네트워크 단절 환경에서 유용 (ex. 모바일, 오프라인 편집)
장점
지역 간 쓰기 지연 감소
장애 대응력 향상
단점
충돌 발생 가능성 증가
병합 로직이 복잡함
적용 예시
카렌더 동기화, 모바일 노트 앱 등
무리더 복제 (Leaderless Replication)
리더 없이 모든 노드가 쓰기/읽기 가능
충돌 해결을 클라이언트 또는 애플리케이션이 수행해야 함
리더 기반: 단순하지만 장애 처리 복잡
다중 리더: 네트워크 분리/병합 환경에 유용
무리더: 완전한 분산성, 그러나 충돌 해결 복잡
2PC: 2-Phase Commit
이해하기 쉬운 합의 알고리즘을 가져와봤다. 2단계 커밋이다. 여러 노드에 걸친 원자적 트랜잭션 커밋을 보장한다. 즉, 모든 노드가 커밋되거나 모든 노드가 어보트되도록 보장한다.
2-phase인 이유는 이 알고리즘을 수행하는 주체가 2가지로 나뉘기 때문이다. 바로 코디네이터(혹은, 트랜잭션 관리자)와 참여자다. 코디네이터가 전체 흐름을 관장하고 참여자가 신호를 보내는 역할이다. 참여자의 판단 하에 수정 내용은 커밋되거나 어보트된다. 책에서는 이 방식에 대한 자세한 설명과 함께 장애 발생 가능성을 알려주고, 더 나아가 3단계 커밋이 등장하기도 한다.