Raft - electionTimeout

broadcastTime ≪ electionTimeout ≪ MTBF

Raft가 정상적으로 동작하기 위해서는 반드시 위의 조건을 만족해야 한다. electionTimeout은 leader election에서 설명한 random 한 timeout의 최대치를 의미한다. 사실 broadcastTime, electionTimeout, MTBF 중에서 사용자가 설정할 수 있는 것은 electionTimeout 뿐이다. 따라서 위의 조건을 만족시킨다는 것은 적절한 electionTimeout을 선택한다는 것이다.

MTBF는 평균 무고장 시간(Mean time between failures)의 약자로, 한 서버가 시작한 뒤 죽기 전까지의 평균 시간을 의미한다. 보통 MTBF가 길면 availability가 높지만, availability와 일치하지는 않는다. MTBF가 길더라도 MTTR(Mean time to repair)가 길면 availability은 떨어질 수 있다.

MTBF는 시스템의 고유한 속성이다. MTBF는 보통 노드가 하는 일의 종류와 개발자의 숙련도, 얼마나 비싼 하드웨어를 사용하는지에 따라 결정된다.

Raft paper는 electionTimeout을 MTBF보다 작게 할 것을 권장한다. 실질적으로 MTBF는 최소 몇 주에서 몇 개월 정도 되기 때문에 electionTimeout을 이보다 더 크게 설정하는 것은 쉽지 않다. 이는 그냥 electionTimeout을 너무 크게 설정하지 말라는 정도로 받아들여도 된다. 리더가 죽은 뒤 electionTimeout 동안 client의 요청을 전혀 처리 못 하니 네트워크 전체의 availability를 올리기 위해서 가능하면 작은 electionTimeout을 설정해야 한다.

하지만 electionTimeout을 너무 작게 설정하면 안 된다. electionTimeout은 아무리 작아도 broadcastTime보다 커야 한다. broadcastTime이란, 한 노드에서 네트워크 안의 다른 모든 노드로 보낸 요청이 처리되어 응답이 오기까지 걸린 시간의 평균을 의미한다. 이 또한 MTBF와 마찬가지로 시스템의 고유한 속성이다. 하지만 숙련된 개발자나 비싼 하드웨어를 사용하여 올릴 수 있는 MTBF와는 다르게 broadcastTime은 물리적으로 최솟값이 정해진다.

만약 electionTimeout을 잘못 설정하여 broadcastTime보다 작게 설정한다면, follower들이 leader의 heartbeat을 듣지 못하고 자신을 candidate으로 만들어 requestVote 메시지만 전송하고 아무도 leader로 선택되지 못 하고 시간만 허비하게 된다.

Raft paper는 broadcastTime를 0.5 ms에서 20 ms 사이의 시간이 될 것을 가정하고 쓰여 있다. 따라서 다른 지역에 존재하는 서버 사이의 consensus가 아닌 한 지역에 존재하는 서버들 사이에서의 consensus를 위한 것이다. 만약 broadcastTime이 이보다 더 긴 네트워크를 구성했다면, electionTimeout도 더 길게 선택해야 한다.

예를 들어 AWS를 사용할 때, 서울과 오레곤 사이의 latency는 평균 120 ms정도 걸린다. 따라서 서울 지역과 오레곤 지역에 양쪽에 설치된 서버 사이의 consensus를 위해서는 electionTimeout을 120 ms보다 더 크게 설정해야 한다.