안녕하세요. 자바파커입니다.

Raft 클러스터의 모든 노드는 같은 역할로 고정되지 않습니다. 한 노드는 Leader로 동작하고 나머지는 Follower가 됩니다. Leader가 멈추면 운영자가 새 리더를 지정하는 것이 아니라 노드들이 투표로 선출합니다.

Raft의 리더는 가장 빠른 서버가 아니라, 현재 Term에서 과반수의 동의를 얻은 서버입니다.

이 글은 Raft 전체 중에서도 리더 선출에 집중합니다. 로그 복제와 커밋 규칙은 리더 선출 이후의 별도 단계입니다.

세 가지 상태

Raft 노드는 다음 상태 중 하나입니다.

Follower  → Leader의 Heartbeat를 기다림
Candidate → 선거를 시작하고 표를 요청
Leader    → 로그 복제와 Heartbeat를 주도

정상 상태에서는 Leader가 주기적으로 Heartbeat를 보냅니다. Follower는 이를 받을 때마다 Election Timeout을 다시 시작합니다.

Term은 선거의 세대 번호다

Term은 단조 증가하는 정수입니다.

TERM 8: Leader A
TERM 9: Leader C

각 Term에는 최대 한 명의 Leader만 존재할 수 있습니다. 노드가 자신보다 높은 Term의 메시지를 받으면 새 Term을 인정하고 Follower로 돌아갑니다. 오래된 Leader가 네트워크 복구 후 돌아와도 낮은 Term으로 클러스터를 다시 지배하지 못하는 이유입니다.

리더 선출 과정

5개 노드 A~E가 있고 A가 Leader라고 하겠습니다.

1. Heartbeat가 끊긴다

A가 장애로 멈추면 Follower들은 즉시 장애를 확정하지 않습니다. 각자 Election Timeout이 만료되기를 기다립니다.

2. 가장 먼저 만료된 노드가 Candidate가 된다

C의 타이머가 먼저 끝났다면 C는 Term을 9로 올리고 자신에게 한 표를 던집니다.

C: Follower → Candidate
currentTerm: 8 → 9
votes: 1

3. RequestVote RPC를 보낸다

C는 B, D, E와 장애 난 A에 투표를 요청합니다. 각 노드는 같은 Term에서 한 후보에게만 투표합니다.

4. 과반수를 얻으면 Leader가 된다

5개 노드의 과반수는 3입니다.

C self vote + B + D = 3 / 5
→ C becomes Leader

새 Leader C는 즉시 Heartbeat를 보내 다른 Candidate와 Follower의 선거 타이머를 초기화합니다.

왜 Election Timeout은 서로 달라야 할까

모든 Follower가 같은 순간 Candidate가 되면 표가 갈릴 수 있습니다.

B → B에게 투표
C → C에게 투표
D → D에게 투표

아무도 과반수 실패 → 다음 Term에서 재선거

Raft는 무작위 Election Timeout을 사용해 한 노드가 먼저 선거를 시작할 가능성을 높입니다. 원 논문은 다음 관계를 제시합니다.

broadcastTime ≪ electionTimeout ≪ MTBF

• 메시지 왕복 시간보다 Election Timeout이 충분히 길어야 정상 Heartbeat를 장애로 오판하지 않습니다.
• 평균 장애 간격보다는 짧아야 실제 Leader 장애 후 빠르게 복구합니다.

아무 Candidate에게나 투표하지 않는다

리더 선출은 과반수만 얻으면 끝나는 인기 투표가 아닙니다. Candidate의 로그가 투표자의 로그보다 충분히 최신이어야 표를 받을 수 있습니다.

일반적으로 마지막 로그의 Term을 먼저 비교하고, 같다면 마지막 로그 인덱스를 비교합니다. 뒤처진 노드가 Leader가 되어 이미 커밋된 로그를 잃게 만드는 상황을 막기 위한 규칙입니다.

장애 순간 쓰기는 어떻게 될까

Leader 장애와 새 Leader 선출 사이에는 쓰기를 합의할 Leader가 없습니다. etcd 공식 장애 문서도 선거 중에는 쓰기를 처리하지 못하고 새 Leader 선출까지 대기한다고 설명합니다.

Leader failure
→ election timeout
→ voting
→ new Leader
→ queued writes resume

따라서 failover가 가능하다는 말은 무중단 쓰기를 의미하지 않습니다. Election Timeout을 너무 길게 잡으면 장애 복구가 느리고, 너무 짧게 잡으면 네트워크 지연이나 느린 디스크를 Leader 장애로 오판해 불필요한 선거가 늘어납니다.

etcd 운영에서 볼 지표

etcd는 Kubernetes의 클러스터 상태를 보관하는 핵심 구성요소입니다. Leader Heartbeat가 늦는 원인이 네트워크만은 아닙니다. WAL fsync가 느리거나 CPU가 포화돼도 Heartbeat가 지연될 수 있습니다.

운영에서는 다음을 함께 봅니다.

• Leader 변경 횟수와 Term 증가
• peer 간 RTT
• wal_fsync_duration_seconds
• backend commit duration
• 디스크 지연과 CPU throttling
• 과반수에 필요한 멤버의 건강 상태

노드 수를 짝수에서 홀수로 늘린다고 항상 장애 허용 수가 증가하는 것도 아닙니다.

3대에서 4대로 늘리면 쓰기 과반수는 커지지만 장애 허용 수는 그대로입니다. 일반적으로 3대 또는 5대 구성이 많이 사용되는 이유입니다.

Pre-Vote는 왜 필요할까

네트워크에서 고립된 노드가 계속 Election Timeout을 맞아 Term을 올리다가 복구되면 정상 Leader까지 높은 Term을 보고 Follower로 내려갈 수 있습니다. Pre-Vote는 실제 Term을 올리기 전에 자신이 선거에서 이길 가능성이 있는지 미리 확인합니다.

etcd의 Raft 구현도 선택적 Pre-Vote 메시지를 제공해 재합류 노드가 불필요하게 클러스터를 흔드는 상황을 줄입니다.

마무리

Heartbeat 중단
→ Follower의 무작위 Timeout 만료
→ Candidate 전환과 Term 증가
→ RequestVote
→ 과반수 획득
→ 새 Leader의 Heartbeat

Raft 운영에서 중요한 것은 선거가 일어난다는 사실보다 왜 자주 일어나는지입니다. 반복되는 Leader 변경은 네트워크, 디스크, CPU, 잘못된 timeout 설정의 신호일 수 있습니다.

자주 묻는 질문

5개 노드 중 2개만 살아 있으면 Leader를 선출할 수 있나요?

아닙니다. 과반수인 3표가 필요합니다. 읽기 방식에 따라 일부 동작은 가능할 수 있지만 새로운 로그를 합의해 커밋할 수 없습니다.

가장 성능이 좋은 노드가 Leader가 되나요?

기본 Raft 선거는 성능 점수로 Leader를 고르지 않습니다. Election Timeout이 먼저 만료되고, 로그 최신성 조건을 통과해 과반수를 얻은 Candidate가 Leader가 됩니다.

Leader가 두 명 생길 수 있나요?

네트워크 분할 중 서로 다른 Term의 노드가 자신을 Leader라고 생각하는 순간은 있을 수 있지만, 같은 Term에서 두 후보가 각각 과반수를 얻을 수는 없습니다. 실제 커밋은 과반수 규칙으로 보호됩니다.

etcd의 elect 명령과 Raft Leader 선출은 같은 것인가요?

아닙니다. etcd 클러스터 내부의 Raft Leader 선출과, 애플리케이션이 etcd concurrency API로 수행하는 리더 선출은 계층이 다릅니다.

참고 자료

• Raft 원 논문 — In Search of an Understandable Consensus Algorithm
• Raft 공식 사이트
• etcd FAQ — Leader와 Heartbeat
• etcd Failure modes — Leader failure
• Kubernetes 핵심 구조 이해