Lecture 6: Fault Tolerance: Raft (1)

Raft

replication을 구현하는 방법 중 하나이다

 

홀수개의 서버로 구성

 - Raft는 majority vote를 통해 리더를 선출한다, 리더가 client request를 받는다

   => 이 때 죽어있는서버 살아있는서버 포함해서 majority달성해야한다 (2f+1 -> f failure까진 tolerant)
 - break symmetry
 - network parition이 발생했을때 적어도 한 partition은 majority를 달성할수있다

 

요청처리

리더는 클라이언트의 요청을 바로 처리하는 대신 log를 보낸다
리더는 AppendEntries message를 보내면서 서버가 어디까지 commit 되었는지 또 알려준다

이를 보고 follower가 어디까지 commit 할지 결정한다 (piggyback)

majority가 commit되면 클라이언트에 response를 보낸다

 

key-value 서버가 있다. 각 서버는 raft layer가있다

1. client request
2. request를 raft의 log로 넣는다 (-> start(command) - index, term있음)
3. 로그 엔트리가 commit되면 raft가 kv에게 channel로 메시지 보낸다 (applych에 ApplyMsg 담겨있다)( ApplyMsg 에는 index,command있다)

 

Why Leader?

효율적으로 replication 구성할수있게 한다. 모든 follower가 leader의 명령순서를 따르게 하여 일관된 순서 보장

리더는 replication 구성에 필수는 아니며 Paxos는 리더가없다

 

리더 선출과정

1. 모든서버는 start as followers

2. 리더 : 주기적으로 heartbeat 보냄 (AppendEntries RPC)
3. heartbeat 못받으면 리더가 없다고 가정 -> election 시작
4. candidate 서버는 term increment, 자기자신 투표, RequestVote RPCs in parallel to 다른 서버

5. majority vote를 받으면 리더가 된다 / 안 뽑히면 다시 timeout 기다림

 

candidate는 한번에 한서버만 되는 것이 원칙이다. 서버들은 찬반투표만 한다.

만약 거의 동시간에 모두가 리더가 되려고하면 각자 본인을 투표하기 때문에 아무도 리더가 될수없다. 그다음 term도 마찬가지이다

 => random timer : 모든 서버가 election timeout 다르다

random timer는 AppendEntries heart-beats interval 보다는 충분히 커야한다

각 서버의 timeout은 RPC Vote 주고 받는 시간 보단 커야한다

(RPC requestVote시간을 가정하고 그렇게 구현해하는지는 잘 모르겠음)

 

만약 old leader가 있다면?

follower들은 old leader의 메시지를 받아도 term과 다르기 때문에 무시한다
old leader는 본인의 term이 follower의 term과 다름을 깨닫고 leader역할을 하지 않는다