Raft 합의 알고리즘
쉽게 풀면
회의록을 여러 명이 동시에 작성하면 누구 기록이 맞는지 혼란스러워집니다. 그래서 한 명을 "서기(리더)"로 정하고, 서기가 작성한 순서대로 나머지 사람들이 그대로 받아 적기로 약속하면 모두가 똑같은 기록을 갖게 됩니다. Raft는 여러 서버로 이루어진 분산 시스템에서 바로 이런 방식을 씁니다.
서버들은 먼저 투표를 통해 리더 하나를 뽑고(리더 선출), 이후 모든 데이터 변경은 리더가 순서를 정해 로그에 기록한 뒤 다른 서버들에게 그대로 복제합니다(로그 복제). 만약 리더가 갑자기 멈추면, 남은 서버들이 다시 투표해서 새 리더를 뽑아 서비스가 끊기지 않도록 합니다.
왜 중요한가
Raft는 여러 서버가 장애 상황에서도 하나의 일관된 상태를 유지하도록 만드는 문제를 실용적으로 해결했기 때문에, 분산 데이터베이스와 클러스터 관리 시스템을 다루는 시스템 논문에서 핵심 구성요소로 자주 인용됩니다. Paxos가 이론적으로 정확하지만 이해와 구현이 어렵다는 평가를 받아온 반면, Raft는 리더 선출과 로그 복제를 명확한 단계로 분리해 설계함으로써 실제 시스템 구현과 검증을 훨씬 쉽게 만들었다는 점에서 분산시스템 교육과 실무 양쪽에서 널리 채택되고 있습니다.
어떤 절차인가
Raft는 서버(노드)를 리더, 팔로워, 후보 세 역할 중 하나로 두고, 시간을 번호가 붙은 임기(term)로 나눕니다(Ongaro & Ousterhout, 2014).
- 리더 선출: 팔로워가 일정 시간(선거 타임아웃) 동안 리더의 신호를 받지 못하면 임기 번호를 올리고 후보가 되어 투표를 요청합니다. 과반의 표를 얻으면 리더가 됩니다. 타임아웃을 노드마다 무작위로 정해 여러 후보가 동시에 나서는 표 분산을 줄입니다.
- 로그 복제: 클라이언트 요청은 리더가 자기 로그에 추가하고 팔로워들에게 보냅니다.
- 확정(commit): 항목이 과반수 노드의 로그에 저장되면 확정되어 상태 기계에 적용됩니다. 이전 임기의 항목은 현재 임기의 항목이 확정될 때 함께 확정되는 방식으로 다룹니다.
- 구성 변경: 노드를 추가·제거할 때는 옛 구성과 새 구성이 겹치는 조인트 합의 단계를 거칩니다.
과반수 규칙 때문에 노드 n개 중 몇 개까지 고장 나도 동작하는지가 정해집니다(코드로 계산).
| 노드 수 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|
| 과반수 | 2 | 3 | 3 | 4 | 4 |
| 견딜 수 있는 고장 수 | 1 | 1 | 2 | 2 | 3 |
짝수 개(4, 6)는 홀수 개(3, 5)보다 견디는 고장 수가 늘지 않으므로 보통 홀수로 구성합니다.
언제 쓰고 무엇을 얻나
Raft는 여러 서버가 같은 순서로 같은 명령을 적용하도록 하는 복제 상태 기계에 쓰입니다. 분산 키-값 저장소, 설정·서비스 탐색 저장소(예: etcd, Consul) 같은 시스템이 Raft를 채택하고 있습니다. 얻는 성질은 임기마다 리더가 최대 한 명이고, 확정된 항목은 사라지지 않으며, 모든 노드가 같은 순서로 로그를 적용한다는 안전성입니다. 이 안전성은 메시지가 지연·유실·중복되고 노드가 멈췄다 다시 살아나는 환경을 가정합니다. 노드가 거짓 정보를 보내는 비잔틴 장애는 다루지 않습니다.
가용성은 과반수 노드가 서로 통신할 수 있을 때만 보장됩니다. 네트워크가 갈라져 과반이 없는 쪽은 새 항목을 확정하지 못합니다.
논문에는 이렇게 적는다
- 장애 모델: 비잔틴 장애를 가정하는지, 노드의 재시작과 저장소 보존을 가정하는지 밝힙니다.
- 매개변수: 노드 수, 선거 타임아웃 범위, 하트비트 간격. 원 논문은 선거 타임아웃의 예로 150~300 ms 범위를 제시했지만 네트워크 지연에 맞춰 조정해야 하는 값입니다.
- 구현과 검증: 직접 구현했는지 기존 라이브러리를 썼는지, 정확성을 어떻게 검증했는지(모델 검증, 장애 주입 시험 등)를 적습니다.
- 변형 여부: 원형에서 바꾼 부분(타임아웃 적응, 구성 변경 방식)을 구분해 적습니다.
제안 시스템은 Raft 합의 알고리즘으로 리더를 선출하고 로그를 복제한다(노드 5개, 선거 타임아웃 150–300 ms). (수치는 형식을 보여 주는 가상의 값입니다.)
논문에서는 이렇게 쓰입니다
실제 논문에서
이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.
예시 문장
아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.
이 문장은 서버 여러 대 중 하나가 갑자기 죽더라도, 나머지 서버들이 Raft 방식으로 새 리더를 뽑아 데이터가 어긋나지 않도록 계속 관리한다는 뜻입니다.
클러스터에 서버를 추가하거나 제거하는 구성 변경 과정에서도 데이터 일관성이 깨지지 않도록 Raft를 응용한 기법이 사용된다는 내용이다.
네트워크 환경이 불안정한 엣지 컴퓨팅 시스템에서는 Raft의 기본 파라미터를 그대로 쓰기 어려워 상황에 맞게 조정하는 연구가 이루어진다는 것을 보여준다.
조금 더 깊게 보면
Raft는 시간을 여러 개의 임기(term)로 나누고, 각 임기마다 최대 한 명의 리더만 존재하도록 보장하는 구조를 통해 합의의 정확성을 유지합니다.
팔로워가 일정 시간 동안 리더의 신호를 받지 못하면 스스로 후보자가 되어 선거를 시작하는데, 이때 노드마다 무작위화된 타임아웃 값을 사용해 여러 노드가 동시에 후보자가 되는 상황(선거 분열)을 줄이는 것이 설계상의 핵심 아이디어입니다.
로그 복제 과정에서도 리더가 로그 항목을 과반수 노드에 기록한 뒤에야 해당 항목을 확정(commit)하는 과반수 기반 합의 규칙을 따르며, 이 규칙 덕분에 소수 노드에 장애가 생겨도 시스템 전체는 계속 정상 동작할 수 있습니다.
주의할 점
Raft는 같은 문제를 푸는 합의 알고리즘인 Paxos보다 이해하고 구현하기 쉽도록 설계되었다는 점이 특징이지만, 그렇다고 성능이 항상 더 뛰어난 것은 아닙니다. 또한 Raft는 노드가 고장 나서 응답을 멈추는 상황(fail-stop)을 가정하며, 노드가 의도적으로 거짓 정보를 보내는 비잔틴 장애 허용 상황까지는 다루지 않습니다.
헷갈리기 쉬운 용어
Raft와 이웃한 합의 용어는 알고리즘, 문제 이름, 분야 이름으로 나뉩니다.
| 용어 | 무엇인가 | Raft와의 관계 |
|---|---|---|
| 팍소스 알고리즘 | 같은 합의 문제를 푸는 대표적 알고리즘 | Raft는 이해와 구현의 용이함을 목표로 설계되었습니다. 어느 쪽이 항상 빠르다고 말할 수는 없습니다. |
| 합의 알고리즘 | 여러 노드가 하나의 값에 동의하게 하는 알고리즘의 총칭 | Raft는 그 한 종류입니다. 블록체인의 합의 방식과는 가정이 다릅니다. |
| 분산 합의 | 분산 시스템에서의 합의 문제 | Raft가 푸는 문제 자체를 가리킵니다. |
참고 문헌
- Ongaro, D., & Ousterhout, J. (2014). In search of an understandable consensus algorithm. In Proceedings of the 2014 USENIX Annual Technical Conference (pp. 305–319). USENIX Association.
- Lamport, L. (1998). The part-time parliament. ACM Transactions on Computer Systems, 16(2), 133–169.
- Lamport, L. (2001). Paxos made simple. ACM SIGACT News, 32(4).
- Howard, H., & Mortier, R. (2020). Paxos vs Raft: Have we reached consensus on distributed consensus? In Proceedings of the 7th Workshop on Principles and Practice of Consistency for Distributed Data. ACM.
표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.