Raft Consensus Algorithm

개요

Raft는 Paxos보다 이해하기 쉬우면서도 동일한 안전성과 일관성을 제공하는 분산 합의 알고리즘입니다. 핵심 목적은 여러 노드(서버)로 구성된 시스템에서 하나의 일관된 로그(log)를 유지하면서도, 노드 장애나 네트워크 분할 상황에서도 안전하고 가용한 상태를 유지하는 것입니다. 2014년 Diego Ongaro와 John Ousterhout의 논문 "In Search of an Understandable Consensus Algorithm"을 통해 소개되었으며, 현재 etcd, Consul, RethinkDB, CockroachDB 등에서 널리 채택되고 있습니다.

---

1. 개념 및 정의

Raft는 총 세 가지 핵심 하위 프로토콜로 구성됩니다:

1. 리더 선출(Leader Election)
2. 로그 복제(Log Replication)
3. 안전성 보장(Safety)

각 노드는 하나의 시점에 Follower, Candidate, Leader 중 하나의 상태를 가지며, 리더는 클라이언트 요청을 받고, 로그를 다수 노드에 복제하여 **일관된 커밋 상태(commit log)**를 보장합니다.

---

2. 동작 흐름 및 상태 전이

상태	역할	주요 이벤트
Follower	리더의 명령 수신	일정 시간 리더 신호 없음 → Candidate로 전이
Candidate	리더 선출 시도	과반수의 투표 획득 시 Leader로 승격
Leader	클라이언트 요청 처리 및 로그 복제	Heartbeat 주기적으로 전송

Heartbeat 타이머 + 랜덤ized 선출 시간은 리더 충돌을 방지합니다.

---

3. 로그 복제 메커니즘

단계	설명
클라이언트 요청	Leader에게 명령 전달 (예: Key/Value 수정)
로그 추가	Leader가 로그 엔트리를 추가 후 Follower에게 AppendEntries RPC 전송
복제 응답 수신	과반수 이상 복제 성공 시 커밋
커밋 통지	모든 노드가 커밋된 명령을 상태 머신에 적용

Raft는 단일 리더 모델이기 때문에 로그 충돌이 덜 복잡합니다.

---

4. 특징 및 장점

항목	설명	효과
이해 용이성	Paxos보다 구조적으로 명확	교육 및 구현 부담 감소
강력한 일관성	Leader 기반 복제 구조	선형 일관성 보장 (Linearizability)
리더 중심성	클라이언트가 리더만 참조	쓰기 경로 단순화, 분산 락 구현 용이
장애 내성	Follower 복구 및 리더 교체 가능	2f+1 중 최대 f개 장애 허용

Raft는 CAP 이론 상 CP(Consistency + Partition Tolerance) 계열입니다.

---

5. 활용 사례

시스템	설명	용도
etcd	Kubernetes 설정 저장소	분산 Key-Value 저장소, 클러스터 구성 관리
Consul	서비스 디스커버리 및 헬스체크	분산 환경의 상태 동기화
CockroachDB	PostgreSQL 호환 분산 RDBMS	SQL 트랜잭션 기반 동기 복제
TiKV	분산 Key-Value 엔진 (Raft 기반)	Per-Region 리더 구조 운영

분산 설정 저장소 및 DB 트랜잭션 합의 구현에 가장 자주 사용되는 알고리즘입니다.

---

6. 한계점 및 고려사항

항목	설명	대응 전략
리더 병목	모든 쓰기를 리더가 처리	리더 자원 할당 증가 또는 샤딩 필요
네트워크 지연	타이머 기준 오작동 가능성	지연 환경에 맞춘 타임아웃 조정 필요
로그 일관성	과거 로그와 충돌 시 덮어쓰기 처리 복잡	인덱스+term 비교 기반 처리 필요
동시 선출	다수 후보 발생 시 split vote 가능성	선출 타이머 무작위화로 해결 가능

운영 환경에 따라 타이머 및 네트워크 튜닝이 필수적입니다.

---

7. 결론

Raft는 분산 시스템의 복잡한 합의 문제를 실용적이고 이해하기 쉬운 방식으로 풀어낸 대표적인 합의 프로토콜입니다. 단일 리더 모델을 기반으로 고가용성, 일관성, 복구 용이성을 제공하며, 다양한 현대 분산 시스템의 핵심 구성 요소로 사용되고 있습니다. Paxos 대비 구현과 디버깅이 쉬워 운영자와 개발자 모두에게 실용적인 선택지입니다.