Phase 3레슨 15

Consensus (Raft, Paxos)

분산 시스템에서 하나의 값을 어떻게 합의하는가 — Leader Election, Log Replication

💡ELI5·

투표와 합의

5명의 의원이 하나의 법안에 동의해야 한다:
  3명 이상 찬성 → 가결 (Quorum)
  2명이 회의 불참 → 3명이서라도 결정 가능
  두 그룹이 분리 → 과반수 못 만든 쪽은 대기 (Split Brain 방지)

💡 비유 — 합의 = 의회 투표. 과반수가 동의해야 결정. 한 명이 쓰러져도 나머지가 결정 가능. 두 파벌로 나뉘면 과반수를 못 만든 쪽은 결정 불가 → 모순된 결정이 동시에 나오는 것을 방지.

🔬Deep Dive·

Raft의 세 가지 핵심 메커니즘

1. Leader Election
   Follower → Candidate (timeout) → RequestVote → 과반수 → Leader

2. Log Replication
   Client → Leader (로그 추가) → AppendEntries → Followers
   → 과반수 복제 → Commit → Client 응답

3. Safety
   Commit된 로그는 절대 손실되지 않음
   같은 Term에서 하나의 Leader만
   Leader의 로그가 Follower의 로그를 포함

상태	역할	전환 조건
Follower	Leader의 로그 복제만 수행	Leader 하트비트 안 오면 Candidate로
Candidate	선거 시작 (Term 증가)	과반수 득표 → Leader, 더 높은 Term 발견 → Follower
Leader	모든 쓰기 처리, 로그 복제	더 높은 Term 발견 → Follower

🔬Deep Dive·

Paxos vs Raft

구분	Paxos	Raft
합의 단위	단일 값 (Multi-Paxos로 확장)	로그 (명령 시퀀스)
리더	선택적 (Multi-Paxos에서 필요)	필수 (강한 리더 모델)
이해 난이도	매우 높음	낮음 (설계 목표)
구현 난이도	매우 높음	중간
실제 사용	Chubby, Spanner (변형)	etcd, Consul, CockroachDB

🔬Deep Dive·

Split Brain 방지

5노드, 네트워크 분할:
  그룹 A: 3노드 → 과반수 → 리더 선출 가능 → 쓰기 가능
  그룹 B: 2노드 → 과반수 불가 → 리더 선출 불가 → 읽기만 (또는 거부)

복구 후:
  그룹 B의 구식 리더 → 그룹 A의 더 높은 Term 발견 → 자동 스텝다운

과반수 Quorum이 Split Brain을 수학적으로 방지한다. 두 그룹이 동시에 과반수를 가질 수 없기 때문.

⚖️Trade-off·

합의 알고리즘의 비용

이점	대가
강한 일관성 보장	과반수 노드 필요 (최소 3, 권장 5)
장애 허용 (f 노드 장애 시 2f+1 노드로 동작)	모든 쓰기에 합의 오버헤드 (지연)
Split Brain 방지	과반수 미달 시 서비스 중단
순서 보장 (로그 복제)	리더가 SPOF (빠른 재선출로 완화)

❓ 체크포인트 질문

1.합의(Consensus) 알고리즘이 해결하는 근본 문제는?
2.Raft의 Leader Election에서 'Term'이 왜 중요한가?
3.Quorum이 과반수(majority)인 이유는?
4.Raft가 Paxos보다 실용적으로 널리 쓰이는 이유는?
5.Split Brain이 발생하는 상황과 합의 알고리즘이 이를 어떻게 방지하는가?

← 이전

Distributed Lock

Layered Architecture