Raft 합의 알고리즘
쉽게 풀면
회의록을 여러 명이 동시에 작성하면 누구 기록이 맞는지 혼란스러워집니다. 그래서 한 명을 "서기(리더)"로 정하고, 서기가 작성한 순서대로 나머지 사람들이 그대로 받아 적기로 약속하면 모두가 똑같은 기록을 갖게 됩니다. Raft는 여러 서버로 이루어진 분산 시스템에서 바로 이런 방식을 씁니다. 서버들은 먼저 투표를 통해 리더 하나를 뽑고(리더 선출), 이후 모든 데이터 변경은 리더가 순서를 정해 로그에 기록한 뒤 다른 서버들에게 그대로 복제합니다(로그 복제). 만약 리더가 갑자기 멈추면, 남은 서버들이 다시 투표해서 새 리더를 뽑아 서비스가 끊기지 않도록 합니다.
왜 중요한가
Raft는 여러 서버가 장애 상황에서도 하나의 일관된 상태를 유지하도록 만드는 문제를 실용적으로 해결했기 때문에, 분산 데이터베이스와 클러스터 관리 시스템을 다루는 시스템 논문에서 핵심 구성요소로 자주 인용됩니다. Paxos가 이론적으로 정확하지만 이해와 구현이 어렵다는 평가를 받아온 반면, Raft는 리더 선출과 로그 복제를 명확한 단계로 분리해 설계함으로써 실제 시스템 구현과 검증을 훨씬 쉽게 만들었다는 점에서 분산시스템 교육과 실무 양쪽에서 널리 채택되고 있습니다.
논문에서는 이렇게 쓰입니다
이 문장은 서버 여러 대 중 하나가 갑자기 죽더라도, 나머지 서버들이 Raft 방식으로 새 리더를 뽑아 데이터가 어긋나지 않도록 계속 관리한다는 뜻입니다.
클러스터에 서버를 추가하거나 제거하는 구성 변경 과정에서도 데이터 일관성이 깨지지 않도록 Raft를 응용한 기법이 사용된다는 내용이다.
네트워크 환경이 불안정한 엣지 컴퓨팅 시스템에서는 Raft의 기본 파라미터를 그대로 쓰기 어려워 상황에 맞게 조정하는 연구가 이루어진다는 것을 보여준다.
조금 더 깊게 보면
Raft는 시간을 여러 개의 임기(term)로 나누고, 각 임기마다 최대 한 명의 리더만 존재하도록 보장하는 구조를 통해 합의의 정확성을 유지합니다. 팔로워가 일정 시간 동안 리더의 신호를 받지 못하면 스스로 후보자가 되어 선거를 시작하는데, 이때 노드마다 무작위화된 타임아웃 값을 사용해 여러 노드가 동시에 후보자가 되는 상황(선거 분열)을 줄이는 것이 설계상의 핵심 아이디어입니다. 로그 복제 과정에서도 리더가 로그 항목을 과반수 노드에 기록한 뒤에야 해당 항목을 확정(commit)하는 과반수 기반 합의 규칙을 따르며, 이 규칙 덕분에 소수 노드에 장애가 생겨도 시스템 전체는 계속 정상 동작할 수 있습니다.
주의할 점
Raft는 같은 문제를 푸는 합의 알고리즘인 Paxos보다 이해하고 구현하기 쉽도록 설계되었다는 점이 특징이지만, 그렇다고 성능이 항상 더 뛰어난 것은 아닙니다. 또한 Raft는 노드가 고장 나서 응답을 멈추는 상황(fail-stop)을 가정하며, 노드가 의도적으로 거짓 정보를 보내는 비잔틴 장애 허용 상황까지는 다루지 않습니다.