🛶 Raft 알고리즘: 합의의 땟목 (ETCD의 심장)
“리더 없이는 아무것도 못 하는 우리 팀”
🐟 Intro
분산 시스템에서 제일 무서운 순간은?
👉 “누가 리더냐?” 하는 순간입니다.
MongoDB, Zookeeper, Kafka, etcd… 다들 합의 알고리즘으로 Raft를 쓰거나 영향을 받았죠.
Kubernetes의 etcd도 마찬가지!
오늘은 Raft가 어떻게 리더 뽑고, 로그 합의하고, 장애 대응하는지를 파헤쳐보겠습니다.
👑 1단계: 리더 선출 (Leader Election)
Raft는 무조건 리더 기반입니다.
리더 없이는 아무 것도 못함. (우리 회사도 비슷하죠?)
- 노드들이 처음엔 다 “팔로워(Follower)” 상태
- 일정 시간 동안 리더가 아무 소식 없으면 → “리더 죽었네?” 판단
- 그때 한 노드가 “내가 후보(Candidate) 할래!” 선언
- 투표 요청 날림 → 과반수 표 얻으면 리더 당선 🎉
👉 그래서 홀수가 중요한 겁니다. 짝수면 동률 나와서 “아니 네가 해 / 아니 네가 해” 싸움남.
📜 2단계: 로그 복제 (Log Replication)
리더가 뽑히면 해야 할 일: 로그를 다 똑같이 맞추기
(“얘들아 우리 팀 노션 똑같이 업데이트 해라!” 같은 느낌)
- 클라이언트 → 리더에게 요청
- 리더 → “얘들아, 이거 복제해” 하고 팔로워들한테 AppendEntries RPC 날림
- 과반수 동의하면 커밋 확정 ✅
- 팔로워들이 모두 따라오면 데이터 일관성 보장
👉 즉, 리더는 분산 시스템의 “엄마” 같은 존재.
(“밥 먹자~” 하면 애들이 줄 맞춰 따라감)
🕳️ 3단계: 장애 상황 처리
리더가 갑자기 죽으면? 💀
- 팔로워들이 “심장 박동(heartbeat)” 신호 못 받음
- “리더 사라졌네?” → 새 리더 뽑기 투표 돌입
- 과반수 확보한 노드가 새 리더 당선
즉, Raft는 항상 과반수 합의만 있으면 시스템이 굴러감.
짝수 노드가 싫은 이유가 다시 나왔죠.
🔢 Term
Raft는 선거 때마다 “Term(임기)”라는 개념을 붙입니다.
대통령 선거처럼 “제 1기, 제 2기…” 이런 느낌.
- 각 Term에는 반드시 리더 1명
- Term 번호는 전 세계 공통 진실(absolute truth)
- Term이 바뀌면 이전 리더는 자동 퇴출됨
👉 그래서 Raft는 항상 “최신 Term의 리더만 믿자” 원칙으로 동작합니다.
🕺 재미난 포인트
- Raft는 Paxos보다 이해하기 쉽게 만들려고 나옴
(그래서 논문 제목도 "In Search of an Understandable Consensus Algorithm") - Paxos는 수학과 논문 느낌인데, Raft는 실용주의 느낌
- 즉: Paxos = 수학 과외, Raft = 유튜브 인강
🍕 비유: 치킨 시켜 먹기
- 리더 선출: “오늘 치킨 뭐 시킬까? 투표 ㄱㄱ”
- 로그 복제: 리더가 “양념치킨 2마리, 후라이드 1마리” 주문 확정 → 단톡방에 공유
- 장애: 리더가 갑자기 단톡방 퇴장 → “새 단톡방장 뽑자!”
- Term: “2025년 1분기 치킨 담당 회장”
🎬 마무리
Raft 알고리즘은 결국 이런 원칙을 따릅니다:
- 리더는 무조건 1명 (왕은 둘이 될 수 없다 👑)
- 과반수 합의만 있으면 시스템은 계속 굴러간다
- 짝수 노드는 혼돈을 부른다
그러니, 쿠버네티스에서 마스터 노드를 짤 때는 꼭 이렇게 기억하세요:
“K8s 마스터 = 홀수 = 평화로운 치킨 파티” 🍗
