Raft 리더 선출
5노드 클러스터에서 리더 사망 → 무작위 타임아웃 → 입후보와 투표 → 과반 취임 → 옛 리더 강등까지, 합의의 네 가지 규칙을 실행한다.
하트비트: 흐름
단계 목록 · 키보드 ←/→ 이동, Space 재생
Raft 선출은 네 규칙의 조합이다 — 무작위 타임아웃(동시 입후보 방지), 임기당 한 표(이중 리더 방지), 과반 득표(분할 시 소수 쪽 리더 방지), 높은 임기 우선(복귀 리더 강등).
왜 헷갈리는가
"노드가 죽으면 어떻게 새 리더를 뽑지? 누가 사회를 보지?" — 사회자가 없다는 것이 요점이다. 그리고 '왜 하필 과반인가'가 늘 얼버무려진다: 네트워크가 갈라져도 과반은 한쪽에만 존재할 수 있어서, 두 쪽이 동시에 리더를 갖는 일이 산술적으로 불가능해진다.
애니메이션이 보여주는 것
평시의 질서는 하트비트다 — 리더가 살아 있는 한 팔로워의 선거 타이머는 계속 되감긴다. 리더가 죽으면 하트비트가 끊기고, 무작위 타임아웃(150~300ms)이 가장 먼저 끝난 노드가 후보가 된다. 무작위가 아니면 전원이 동시에 입후보해 표가 갈린다.
후보는 임기를 올리고(3→4) 투표를 청한다. 각 노드는 한 임기에 한 표만 — 그리고 후보의 로그가 자기보다 뒤처지지 않을 때만 — 준다. 과반(5대 중 3표)을 얻는 순간 취임하고, 옛 리더가 돌아와도 더 높은 임기의 하트비트를 보는 즉시 팔로워로 내려앉는다. 스플릿 브레인이 구조적으로 막히는 지점이다.
과반의 산술과 홀수 클러스터
5노드에서 과반은 3 — 2대까지 죽어도 전진한다. 네트워크가 3:2로 갈라지면 3쪽만 리더를 가질 수 있고, 2쪽의 옛 리더는 쓰기를 커밋할 수 없다(과반 응답을 못 받으므로). 4노드의 과반도 3이라 장애 허용은 5노드와 같은데 비용만 늘어난다 — 합의 클러스터를 3·5·7 홀수로 두는 이유다.
실무에서 만나는 Raft
오늘 쓰는 인프라의 심장부가 대부분 이 절차다.
- Kafka KRaft: ZooKeeper를 걷어내고 컨트롤러 쿼럼이 Raft로 메타데이터를 합의한다 — 'Kafka는 이제 ZK가 필요 없다'의 실체.
- etcd(쿠버네티스의 진실 저장소)·Consul·CockroachDB·TiDB — 전부 Raft. 참고로 옛 ZooKeeper는 Raft가 아니라 동류의 ZAB 프로토콜이다.
- 운영 감각: 선출 동안(대개 1초 미만) 쓰기가 멈춘다 — 리더 재선출 스파이크가 지연 그래프에 보이면 이것이다. 네트워크 불안정으로 선출이 반복되면(플래핑) 타임아웃 튜닝과 회선부터 본다.
- Raft가 다수결로 뽑는 건 '가장 로그가 앞선 노드 중 하나'다 — 커밋된 항목을 가진 노드만 이길 수 있어, 리더가 바뀌어도 커밋된 데이터는 유실되지 않는다.
기억할 것
- 사회자는 없다 — 무작위 타임아웃이 첫 후보를 만든다.
- 임기당 한 표 + 과반 득표 = 어떤 분할에서도 리더는 최대 하나.
- 높은 임기가 언제나 이긴다 — 돌아온 옛 리더는 즉시 강등.
- 홀수 노드(3·5·7)로 꾸린다 — 짝수는 비용만 늘고 허용치는 그대로.
- 선출 중 쓰기는 멈춘다 — 지연 스파이크의 흔한 범인.