합의 알고리즘과 리더 선출

여러 노드가 같은 데이터를 들고 있을 때, 누구 말이 맞는지 정하는 기준이 필요합니다. 쓰기를 한 곳으로 모으면 순서가 하나로 정해집니다. 그 한 곳이 리더입니다.

리더가 없으면 두 노드가 같은 자리에 다른 값을 쓰고, 나중에 어느 것이 맞는지 알 수 없게 됩니다. 시계로 판단하려 해도 서버마다 시계가 다릅니다.

선출 과정은 세 조각입니다.

임기 번호가 옛 리더 문제를 해결합니다. 네트워크가 끊겼다 돌아온 옛 리더가 명령을 내려도, 임기가 낮으므로 받는 쪽이 거절합니다.

대기 시간을 노드마다 다르게(무작위로) 두는 것도 중요합니다. 전부 동시에 후보가 되면 표가 갈려 아무도 과반을 못 얻고, 그게 반복되면 리더가 영영 안 정해집니다.

흔한 실수: 리더 선출을 직접 구현하는 것. 정상 경로는 쉬워 보이지만 무너지는 곳은 이상 경로입니다. 옛 리더의 복귀, 표 분산, 반쪽 네트워크. 세 가지 모두 평소에는 안 보이고 사고가 난 뒤에 틀렸다는 것을 알게 됩니다.

5대면 2대까지 견딥니다. 과반인 3대가 살아 있어야 결정을 내릴 수 있기 때문입니다.

짝수를 피하는 이유가 이 표에 있습니다. 3과 4가 똑같이 1대만 견딥니다. 한 대를 더 넣었는데 내결함성은 그대로이고, 과반이 2에서 3으로 늘어 쓰기마다 기다릴 상대만 늘어납니다. 6과 7도 같은 관계입니다. 짝수는 돈과 지연을 더 쓰고 얻는 것이 없습니다.

무한정 늘리지 않는 이유도 같습니다. 노드가 늘수록 견디는 고장은 늘지만 결정마다 더 많은 응답을 기다려야 해서 쓰기가 느려집니다. 그래서 5가 흔한 타협점입니다.

투표에만 참여하고 데이터를 안 들고 있는 노드를 두는 방식도 있습니다. 짝수 구성에서 동수를 깨는 용도인데, 그 노드가 죽으면 다시 짝수가 되므로 근본 해법은 아닙니다.

흔한 실수: 가용성을 올리려고 노드를 짝수로 늘리는 것. 합의 클러스터에서 노드 수는 과반을 만들 수 있는가로 정해집니다. 대수를 늘리는 것과 견디는 고장 수가 비례하지 않는 유일한 구성입니다.

교체는 순간이 아니라 구간입니다. 그 사이 쓰기가 거절되거나 멈춥니다.

첫 줄이 가장 아픕니다. 죽은 리더는 거절하지 않고 그냥 대답하지 않습니다. 그래서 클라이언트 타임아웃이 길면 그 시간만큼 요청이 쌓입니다. 합의 계층이 몇 초에 복구돼도 애플리케이션은 훨씬 오래 느립니다. 타임아웃을 짧게 잡는 것이 복구 시간을 정합니다.

준비할 것은 셋입니다. 쓰기 실패를 재시도하되 멱등하게 만들 것, 재시도 간격을 벌려 새 리더에 몰리지 않게 할 것, 그리고 이 구간에 사용자에게 무엇을 보여줄지 정해 둘 것.

읽기는 설정에 따라 다릅니다. 복제본에서 읽도록 허용했다면 이 구간에도 읽기는 되지만 조금 옛 데이터입니다. 그 거래를 받아들일지 미리 정해야 합니다.

흔한 실수: 합의 계층의 복구 시간만 보고 "몇 초면 된다" 고 보는 것. 사용자가 겪는 시간은 거기에 클라이언트 타임아웃과 재연결 몰림이 더해진 값입니다.

과반 규칙이 그 자체로 방어입니다. 양쪽이 동시에 과반이 될 수 없기 때문입니다.

5대가 3대와 2대로 갈리면, 3대 쪽만 리더를 뽑고 2대 쪽은 아무 결정도 못 합니다. 2대 쪽에 옛 리더가 있어도 과반의 응답을 못 받으므로 쓰기를 확정하지 못합니다.

그래서 남는 위험은 소수 쪽에서 읽는 것입니다. 옛 리더가 자기가 아직 리더인 줄 알고 읽기를 처리하면 낡은 값을 줍니다. 리더 임대(일정 시간마다 리더 자격을 갱신)로 막는데, 그 시간 동안은 여전히 낡을 수 있습니다.

정말 위험한 구성은 따로 있습니다. 분단된 양쪽이 각자 별개 클러스터로 재구성되는 경우입니다. 사람이 장애 대응 중 소수 쪽 노드 수를 줄여 과반을 만들어 주면 이것이 일어납니다. 양쪽이 각자 리더를 갖고 각자 쓰기를 받습니다.

흔한 실수: 장애 중에 급해서 노드 수 설정을 손으로 바꾸는 것. 과반 규칙이 지켜 주던 유일한 보호막을 사람이 직접 걷어내는 행동이고, 복구된 뒤 두 갈래 데이터를 합칠 방법이 없습니다.