Raft - consistency

Raft는 모든 결정을 leader가 맡아서 한다. 따라서 term이 변경되기 전에는 leader의 결정을 따르면 된다. 문제는 leader에 문제가 생기거나 네트워크 파티션으로 인해 leader가 변경되고 다음 term으로 진행된 경우다.

Consistency를 위해 가장 이상적인 것은 모든 노드가 하나의 leader만 따르도록 하는 것이다. 하지만 이는 사실상 불가능하다. 이게 가능하면 애초에 합의에 도달한 것이다. 그래서 Raft에서는 특정 시간에 2개 이상의 리더가 존재할 수 있다. 단, state를 변경시킬 수 있는 리더는 1개 밖에 있을 수 없다. 이 두 말은 별 차이 없는 것 같지만, 이 차이가 분산 환경에서 구현 가능한 시스템이 되도록 만들어준다.

Raft에서는 leader에 커밋 된 로그만이 state를 변경시킨다. Leader가 커밋하기 위해서는 네트워크에 참여하는 노드 과반의 동의가 필요하다. 새 leader가 선출되면 과거의 leader는 절반 이상의 지지를 받지 못한다. 모든 요청에 요청하는 노드의 term이 담겨있고, 요청받은 쪽은 자신의 term보다 작은 term인 노드가 보낸 요청은 모두 거절한다. 새 leader가 선출됐다는 것은 이미 절반 이상의 노드가 다음 term으로 넘어갔다는 것이고 과거의 leader를 지지하는 노드는 절반이 되지 않기 때문에 과거 leader는 더 이상 상태를 변경시킬 수 없다. 따라서 같은 시간에 두 개의 노드가 상태를 변경시키는 것은 불가능하다.

물론 leader가 아닌 노드들이 가지고 있는 상태는 consistent 하지 않다. 새 RequestVote를 받기 전에 과거의 leader가 보낸 AppendEntries 메시지를 받고 자신의 상태를 변경시킬 수 있기 때문이다. 하지만 네트워크의 상태는 리더에 커밋 된 로그를 기준으로 만들어지기 때문에 각 노드의 inconsitecy는 클라이언트가 보는 네트워크 상태에 영향을 주지 않는다.

그렇다면 leader에 커밋 된 로그를 가지지 않은 노드가 leader가 되면 어떻게 될까? 다행히도 raft에서는 이런 일이 발생하지 않는다. RequestVote 메시지에는 candidate이 가지는 최신 로그의 index와 그 index가 생성된 term이 저장돼 있다. 이 index가 자신이 알고 있는 로그의 최신 index보다 작으면 이 RequestVote 요청은 거절된다. 즉, 가장 최신 로그를 가지고 있는 노드만 리더가 될 수 있고, 이 최신 로그에는 최소한 leader에 커밋 된 로그를 포함된다.

그렇다면 leader를 포함하여 커밋 된 로그를 가진 노드가 모두 죽으면 어떻게 될까? Leader가 어떤 로그를 커밋했다는 것은 최소 과반의 노드가 이 로그를 가지고 있다는 것이다. 이 노드가 모두 죽었다는 것은 네트워크에 남은 노드가 절반이 되지 않는다는 것이고 새 candidate을 지지하는 노드가 절반 이하가 되기 때문에 새 leader를 선출할 수 없고 이후로 네트워크는 상태를 변경할 수 없다. 만약 네트워크에 과반의 노드가 살아있다고 하면, 이는 비둘기집 원리에 따라 커밋 된 로그를 가지고 있는 노드가 최소한 한 개 존재한다는 것이고, 이 노드가 leader가 되면서 consistency를 유지된다.