Raft는 분산 시스템에서 여러 서버 간에 일관된 상태를 유지하기 위한 합의(Consensus) 알고리즘이다. Paxos보다 이해하기 쉽게 설계되었으며, etcd, CockroachDB, TiKV 등에서 사용된다.
핵심 개념
Raft 클러스터 역할:
- Leader (1개): 모든 요청 처리, 로그 복제
- Follower (n개): 리더의 로그 복제, 하트비트 수신
- Candidate: 리더 선출 참여 중 임시 상태
노드 5개 클러스터의 내결함성:
최대 2개 노드 장애 허용 (과반수 3개 필요)
1. 초기: 모든 노드 Follower
2. 타임아웃: Follower가 150-300ms 내 하트비트 못 받음
3. Candidate 전환: 자신에게 투표, 다른 노드에 RequestVote 전송
4. 과반수 투표: Candidate → Leader 승격
5. 리더 확정: 다른 노드에 하트비트 전송
용어(Term):
- 선거마다 단조 증가하는 임기 번호
- 구 리더의 메시지 무시 (오래된 Term)
로그 복제
클라이언트 요청 처리:
1. 클라이언트 → 리더: "x = 5"
2. 리더: 로그 추가 [Index:3, Term:2, x=5] (미커밋)
3. 리더 → 모든 Follower: AppendEntries 전송
4. 과반수 ACK 수신 → 커밋
5. 리더 → 클라이언트: 성공 응답
6. 리더 → Follower: 커밋 알림
로그 일관성 보장:
- 같은 Index+Term의 로그 항목은 내용이 동일
- 커밋된 항목은 절대 덮어쓰지 않음
Raft vs Paxos
| 항목 | Raft | Paxos |
|---|
| 이해 난이도 | 쉬움 | 어려움 |
| 리더십 | 명시적 강한 리더 | 여러 제안자 가능 |
| 로그 연속성 | 보장 (Gap 없음) | 복잡한 처리 필요 |
| 멤버십 변경 | Joint Consensus | 별도 정의 필요 |
관련 개념
