Raft는 복제된 로그를 여러 서버가 같은 순서로 확정하도록 만드는 합의 알고리즘입니다. 안정적인 변경을 위해서는 리더가 살아 있다는 사실만으로 충분하지 않고, 클러스터 과반수와 통신할 수 있어야 합니다. Raft 논문은 선출·로그 복제·commit 규칙을 설명하고, etcd 용어집은 quorum을 상태 변경에 필요한 활성 멤버 수로 정의합니다.

quorum에는 리더 자신도 포함된다

멤버 수 N의 quorum은 floor(N/2)+1입니다. 3노드 클러스터라면 2개, 5노드라면 3개가 필요합니다. 리더도 클러스터 멤버이므로 자신을 포함해 계산합니다. 3노드 예에서 리더와 follower 한 대가 같은 로그 항목을 저장하면 2/3 과반수에 도달합니다. “리더를 제외한 follower 과반수”를 요구하는 것이 아닙니다.

이 숫자는 동시에 허용 가능한 실패 수를 가늠하는 데도 쓰입니다. 3노드는 한 대, 5노드는 두 대가 응답하지 않아도 나머지가 과반수를 이룰 수 있습니다. 다만 quorum을 잃은 쪽은 새 리더를 선출하거나 변경을 안전하게 commit할 수 없습니다. 기존 리더 프로세스가 소수 파티션에 남아 있어도 그 사실만으로 쓰기 권한이 생기지 않습니다.

election term과 로그 복제를 구별하기

Raft의 term은 선거를 구분하는 논리적 시대 번호입니다. 후보자는 투표를 요청하고 과반수의 표를 얻어 리더가 됩니다. 리더는 AppendEntries 요청으로 로그를 follower에 복제합니다. follower는 term과 로그 일관성 규칙에 따라 요청을 받아들이며, 새 리더 선출 규칙은 더 최신 로그를 가진 후보가 오래된 로그만 가진 후보보다 우선하도록 제한합니다.

운영자는 단순히 “어느 노드가 leader인가”만 볼 것이 아니라, 현재 term, 응답 중인 멤버 수, leader가 어느 index까지 복제했는지를 같이 살펴야 합니다. 한 follower가 느리더라도 과반수가 정상이라면 진행할 수 있지만, 과반수와 단절되면 정상적인 신규 변경 확정은 멈춰야 합니다.

현재 term 항목이 commit의 기준이다

중요한 예외가 있습니다. 리더는 이전 term에서 만들어진 로그 항목이 과반수에 복제됐다는 이유만으로 그 항목을 바로 commit할 수 없습니다. Raft 논문은 리더가 현재 term의 항목을 과반수에 복제한 경우 그 항목을 commit하도록 규정합니다. 이 조건을 만족하면 로그 일치 속성에 의해 앞선 항목도 간접적으로 commit됩니다.

이 규칙은 이전 리더가 복제했지만 확정하지 못한 항목을 새 리더가 덮어쓸 수 있는 상황을 안전하게 처리합니다. 따라서 “노드 절반 이상에 보인다”와 “commit되어 클라이언트가 확정된 값으로 볼 수 있다”는 같은 말이 아닙니다. 모니터링 화면의 복제 수만 보고 성공 응답을 추정하지 마세요.

분할 상황에서 기대할 동작

3노드 클러스터에서 A가 처음 리더라고 가정해 봅시다. A가 B와 C 모두와 단절되면 A는 소수 파티션에 남고, 서로 연결된 B와 C가 2/3 과반수를 이룹니다. B와 C는 새 리더를 선출하고 현재 term의 로그 항목을 과반수에 복제해 commit할 수 있습니다. A 프로세스는 자신을 리더라고 여길 수 있지만 quorum이 없어 새 항목을 안전하게 commit하지 못합니다. 네트워크가 복구되면 더 높은 term과 로그 일치 규칙에 따라 A가 새 리더를 따르고 충돌하는 미확정 로그를 정리합니다.

따라서 배포 전에는 노드 수뿐 아니라 장애 도메인, 네트워크 분할, 재시작 때의 멤버 설정을 점검하세요. Raft는 합의 규칙이지 애플리케이션의 재시도, idempotency, 백업, 복구 절차를 대신하지 않습니다.

참고 자료