분산 합의 마스터하기: 글로벌 시스템을 위한 Raft 알고리즘 구현 심층 분석

점점 더 상호 연결되는 세상에서 분산 시스템은 전자 상거래 플랫폼, 금융 기관에서 클라우드 컴퓨팅 인프라 및 실시간 통신 도구에 이르기까지 거의 모든 디지털 서비스의 백본입니다. 이러한 시스템은 워크로드와 데이터를 여러 머신에 분산함으로써 탁월한 확장성, 가용성 및 복원력을 제공합니다. 그러나 이러한 강력함에는 상당한 과제가 따릅니다. 바로 네트워크 지연, 노드 장애 및 동시 작업 발생 시에도 모든 구성 요소가 시스템 상태에 동의하도록 보장하는 것입니다. 이 근본적인 문제가 바로 분산 합의입니다.

비동기적이고 장애가 발생하기 쉬운 분산 환경에서 합의를 달성하는 것은 악명 높게 복잡합니다. 수십 년 동안 Paxos는 이 과제를 해결하는 지배적인 알고리즘이었으며, 이론적 건전성으로 존경받았지만 종종 복잡성과 구현의 어려움으로 비판받았습니다. 그러다 Raft 알고리즘이 등장했습니다. Raft는 이해 가능성을 주된 목표로 설계되었습니다. Raft는 내결함성 및 성능 측면에서 Paxos와 동등하지만, 개발자가 훨씬 더 쉽게 이해하고 기반을 구축할 수 있는 방식으로 구성되었습니다.

이 종합 가이드에서는 Raft 알고리즘을 깊이 파고들어 기본 원칙, 운영 메커니즘, 실질적인 구현 고려 사항 및 강력하고 전역적으로 분산된 애플리케이션을 구축하는 데 있어 중요한 역할을 탐구합니다. 숙련된 아키텍트, 분산 시스템 엔지니어 또는 고가용성 서비스를 구축하려는 개발자라면 Raft를 이해하는 것이 현대 컴퓨팅의 복잡성을 마스터하기 위한 필수적인 단계입니다.

현대 아키텍처에서 분산 합의의 필수적인 필요성

초당 수백만 건의 거래를 처리하는 글로벌 전자 상거래 플랫폼을 상상해 보세요. 고객 데이터, 재고 수준, 주문 상태 등 모든 것이 대륙에 걸쳐 있는 수많은 데이터 센터에 걸쳐 일관성을 유지해야 합니다. 은행 시스템의 원장(여러 서버에 분산됨)은 계좌 잔액에 대한 잠시의 불일치조차 감수할 수 없습니다. 이러한 시나리오는 분산 합의의 중요성을 강조합니다.

분산 시스템의 고유한 과제

분산 시스템은 본질적으로 모놀리식 애플리케이션에는 없는 수많은 과제를 야기합니다. 이러한 과제를 이해하는 것은 Raft와 같은 알고리즘의 우아함과 필요성을 이해하는 데 중요합니다.

• 부분 장애: 단일 서버는 작동하거나 완전히 실패하는 것과 달리, 분산 시스템에서는 일부 노드가 실패하고 다른 노드는 계속 작동할 수 있습니다. 서버가 충돌하거나, 네트워크 연결이 끊어지거나, 디스크가 손상될 수 있으며, 이 모든 것이 나머지 클러스터는 계속 작동하는 동안 발생할 수 있습니다. 시스템은 이러한 부분 장애에도 불구하고 올바르게 계속 작동해야 합니다.

• 네트워크 분할: 노드를 연결하는 네트워크가 항상 안정적인 것은 아닙니다. 네트워크 분할은 노드 하위 집합 간의 통신이 끊어질 때 발생하며, 노드가 계속 실행 중이더라도 특정 노드가 실패한 것처럼 보이게 합니다. 시스템의 다른 부분이 오래되거나 일관성 없는 정보를 기반으로 독립적으로 작동하는 이러한 '분할 두뇌' 시나리오를 해결하는 것이 핵심 합의 문제입니다.

• 비동기 통신: 노드 간 메시지가 지연되거나, 재정렬되거나, 완전히 손실될 수 있습니다. 글로벌 시계나 메시지 전달 시간에 대한 보장이 없으므로 이벤트의 일관된 순서나 확정적인 시스템 상태를 설정하기 어렵습니다.

• 동시성: 여러 노드가 동시에 동일한 데이터 조각을 업데이트하거나 작업을 시작하려고 시도할 수 있습니다. 이러한 작업을 조정하는 메커니즘 없이는 충돌과 불일치가 불가피합니다.

• 예측 불가능한 지연 시간: 특히 전역적으로 분산된 배포에서는 네트워크 지연 시간이 크게 다를 수 있습니다. 한 지역에서 빠른 작업이 다른 지역에서는 느릴 수 있으며, 이는 의사 결정 프로세스와 조정에 영향을 미칩니다.

왜 합의가 신뢰성의 초석인가

합의 알고리즘은 이러한 과제를 해결하기 위한 기본적인 빌딩 블록을 제공합니다. 이를 통해 신뢰할 수 없는 구성 요소 모음이 단일하고 매우 신뢰할 수 있으며 일관된 장치로 집합적으로 작동할 수 있습니다. 특히 합의는 다음을 달성하는 데 도움이 됩니다.

• 상태 머신 복제 (SMR): 많은 내결함성 분산 시스템의 핵심 아이디어입니다. 모든 노드가 작업 순서에 동의하고 각 노드가 동일한 초기 상태에서 시작하여 해당 작업을 동일한 순서로 실행하면 모든 노드가 동일한 최종 상태에 도달합니다. 합의는 이러한 전역 작업 순서에 동의하는 메커니즘입니다.

• 고가용성: 소수의 노드가 실패하더라도 시스템이 계속 작동하도록 허용함으로써 합의는 서비스가 접근 가능하고 기능하도록 보장하여 다운타임을 최소화합니다.

• 데이터 일관성: 데이터의 모든 복제본이 동기화되도록 보장하여 충돌하는 업데이트를 방지하고 클라이언트가 항상 최신이고 정확한 정보를 읽도록 합니다.

• 내결함성: 시스템은 특정 수의 임의 노드 장애(일반적으로 충돌 장애)를 허용하고 사람의 개입 없이도 계속 진행할 수 있습니다.

Raft 소개: 합의에 대한 이해 가능한 접근 방식

Raft는 학계에서 명확한 목표를 가지고 등장했습니다. 분산 합의를 쉽게 접근할 수 있도록 하는 것입니다. 저자인 Diego Ongaro와 John Ousterhout는 Raft를 이해 가능성에 중점을 두고 명시적으로 설계했으며, 합의 알고리즘의 더 넓은 채택과 올바른 구현을 가능하게 하는 것을 목표로 했습니다.

Raft의 핵심 설계 철학: 이해 가능성 우선

Raft는 합의의 복잡한 문제를 비교적 독립적인 여러 하위 문제로 분해하며, 각 하위 문제는 고유한 규칙과 동작 세트를 가집니다. 이 모듈성은 이해를 크게 돕습니다. 주요 설계 원칙은 다음과 같습니다.

• 리더 중심 접근 방식: 모든 노드가 의사 결정에 동등하게 참여하는 다른 합의 알고리즘과 달리, Raft는 단일 리더를 지정합니다. 리더는 복제된 로그를 관리하고 모든 클라이언트 요청을 조정하는 책임이 있습니다. 이는 로그 관리를 단순화하고 노드 간의 상호 작용 복잡성을 줄입니다.

• 강력한 리더: 리더는 새로운 로그 항목을 제안하고 커밋 시점을 결정하는 궁극적인 권위자입니다. 팔로워는 수동으로 리더의 로그를 복제하고 리더의 요청에 응답합니다.

• 결정론적 선출: Raft는 무작위 선출 타임아웃을 사용하여 주어진 선출 기간에 일반적으로 하나의 후보만 리더로 부상하도록 합니다.

• 로그 일관성: Raft는 복제된 로그에 대한 강력한 일관성 속성을 강제하여 커밋된 항목이 롤백되지 않으며 모든 커밋된 항목이 결국 사용 가능한 모든 노드에 나타나도록 보장합니다.

Paxos와의 간략한 비교

Raft 이전에는 Paxos가 분산 합의의 사실상 표준이었습니다. 강력하지만 Paxos는 이해하고 올바르게 구현하기가 매우 어렵습니다. 역할(제안자, 수락자, 학습자)을 분리하고 동시에 여러 리더가 존재할 수 있도록 하는(단, 하나의 리더만 값을 커밋할 수 있음) 설계는 복잡한 상호 작용과 엣지 케이스를 초래할 수 있습니다.

대조적으로 Raft는 상태 공간을 단순화합니다. 리더가 모든 로그 변경의 책임이 있는 강력한 리더 모델을 강제합니다. 역할을 명확하게 정의(리더, 팔로워, 후보)하고 그 사이의 전환을 정의합니다. 이 구조는 Raft의 동작을 더 직관적이고 추론하기 쉽게 만들어 구현 버그를 줄이고 개발 주기를 단축합니다. 처음에 Paxos로 어려움을 겪었던 많은 실제 시스템이 Raft를 채택함으로써 성공을 거두었습니다.

Raft의 세 가지 기본 역할

언제든지 Raft 클러스터의 각 서버는 리더, 팔로워 또는 후보의 세 가지 상태 중 하나에 있습니다. 이러한 역할은 배타적이고 동적이며, 서버는 특정 규칙과 이벤트를 기반으로 전환합니다.

1. 팔로워

• 수동적 역할: 팔로워는 Raft에서 가장 수동적인 상태입니다. 리더 및 후보로부터의 요청에 단순히 응답합니다.

• 하트비트 수신: 팔로워는 정기적으로 리더로부터 하트비트(빈 AppendEntries RPC)를 수신할 것으로 예상합니다. 팔로워가 특정 election timeout 기간 내에 하트비트 또는 AppendEntries RPC를 수신하지 못하면 리더가 실패했다고 가정하고 후보 상태로 전환합니다.

• 투표: 선거 기간 동안 팔로워는 기간당 최대 한 명의 후보에게 투표합니다.

• 로그 복제: 팔로워는 리더의 지시에 따라 로컬 로그에 로그 항목을 추가합니다.

2. 후보

• 선거 시작: 팔로워가 타임아웃(리더로부터 소식을 듣지 못함)되면 새로운 선거를 시작하기 위해 후보 상태로 전환합니다.

• 자체 투표: 후보는 current term을 증가시키고, 자신에게 투표하며, 클러스터의 모든 다른 서버에 RequestVote RPC를 보냅니다.

• 선거 승리: 후보가 동일한 기간에 클러스터 서버 과반수로부터 투표를 받으면 리더 상태로 전환합니다.

• 단계적 축소: 후보가 더 높은 기간을 가진 다른 서버를 발견하거나 합법적인 리더로부터 AppendEntries RPC를 받으면 팔로워 상태로 되돌아갑니다.

3. 리더

• 유일한 권위: 주어진 기간에 Raft 클러스터에는 한 번에 단 하나의 리더만 있습니다. 리더는 모든 클라이언트 상호 작용, 로그 복제 및 일관성 보장에 책임이 있습니다.

• 하트비트 전송: 리더는 리더십을 유지하고 새로운 선거를 방지하기 위해 주기적으로 모든 팔로워에게 AppendEntries RPC(하트비트)를 보냅니다.

• 로그 관리: 리더는 클라이언트 요청을 수락하고, 로컬 로그에 새로운 로그 항목을 추가한 다음, 이러한 항목을 모든 팔로워에게 복제합니다.

• 커밋: 리더는 항목이 과반수 서버에 안전하게 복제되어 상태 머신에 커밋될 수 있다고 결정합니다.

• 단계적 축소: 리더가 더 높은 term을 가진 서버를 발견하면 즉시 단계적 축소하고 팔로워로 되돌아갑니다. 이는 시스템이 항상 가장 높은 알려진 기간으로 진행되도록 보장합니다.

Raft의 운영 단계: 상세한 워크스루

Raft는 리더 선출과 로그 복제의 지속적인 주기를 통해 운영됩니다. 이 두 가지 주요 메커니즘과 중요한 안전 속성이 클러스터가 일관성과 내결함성을 유지하도록 보장합니다.

1. 리더 선출

리더 선출 프로세스는 Raft 운영의 기초이며, 클러스터에 항상 작업을 조정할 단일 권위 있는 노드가 있도록 보장합니다.

• 선거 타임아웃: 각 팔로워는 무작위 election timeout(일반적으로 150-300ms)을 유지합니다. 팔로워가 현재 리더로부터 이 타임아웃 기간 내에 통신(하트비트 또는 AppendEntries RPC)을 수신하지 못하면 리더가 실패했거나 네트워크 분할이 발생했다고 가정합니다.

• 후보로 전환: 타임아웃 시 팔로워는 Candidate 상태로 전환합니다. current term을 증가시키고, 자신에게 투표하며, 선거 타이머를 재설정합니다.

• RequestVote RPC: 후보는 클러스터의 다른 모든 서버에 RequestVote RPC를 보냅니다. 이 RPC에는 후보의 current term, candidateId 및 last log index 및 last log term에 대한 정보가 포함됩니다(안전을 위해 왜 이것이 중요한지는 나중에 설명).

• 투표 규칙: 서버는 다음 조건 중 하나라도 충족하면 후보에게 투표를 부여합니다.
  1. 해당 current term이 후보의 기간보다 작거나 같습니다.

  2. 현재 기간에 다른 후보에게 아직 투표하지 않았습니다.

  3. 후보의 로그가 자체 로그만큼 최신입니다. 이는 last log term을 먼저 비교한 다음, 기간이 같으면 last log index를 비교하여 결정됩니다. 후보는 유권자의 로그가 포함하는 모든 커밋된 항목을 포함하는 경우 '최신'입니다. 이는 선거 제한이라고 하며 안전을 위해 중요합니다.

• 선거 승리: 후보가 동일한 기간에 클러스터 서버 과반수로부터 투표를 받으면 새로운 리더가 됩니다. 선출되면 새로운 리더는 즉시 다른 모든 서버에 AppendEntries RPC(하트비트)를 보내 리더십을 확립하고 새로운 선거를 방지합니다.

• 분할 투표 및 재시도: 여러 후보가 동시에 발생하여 어느 후보도 과반수를 얻지 못하는 분할 투표로 이어질 수 있습니다. 이를 해결하기 위해 각 후보는 무작위 선출 타임아웃을 가집니다. 후보의 타임아웃이 선거에서 승리하거나 새로운 리더로부터 소식을 듣지 못하고 만료되면, 기간을 증가시키고 새로운 선거를 시작합니다. 무작위화는 분할 투표가 드물고 신속하게 해결되도록 하는 데 도움이 됩니다.

• 더 높은 기간 발견: 후보(또는 모든 서버)가 자신의 current term보다 높은 term을 가진 RPC를 수신하면 즉시 current term을 더 높은 값으로 업데이트하고 follower 상태로 되돌아갑니다. 이는 오래된 정보를 가진 서버가 리더가 되려고 시도하거나 합법적인 리더를 방해하지 않도록 보장합니다.

2. 로그 복제

리더가 선출되면 주요 책임은 복제된 로그를 관리하고 클러스터 전반의 일관성을 보장하는 것입니다. 여기에는 클라이언트 명령 수락, 로그에 추가, 팔로워에게 복제가 포함됩니다.

• 클라이언트 요청: 모든 클라이언트 요청(상태 머신에서 실행될 명령)은 리더에게 전달됩니다. 클라이언트가 팔로워에게 연락하면 팔로워는 리더에게 요청을 전달합니다.

• 리더 로그에 추가: 리더가 클라이언트 명령을 받으면 명령을 로컬 로그의 새 log entry로 추가합니다. 각 로그 항목에는 자체 명령, 수신된 term 및 log index가 포함됩니다.

• AppendEntries RPC: 리더는 모든 팔로워에게 AppendEntries RPC를 보내 새 로그 항목(또는 항목 배치)을 로그에 추가하도록 요청합니다. 이러한 RPC에는 다음이 포함됩니다.
  • term: 리더의 현재 기간.

  • leaderId: 리더의 ID(팔로워가 클라이언트를 리디렉션하기 위함).

  • prevLogIndex: 새 항목 바로 앞의 로그 항목의 인덱스.

  • prevLogTerm: prevLogIndex 항목의 기간. 이 두 가지(prevLogIndex, prevLogTerm)는 로그 일치 속성에 중요합니다.

  • entries[]: 저장할 로그 항목(하트비트의 경우 비어 있음).

  • leaderCommit: 리더의 commitIndex(커밋된 것으로 알려진 가장 높은 로그 항목의 인덱스).

• 일관성 검사 (로그 일치 속성): 팔로워가 AppendEntries RPC를 수신하면 일관성 검사를 수행합니다. prevLogIndex에 prevLogTerm과 일치하는 기간을 가진 항목이 있는지 자신의 로그에서 확인합니다. 이 검사가 실패하면 팔로워는 AppendEntries RPC를 거부하고 로그가 일관되지 않음을 리더에게 알립니다.

• 불일치 해결: 팔로워가 AppendEntries RPC를 거부하면 리더는 해당 팔로워의 nextIndex를 감소시키고 AppendEntries RPC를 다시 시도합니다. nextIndex는 리더가 특정 팔로워에게 보낼 다음 로그 항목의 인덱스입니다. 이 프로세스는 nextIndex가 리더와 팔로워의 로그가 일치하는 지점에 도달할 때까지 계속됩니다. 일치가 발견되면 팔로워는 후속 로그 항목을 수락하고 결국 로그를 리더와 일치시킬 수 있습니다.

• 항목 커밋: 항목은 리더가 과반수 서버(자신 포함)에 성공적으로 복제된 것으로 간주될 때 커밋된 것으로 간주됩니다. 커밋되면 상태 머신에 적용될 수 있습니다. 리더는 commitIndex를 업데이트하고 이를 후속 AppendEntries RPC에 포함하여 커밋된 항목에 대한 팔로워에게 알립니다. 팔로워는 리더의 leaderCommit을 기반으로 commitIndex를 업데이트하고 해당 인덱스까지의 항목을 상태 머신에 적용합니다.

• 리더 완전성 속성: Raft는 특정 기간에 커밋된 로그 항목은 모든 후속 리더에도 해당 항목이 포함될 것임을 보장합니다. 이 속성은 커밋된 데이터 손실을 방지하기 위해 중요하며, 주로 선거 제한에 의해 보장됩니다. 이는 리더가 커밋된 항목을 덮어쓰거나 놓칠 수 있는 리더가 선출되는 것을 방지합니다.

3. 안전 속성 및 보증

Raft의 견고성은 불일치와 데이터 무결성을 방지하는 몇 가지 신중하게 설계된 안전 속성에서 비롯됩니다.

• 선거 안전: 주어진 기간에 최대 하나의 리더만 선출될 수 있습니다. 이는 팔로워가 기간당 최대 한 표만 부여하고 후보가 과반수 투표를 받아야 하는 투표 메커니즘에 의해 강제됩니다.

• 리더 완전성: 로그 항목이 주어진 기간에 커밋된 경우, 해당 항목은 모든 후속 리더의 로그에 존재합니다. 이는 커밋된 데이터 손실을 방지하는 데 중요하며, 주로 리더 완전성 속성에 의해 보장됩니다.

• 로그 일치 속성: 두 로그가 동일한 인덱스와 기간을 가진 항목을 포함하는 경우, 두 로그는 이전 모든 항목에서 동일합니다. 이는 로그 일관성 검사를 단순화하고 리더가 팔로워의 로그를 효율적으로 최신 상태로 가져올 수 있도록 합니다.

• 커밋 안전: 항목이 커밋되면 결코 롤백되거나 덮어쓰이지 않습니다. 이는 리더 완전성 및 로그 일치 속성의 직접적인 결과입니다. 항목이 커밋되면 영구적으로 저장된 것으로 간주됩니다.

Raft의 주요 개념 및 메커니즘

역할과 운영 단계를 넘어 Raft는 상태를 관리하고 정확성을 보장하기 위해 몇 가지 핵심 개념에 의존합니다.

1. 기간 (Terms)

Raft의 term은 지속적으로 증가하는 정수입니다. 이는 클러스터의 논리적 시계 역할을 합니다. 각 기간은 선거로 시작되며, 선거가 성공하면 해당 기간 동안 단일 리더가 선출됩니다. 기간은 오래된 정보를 식별하고 서버가 항상 최신 정보에 우선하도록 하는 데 중요합니다.

• 서버는 모든 RPC에서 current term을 교환합니다.

• 서버가 다른 서버보다 더 높은 term을 발견하면 자신의 current term을 업데이트하고 follower 상태로 되돌아갑니다.

• 후보 또는 리더가 자신의 term이 오래되었음을 발견하면(다른 서버의 term보다 낮음) 즉시 단계적 축소합니다.

2. 로그 항목 (Log Entries)

log는 Raft의 핵심 구성 요소입니다. 이는 상태 머신에서 실행될 명령을 나타내는 항목의 정렬된 순서입니다. 각 log entry에는 다음이 포함됩니다.

• 명령: 수행할 실제 작업(예: "x=5 설정", "사용자 생성").

• Term: 항목이 리더에서 생성된 기간.

• Index: 로그에서의 위치. 로그 항목은 인덱스에 의해 엄격하게 정렬됩니다.

로그는 지속적이어서 충돌 중 데이터 손실을 방지하기 위해 클라이언트에 응답하기 전에 항목이 안정적인 저장소에 기록됩니다.

3. 상태 머신 (State Machine)

Raft 클러스터의 모든 서버는 state machine을 유지합니다. 이는 커밋된 로그 항목을 처리하는 애플리케이션별 구성 요소입니다. 일관성을 보장하기 위해 상태 머신은 결정론적이어야 합니다(동일한 초기 상태와 명령 시퀀스가 주어지면 항상 동일한 출력과 최종 상태를 생성함). 또한 멱등성이 있어야 합니다(동일한 명령을 여러 번 적용하는 것은 한 번 적용하는 것과 동일한 효과를 가짐. 이는 재시도를 정상적으로 처리하는 데 도움이 되지만, Raft의 로그 커밋은 단일 적용을 크게 보장함).

4. 커밋 인덱스 (Commit Index)

commitIndex는 커밋된 것으로 알려진 가장 높은 로그 항목 인덱스입니다. 이는 과반수 서버에 안전하게 복제되어 상태 머신에 적용될 수 있음을 의미합니다. 리더는 commitIndex를 결정하고 팔로워는 리더의 AppendEntries RPC를 기반으로 commitIndex를 업데이트합니다. commitIndex까지의 모든 항목은 영구적으로 간주되며 롤백될 수 없습니다.

5. 스냅샷 (Snapshots)

시간이 지남에 따라 복제된 로그가 매우 커져 상당한 디스크 공간을 차지하고 로그 복제 및 복구를 느리게 할 수 있습니다. Raft는 snapshots를 사용하여 이를 해결합니다. 스냅샷은 특정 시점의 상태 머신 상태를 간결하게 표현한 것입니다. 전체 로그를 유지하는 대신 서버는 주기적으로 상태를 '스냅샷'하고, 스냅샷 지점까지의 모든 로그 항목을 삭제한 다음, 스냅샷을 새 팔로워 또는 지연된 팔로워에게 복제할 수 있습니다. 이 프로세스는 효율성을 크게 향상시킵니다.

• 로그 압축: 지속적인 로그 데이터 양을 줄입니다.

• 더 빠른 복구: 새롭거나 충돌한 서버는 처음부터 전체 로그를 다시 재생하는 대신 스냅샷을 받을 수 있습니다.

• InstallSnapshot RPC: Raft는 스냅샷을 리더에서 팔로워로 전송하기 위한 InstallSnapshot RPC를 정의합니다.

효과적이지만 스냅샷은 동시 스냅샷 생성, 로그 절단 및 전송 관리에서 구현에 복잡성을 더합니다.

Raft 구현: 글로벌 배포를 위한 실질적인 고려 사항

Raft의 우아한 설계를 강력하고 프로덕션 준비가 된 시스템으로 변환하는 것, 특히 전역 대상 및 다양한 인프라를 위해서는 몇 가지 실질적인 엔지니어링 과제를 해결해야 합니다.

1. 글로벌 맥락에서의 네트워크 지연 및 분할

전역적으로 분산된 시스템의 경우 네트워크 지연이 중요한 요소입니다. Raft 클러스터는 일반적으로 로그 항목을 커밋하기 전에 항목에 동의할 과반수의 노드를 필요로 합니다. 대륙에 걸쳐 분포된 클러스터에서는 노드 간 지연 시간이 수백 밀리초가 될 수 있습니다. 이는 다음 사항에 직접적인 영향을 미칩니다.

• 커밋 지연 시간: 클라이언트 요청이 커밋되는 데 걸리는 시간은 과반수 복제본에 대한 가장 느린 네트워크 링크로 인해 병목 현상이 발생할 수 있습니다. 읽기 전용 팔로워(항상 오래된 읽기에 대한 리더 상호 작용이 필요하지 않음) 또는 지리적으로 인식된 쿼럼 구성(예: 5노드 클러스터에 3노드, 다른 지역에 2노드. 여기서 과반수는 단일 빠른 지역 내에 있을 수 있음)과 같은 전략이 이를 완화할 수 있습니다.

• 리더 선출 속도: 높은 지연 시간은 RequestVote RPC를 지연시켜 더 빈번한 분할 투표 또는 더 긴 선출 시간으로 이어질 수 있습니다. 선출 타임아웃을 일반적인 노간 지연 시간보다 훨씬 더 크게 조정하는 것이 중요합니다.

• 네트워크 분할 처리: 실제 네트워크는 분할에 취약합니다. Raft는 과반수 서버가 포함된 분할만 리더를 선출하고 진행할 수 있도록 함으로써 분할을 올바르게 처리합니다. 소수 분할은 새 항목을 커밋할 수 없어 분할 두뇌 시나리오를 방지합니다. 그러나 글로벌 배포에서의 장기간 분할은 특정 지역에서 가용성 부족을 초래할 수 있으며, 쿼럼 배치에 대한 신중한 아키텍처 결정이 필요합니다.

2. 영구 저장소 및 내구성

Raft의 정확성은 로그 및 상태의 영구성에 크게 의존합니다. 서버가 RPC에 응답하거나 상태 머신에 항목을 적용하기 전에 관련 데이터(로그 항목, current term, votedFor)가 안정적인 저장소에 기록되고 fsync'd(디스크에 플러시됨)되었는지 확인해야 합니다. 이는 충돌 시 데이터 손실을 방지합니다. 고려 사항은 다음과 같습니다.

• 성능: 빈번한 디스크 쓰기는 성능 병목 현상이 될 수 있습니다. 쓰기 일괄 처리 및 고성능 SSD 사용이 일반적인 최적화입니다.

• 신뢰성: 강력하고 내구성이 뛰어난 저장소 솔루션(로컬 디스크, 네트워크 연결 저장소, 클라우드 블록 저장소)을 선택하는 것이 중요합니다.

• WAL (Write-Ahead Log): 종종 Raft 구현은 데이터베이스와 유사하게 WAL을 사용하여 내구성을 확보하여 변경 사항이 메모리에 적용되기 전에 디스크에 기록되도록 합니다.

3. 클라이언트 상호 작용 및 일관성 모델

클라이언트는 리더에게 요청을 보내 Raft 클러스터와 상호 작용합니다. 클라이언트 요청 처리는 다음을 포함합니다.

• 리더 검색: 클라이언트는 현재 리더를 찾기 위한 메커니즘이 필요합니다. 이는 서비스 검색 메커니즘, 고정된 리디렉션 엔드포인트 또는 서버를 시도하여 응답하는 서버를 찾을 때까지 수행할 수 있습니다.

• 요청 재시도: 리더가 변경되거나 네트워크 오류가 발생하면 클라이언트는 요청을 재시도할 준비가 되어 있어야 합니다.

• 읽기 일관성: Raft는 주로 쓰기에 대한 강력한 일관성을 보장합니다. 읽기의 경우 여러 모델이 가능합니다.
  • 강력하게 일관된 읽기: 클라이언트는 리더에게 읽기를 제공하기 전에 팔로워 과반수에게 하트비트를 보내 상태가 최신인지 확인할 수 있습니다. 이는 신선도를 보장하지만 지연 시간을 추가합니다.

  • 리더 임대 읽기: 리더는 짧은 기간 동안 과반수 노드로부터 '임대'를 획득할 수 있으며, 이 기간 동안에는 더 이상의 합의 없이 읽기를 제공할 수 있음을 알고 있습니다. 이는 더 빠르지만 시간 제한이 있습니다.

  • 오래된 읽기(팔로워로부터): 팔로워에서 직접 읽는 것은 지연 시간을 줄일 수 있지만, 팔로워의 로그가 리더보다 뒤떨어지는 경우 오래된 데이터를 읽을 위험이 있습니다. 이는 최종 일관성이 읽기에 충분한 애플리케이션에는 허용됩니다.

4. 구성 변경 (클러스터 멤버십)

Raft 클러스터의 멤버십 변경(서버 추가 또는 제거)은 일관성 또는 분할 두뇌 시나리오를 방지하기 위해 합의를 통해 수행되어야 하는 복잡한 작업입니다. Raft는 Joint Consensus라는 기술을 제안합니다.

• 두 가지 구성: 구성 변경 중에는 시스템이 임시로 두 개의 겹치는 구성(기존 구성 C_old 및 새 구성 C_new)으로 작동합니다.

• Joint Consensus 상태 (C_old, C_new): 리더는 공동 구성을 나타내는 특수 로그 항목을 제안합니다. 이 항목이 커밋되면(C_old 및 C_new 모두에서 과반수 동의 필요), 시스템은 전환 상태에 있습니다. 이제 의사 결정은 두 구성 모두의 과반수를 요구합니다. 이는 전환 중에 이전 구성 또는 새 구성이 단독으로 의사 결정을 내릴 수 없어 불일치를 방지합니다.

• C_new로 전환: 공동 구성 로그 항목이 커밋되면 리더는 새 구성(C_new)만 나타내는 다른 로그 항목을 제안합니다. 이 두 번째 항목이 커밋되면 이전 구성은 삭제되고 시스템은 C_new에 따라 작동합니다.

• 안전성: 이 2단계 커밋과 유사한 프로세스는 어느 시점에서도 두 개의 충돌하는 리더(C_old 하의 리더, C_new 하의 리더)가 선출될 수 없으며, 변경 중에 시스템이 계속 작동함을 보장합니다.

구성 변경을 올바르게 구현하는 것은 전환 상태 중 수많은 엣지 케이스와 장애 시나리오로 인해 Raft 알고리즘 구현에서 가장 어려운 부분 중 하나입니다.

5. 분산 시스템 테스트: 엄격한 접근 방식

Raft와 같은 분산 합의 알고리즘을 테스트하는 것은 비결정론적 특성과 수많은 장애 모드로 인해 매우 어렵습니다. 간단한 단위 테스트로는 충분하지 않습니다. 엄격한 테스트에는 다음이 포함됩니다.

• 장애 주입: 노드 충돌, 네트워크 분할, 메시지 지연 및 메시지 재정렬과 같은 장애를 체계적으로 도입합니다. Jepsen과 같은 도구는 이 목적으로 특별히 설계되었습니다.

• 속성 기반 테스트: 불변 및 안전 속성(예: 기간당 최대 하나의 리더, 커밋된 항목은 절대 손실되지 않음)을 정의하고 다양한 조건에서 구현이 이를 준수하는지 테스트합니다.

• 모델 검사: 중요한 알고리즘 부분의 경우, 올바름을 증명하기 위해 형식 검증 기법을 사용할 수 있지만, 이는 매우 전문화된 영역입니다.

• 시뮬레이션 환경: 전역 배포의 일반적인 네트워크 조건(지연 시간, 패킷 손실)을 시뮬레이션하는 환경에서 테스트를 실행합니다.

사용 사례 및 실제 애플리케이션

Raft의 실용성과 이해 가능성은 다양한 중요 인프라 구성 요소에 널리 채택되는 결과를 가져왔습니다.

1. 분산 키-값 저장소 및 데이터베이스 복제

• etcd: Kubernetes의 기반 구성 요소인 etcd는 Raft를 사용하여 구성 데이터, 서비스 검색 정보 및 클러스터 상태 관리를 저장하고 복제합니다. Kubernetes가 올바르게 작동하려면 그 신뢰성이 가장 중요합니다.

• Consul: HashiCorp에서 개발한 Consul은 분산 저장소 백엔드에 Raft를 사용하여 동적 인프라 환경에서 서비스 검색, 상태 확인 및 구성 관리를 가능하게 합니다.

• TiKV: TiDB(분산 SQL 데이터베이스)에서 사용되는 분산 트랜잭션 키-값 저장소는 데이터 복제 및 일관성 보장을 위해 Raft를 구현합니다.

• CockroachDB: 이 전역적으로 분산된 SQL 데이터베이스는 지역 전체 장애에도 불구하고 고가용성과 강력한 일관성을 보장하기 위해 다중 노드 및 지리적 영역에 걸쳐 데이터를 복제하는 데 Raft를 광범위하게 사용합니다.

2. 서비스 검색 및 구성 관리

Raft는 클러스터 전체의 서비스 및 구성에 대한 중요 메타데이터를 저장하고 배포해야 하는 시스템을 위한 이상적인 기반을 제공합니다. 서비스가 등록되거나 구성이 변경될 때 Raft는 모든 노드가 새로운 상태에 결국 동의하도록 보장하여 수동 개입 없이 동적 업데이트를 가능하게 합니다.

3. 분산 트랜잭션 조정자

여러 작업 또는 서비스에 걸쳐 원자성을 요구하는 시스템의 경우, Raft는 분산 트랜잭션 조정자의 기반이 되어 참가자 전체에 걸쳐 변경 사항을 커밋하기 전에 트랜잭션 로그가 일관되게 복제되도록 할 수 있습니다.

4. 기타 시스템의 클러스터 조정 및 리더 선출

명시적인 데이터베이스 또는 키-값 저장소 사용 외에도 Raft는 조정 작업을 관리하거나, 다른 분산 프로세스의 리더를 선출하거나, 대규모 시스템에서 신뢰할 수 있는 제어 평면을 제공하기 위해 라이브러리 또는 핵심 구성 요소로 종종 포함됩니다. 예를 들어, 많은 클라우드 네이티브 솔루션은 제어 평면 구성 요소의 상태를 관리하기 위해 Raft를 활용합니다.

Raft의 장점과 단점

Raft는 상당한 이점을 제공하지만, 절충점을 이해하는 것이 중요합니다.

장점:

• 이해 가능성: 주요 설계 목표로, 이전 합의 알고리즘(예: Paxos)보다 구현, 디버깅 및 추론하기가 더 쉽습니다.

• 강력한 일관성: 커밋된 로그 항목에 대한 강력한 일관성 보장을 제공하여 데이터 무결성과 신뢰성을 보장합니다.

• 내결함성: 가용성 또는 일관성을 잃지 않고 소수의 노드(N개 노드 클러스터에서 (N-1)/2개 장애까지)를 허용합니다.

• 성능: 안정적인 조건(리더 변경 없음)에서 Raft는 리더가 모든 요청을 순차적으로 처리하고 병렬로 복제하여 네트워크 대역폭을 효율적으로 활용하므로 높은 처리량을 달성할 수 있습니다.

• 정의된 역할: 명확한 역할(리더, 팔로워, 후보) 및 상태 전환은 정신 모델과 구현을 단순화합니다.

• 구성 변경: 클러스터에서 노드를 안전하게 추가하거나 제거하기 위한 강력한 메커니즘(Joint Consensus)을 제공합니다.

단점:

• 리더 병목 현상: 모든 클라이언트 쓰기 요청은 리더를 통과해야 합니다. 극도로 높은 쓰기 처리량 또는 리더가 클라이언트에서 지리적으로 멀리 떨어진 시나리오에서는 이것이 성능 병목 현상이 될 수 있습니다.

• 읽기 지연 시간: 강력하게 일관된 읽기를 달성하려면 종종 리더와의 통신이 필요하며 잠재적으로 지연 시간이 추가될 수 있습니다. 팔로워에서 읽는 것은 오래된 데이터를 읽을 위험이 있습니다.

• 쿼럼 요구 사항: 새 항목을 커밋하려면 과반수 노드를 사용할 수 있어야 합니다. 5노드 클러스터에서는 2개의 장애를 허용합니다. 3개의 노드가 실패하면 클러스터는 쓰기에 대해 사용 불가능하게 됩니다. 이는 지역 간 과반수를 유지하기 어려운 분할되거나 지리적으로 분산된 환경에서는 어려울 수 있습니다.

• 네트워크 민감도: 네트워크 지연 시간 및 분할에 매우 민감하며, 특히 광범위하게 분산된 배포에서 선출 시간 및 전반적인 시스템 처리량에 영향을 미칠 수 있습니다.

• 구성 변경의 복잡성: 강력하지만 Joint Consensus 메커니즘은 Raft 알고리즘 구현에서 가장 복잡한 부분 중 하나이며 올바르게 구현하고 철저히 테스트해야 합니다.

• 쓰기에 대한 단일 장애점: 리더 장애에 대해 내결함성이 있지만, 리더가 영구적으로 다운되었고 새로운 리더를 선출할 수 없는 경우(예: 네트워크 분할 또는 너무 많은 장애로 인해), 시스템은 쓰기에서 진행할 수 없습니다.

결론: 복원력 있는 글로벌 시스템을 위한 분산 합의 마스터하기

Raft 알고리즘은 복잡한 문제를 단순화하는 사려 깊은 설계의 힘을 증명합니다. 이해 가능성에 대한 강조는 분산 합의를 민주화하여 더 넓은 범위의 개발자와 조직이 이전 접근 방식의 난해한 복잡성에 굴복하지 않고 고가용성 및 내결함성 시스템을 구축할 수 있도록 했습니다.

Kubernetes(etcd를 통해)로 컨테이너 클러스터를 오케스트레이션하는 것부터 CockroachDB와 같은 글로벌 데이터베이스에 대한 복원력 있는 데이터 저장소를 제공하는 것까지, Raft는 우리의 디지털 세계가 일관되고 운영되도록 보장하는 보이지 않는 핵심 역할을 합니다. Raft를 구현하는 것은 사소한 일이 아니지만, 그 명확한 사양과 풍부한 생태계는 다음 세대의 강력하고 확장 가능한 인프라를 구축하는 데 전념하는 사람들에게 보람 있는 노력입니다.

개발자 및 설계자를 위한 실행 가능한 통찰력:

• 이해를 우선시하십시오: 구현을 시도하기 전에 Raft의 각 규칙과 상태 전환을 철저히 이해하기 위해 시간을 투자하십시오. 원본 논문과 시각적 설명은 귀중한 리소스입니다.

• 기존 라이브러리 활용: 대부분의 애플리케이션의 경우, 요구 사항이 매우 특수하거나 학술 연구를 수행하는 경우가 아니라면 처음부터 구축하는 대신 잘 검증된 기존 Raft 구현(예: etcd, HashiCorp의 Raft 라이브러리)을 사용하는 것을 고려하십시오.

• 엄격한 테스트는 협상 불가: 장애 주입, 속성 기반 테스트 및 광범위한 장애 시나리오 시뮬레이션은 모든 분산 합의 시스템에 필수적입니다. 철저히 망가뜨리지 않고는 "작동한다"고 가정하지 마십시오.

• 글로벌 지연 시간을 고려하여 설계: 글로벌 배포 시에는 다른 지역 전반의 일관성과 성능을 최적화하기 위해 쿼럼 배치, 네트워크 토폴로지 및 클라이언트 읽기 전략을 신중하게 고려하십시오.

• 영구 및 내구성: 기본 저장소 계층이 강력한지 확인하고 fsync 또는 해당 작업을 충돌 시나리오에서 데이터 손실을 방지하기 위해 올바르게 사용하고 있는지 확인하십시오.

분산 시스템이 계속 발전함에 따라 Raft가 구현한 원칙(명확성, 견고성 및 내결함성)은 신뢰할 수 있는 소프트웨어 엔지니어링의 핵심으로 남을 것입니다. Raft를 마스터함으로써 귀하는 분산 컴퓨팅의 불가피한 혼란을 견딜 수 있는 복원력 있고 글로벌 확장 가능한 애플리케이션을 구축하기 위한 강력한 도구를 갖추게 됩니다.