Raft는 Paxos와 대등했지만 이해하기 쉽게 설계되어 승리했다

Paxos는 인정받는 합의 알고리즘이었지만 이해하기 어렵고 구현하기 어려웠기에, 이를 기반으로 구축된 프로덕션 시스템은 리더 장애 시에만 드러나는 미묘한 버그에 취약했다.

Raft는 다른 우선순위를 두고 작성되었다. 즉 결함 허용성과 성능 면에서 Paxos와 동등하며, 차이는 이해하기 쉽도록 설계되었다는 점이다. 저자들은 합의를 리더 선출, 순서대로 복제되는 로그, 그리고 안전 규칙으로 나누었다.

이러한 분리가 더 넓은 대중이 이를 올바르게 구현할 수 있게 해주었다. 이해 가능성은 일급 요구사항으로 취급되었고, 그 결과는 팀이 실제로 추론하고 배포할 수 있는 합의 알고리즘이었다.

검증해야 하는 사람을 위해 알고리즘을 설계하라

이해 가능한 단계들은 프로그래머가 검증할 수 있는 것에 대응한다.

합의에서의 영리함은 구현 버그를 낳는 경향이 있다.

더 넓은 올바른 채택이 한계적인 성능 우위를 능가한다.

정확성이 많은 다른 이들이 올바르게 하는 것에 달려 있을 때는, 어려운 것을 검증하기 쉽게 만들어라. 단지 영리하기만 한 설계는 우아함에서 얻는 것보다 버그를 통해 더 많은 비용을 치른다.

Raft는 etcd, Consul, CockroachDB 및 기타 많은 분산 시스템에 채택되었고, 엔지니어들이 합의를 배우고 구축하는 기본 방식이 되었다.