leader-follower architecture

읽기/쓰기 요청을 분산하여 시스템의 성능과 데이터 일관성을 유지하려는 설계 방식

리더와 팔로워 역할로 작업을 분담하여 주로 읽기, 쓰기 요청의 분산과 데이터 복제를 처리한다

데이터베이스 복제, 메시지 큐, 분산 캐시 등 다양한 분산 시스템에서 활용한다

리더

데이터를 수정하는 쓰기 작업의 중심이 되는 노드

클라이언트의 쓰기 요청을 처리하고 변경된 데이터를 팔로워 노드로 복제한다

시스템의 데이터 일관성을 유지하는 책임을 가진다

팔로워

리더가 처리한 데이터를 복제하여 읽기 작업을 분담하는 노드

클라이언트의 읽기 요청을 처리하지만 직접적인 데이터 수정은 하지 않는다

리더로부터 주기적으로 데이터를 동기화하여 최신 상태를 유지한다

동작 원리

쓰기 요청 처리

클라이언트는 쓰기 요청을 리더 노드에 보낸다

리더는 데이터를 업데이트하고 변경 내용을 각 팔로워 노드에 복제한다

읽기 요청 처리

읽기 요청은 팔로워 노드로 분산된다

읽기 전용 작업은 팔로워 노드에서 처리하여 리더의 부하를 줄인다

데이터 복제

리더는 데이터의 변경 내역을 팔로워들에게 전달하는데 주로 비동기로 이뤄진다

리더 선출

리더가 장애 발생으로 인해 작업을 처리할 수 없게 되면 새로운 리더를 선출하는 리더 선출 알고리즘이 작동한다

raft, paxos, zookeeper 같은 분산 합의 알고리즘이 사용된다

장점

읽기 성능 향상

읽기 요청이 팔로워 노드로 분산되므로 전체 시스템의 읽기 처리량이 증가한다

고가용성

리더가 장애를 일으키더라도 새로운 리더를 선출하여 서비스를 지속할 수 있다

확장성

팔로워 노드를 추가하여 읽기 성능을 확장할 수 있다

단점

쓰기 병목

쓰기 요청은 리더에서만 처리되므로 리더 노드가 과부하 상태가 될 수 있다

데이터 일관성 문제

비동기 복제 방식에서는 팔로워가 리더의 최신 데이터를 받기 전에 읽기 요청을 처리하면 최신성이 떨어지는 데이터를 반환할 수 있다

이를 최종 일관성(eventual consistency)이라고 한다

리더 장애 처리

리더가 장애를 일으켜서 새로운 리더를 선출하는 동안 서비스 중단이 발생할 수도 있다

복잡성 증가

리더 선출, 데이터 복제, 장애 복구 등으로 인해 관리가 복잡해지며 추가적인 오버헤드가 발생할 수 있다

활용 사례

데이터베이스 복제

mysql master-slave replication, postgresql streaming replication

리더-master, 팔로워-slave

메시지 큐

apache kafka는 브로커 노드 사이에서 리더-팔로워 구조를 사용한다

파티션의 리더가 데이터 쓰기를 담당하고 팔로워가 복제를 관리한다

분산 캐시

redis replication

분산 시스템

zookeeper는 리더-팔로워 모델을 사용하여 분산 합의와 메타데이터 관리를 제공한다

리더-팔로워 아키텍처와 동시성 문제 해결

읽기/쓰기 분산

읽기 작업을 팔로워로 분산하고, 쓰기 작업은 리더에서만 처리하므로 락 경합 및 동시성 문제가 줄어든다

일관성 관리

리더가 데이터 변경을 전담하므로 데이터 무결성과 동시성 문제가 최소화된다

확장성

팔로워 노드를 추가하여 읽기 부하를 분산함으로써 동시성을 높일 수 있다