한양과학기술고등학교

여러 대의 서버가 네트워크로 연결돼 있는데, 그중 일부는 언제든 느려지거나 멈출 수 있다. 이런 상황에서 "다음 값은 이걸로 하자"라는 결정을 서버들끼리 어떻게 안전하게 합의할 수 있을까? 1989년 레슬리 램포트가 제안한 Paxos는 이 문제를 푸는 가장 오래되고 유명한 알고리즘이다. 복잡하기로 악명 높아서, 훗날 이해하기 쉽게 설계한 대안이 바로 이 사이트에도 있는 Raft다.

1. 세 가지 역할

실제로는 한 서버가 여러 역할을 동시에 겸하는 경우가 많다.

2. 왜 하필 "과반수"일까 — 정족수(Quorum)

Acceptor 5대 중 몇 대를 꺼도 합의가 유지되는지 직접 꺼보자. 과반(3대) 미만이면 합의가 불가능해진다.

3. Paxos 한 라운드 — 직접 진행해보기

Paxos는 항상 두 단계다: Phase 1 (Prepare / Promise)로 "번호 N보다 낮은 제안은 무시해달라"고 예약하고, Phase 2 (Accept / Accepted)에서 실제 값을 과반수에게 확정시킨다. 버튼을 눌러 Proposer 하나가 값 "CACHE_TTL=60"을 제안하는 과정을 한 단계씩 지켜보자.

4. 프로포저 둘이 동시에 나서면? — 듀얼링 프로포저

리더가 정해져 있지 않은 Basic Paxos는 두 Proposer가 번호를 계속 높여가며 서로를 밀어내는 라이브락(livelock)에 빠질 수 있다. 아래에서 두 Proposer A, B가 번갈아 제안 번호를 올리며 경쟁하는 모습을 재생해보자.

5. Raft와 무엇이 다른가

6. 어디에 쓰이나