Raft 알고리즘의 다양한 상황들

사례 1: 리더 선출

상황: 클러스터에 있는 서버들이 처음 시작할 때, 리더가 없는 상태입니다.

초기 상태

1. 서버 시작:

   • 클러스터 내 모든 서버는 처음에 Follower 상태로 시작합니다.
   • 서버들은 리더의 하트비트를 기다리며 일정 시간 동안 기다립니다.

2. 선거 타임아웃 설정:

   • 각 서버는 무작위로 설정된 선거 타임아웃(election timeout)을 가집니다.
   • 이 타임아웃은 서버가 리더로부터 하트비트를 받지 못할 경우 새로운 리더 선출을 시작하기 위한 계기입니다.
   • 타임아웃은 클러스터 내의 모든 서버들에서 약간씩 다르게 설정되어, 충돌 가능성을 줄입니다.

리더 선출 과정

1. 리더 없음 감지:

   • 서버가 자신의 선거 타임아웃 동안 하트비트를 받지 못하면, 클러스터에 리더가 없다고 판단합니다.
   • 이는 네트워크 지연, 리더 장애, 또는 리더가 다운된 상태일 수 있습니다.

2. 후보(Candidate) 전환:

   • 타임아웃이 만료된 서버는 Candidate 상태로 전환됩니다.
   • 현재 임기(term)를 증가시키고, 자신에게 투표합니다.
   • 다른 서버에 RequestVote RPC를 전송하여 자신의 리더 선출을 요청합니다.

3. 투표 요청:

   • 후보는 클러스터 내 모든 서버에 투표를 요청하는 메시지를 보냅니다. 이 메시지에는 후보의 임기(term), 후보의 ID, 그리고 후보의 로그 상태가 포함됩니다.
   • 각 서버는 투표 요청을 수신하면 다음 조건을 확인합니다:
     • 후보의 임기가 자신의 임기보다 크거나 같은 경우.
     • 후보의 로그가 자신의 로그와 동일하거나 더 최신인 경우.
   • 위 조건을 만족하면 서버는 해당 후보에게 투표합니다.

4. 투표 수집:

   • 후보는 과반수 이상의 투표를 획득하면 리더로 선출됩니다.
   • 이 과정에서 후보는 자신이 과반수를 확보했는지 확인하기 위해 지속적으로 투표 응답을 모니터링합니다.

5. 리더 선출 성공:

   • 과반수 이상의 투표를 획득한 후보는 Leader로 전환됩니다.
   • 새 리더는 즉시 클러스터 내 모든 서버에 하트비트를 전송하여 자신의 리더 지위를 알립니다.

리더 선출 후

1. 하트비트 전송:

   • 리더는 정기적으로 AppendEntries RPC를 사용하여 팔로워들에게 하트비트를 전송합니다.
   • 하트비트는 팔로워의 타임아웃을 리셋하고, 리더의 지속적인 존재를 확인시킵니다.

2. 로그 동기화:

   • 리더는 클라이언트로부터의 요청을 수신하고, 이를 로그에 기록합니다.
   • 기록된 로그 항목은 클러스터의 모든 팔로워에게 전송되어 동기화됩니다.

3. 클러스터 안정화:

   • 리더 선출이 완료되면, 클러스터는 정상 운영 상태로 돌아가고, 클라이언트 요청을 처리할 준비가 됩니다.

사례 2: 로그 복제

상황: 리더가 클라이언트로부터 새로운 로그 항목을 수신했습니다.

초기 상태

1. 리더 수신:

   • 클러스터의 리더는 클라이언트로부터 새로운 로그 항목을 수신합니다.
   • 이 로그 항목은 클러스터 내 모든 서버에 복제되어야 합니다.

2. 로그 추가:

   • 리더는 수신한 로그 항목을 자신의 로그에 추가합니다. 이때, 로그 항목은 아직 커밋되지 않은 상태입니다.

로그 복제 과정

1. AppendEntries RPC 전송:

   • 리더는 AppendEntries RPC를 통해 새로운 로그 항목을 모든 팔로워 서버에게 전송합니다.
   • 이 요청에는 다음 정보가 포함됩니다:
     • 리더의 현재 임기(term)
     • 로그 항목의 인덱스 및 데이터
     • 이전 로그 항목의 인덱스 및 임기(팔로워가 로그를 일치시킬 수 있도록)

2. 팔로워의 로그 업데이트:

   • 각 팔로워는 AppendEntries RPC를 수신하면 다음을 수행합니다:
     • 이전 로그 항목의 인덱스와 임기를 비교하여 로그의 일관성을 확인합니다.
     • 로그가 일치하는 경우, 새로운 로그 항목을 자신의 로그에 추가합니다.
     • 로그가 불일치하는 경우, 현재 요청을 거부하고 리더에게 불일치 사실을 알립니다.

3. 팔로워의 응답:

   • 팔로워는 로그 항목을 추가한 후 리더에게 성공적으로 로그가 추가되었음을 응답합니다.
   • 만약 로그가 일치하지 않는다면, 팔로워는 실패 응답을 보냅니다.

4. 리더의 로그 커밋:

   • 리더는 과반수 이상의 팔로워로부터 성공적인 응답을 받으면 해당 로그 항목을 커밋합니다.
   • 리더는 커밋된 로그 항목을 클러스터 내 모든 서버에 알립니다.

5. 상태 머신 적용:

   • 커밋된 로그 항목은 각 서버의 상태 머신에 적용됩니다. 이는 로그 항목이 시스템의 일관된 상태로 반영됨을 의미합니다.

6. 클라이언트 응답:

   • 로그 항목이 성공적으로 커밋되면, 리더는 클라이언트에게 요청이 완료되었음을 알리는 응답을 전송합니다.

로그 불일치 처리

1. 로그 불일치 감지:

   • 팔로워가 AppendEntries RPC를 수신할 때, 이전 로그 항목의 인덱스와 임기를 확인하여 불일치를 감지합니다.
   • 불일치가 발견되면, 팔로워는 현재 요청을 거부하고 리더에게 실패 응답을 보냅니다.

2. 리더의 로그 재전송:

   • 리더는 팔로워로부터 받은 실패 응답을 분석하여 불일치가 발생한 위치를 파악합니다.
   • 리더는 일치하는 로그 항목의 인덱스를 찾고, 그 이후의 로그를 팔로워에게 다시 전송합니다.

3. 로그 동기화 완료:

   • 로그가 일치하게 되면 팔로워는 로그 항목을 수신하여 자신의 로그를 업데이트합니다.

사례 3: 네트워크 파티션

상황: 네트워크가 두 개의 파티션으로 분리되어 일부 노드가 서로 통신할 수 없습니다.

초기 상태

1. 클러스터 상태:

   • 클러스터는 여러 서버로 구성되어 있으며, 정상적으로 운영 중입니다.
   • 모든 서버는 하나의 리더와 여러 팔로워로 구성되어 있습니다.

2. 네트워크 파티션 발생:

   • 클러스터가 두 개의 파티션으로 분리됩니다. 이를 A 파티션과 B 파티션으로 부르겠습니다.
   • 리더는 A 파티션에 위치해 있으며, 일부 팔로워는 B 파티션에 위치해 있습니다.

네트워크 파티션 과정

1. 리더의 하트비트 손실:

   • A 파티션의 리더는 B 파티션의 팔로워에게 하트비트를 전송할 수 없습니다.
   • B 파티션의 팔로워들은 일정 시간 동안 하트비트를 받지 못하면 리더가 실패했다고 판단합니다.

2. B 파티션의 리더 선출 시도:

   • B 파티션 내의 팔로워들은 하트비트를 받지 못해 타임아웃이 만료되면 Candidate 상태로 전환됩니다.
   • 새로운 리더 선출을 위해 투표를 시작합니다.
   • B 파티션 내의 노드가 과반수를 확보하지 못하면 리더 선출은 실패로 끝납니다.

3. A 파티션의 리더 유지:

   • A 파티션의 리더는 자신의 파티션 내에서 하트비트를 지속적으로 전송하여 리더 지위를 유지합니다.
   • A 파티션 내의 팔로워들은 리더가 여전히 유효하다고 인식합니다.

네트워크 복구 후 과정

1. 네트워크 복구:

   • 일정 시간이 지난 후 네트워크 파티션이 해소되어 A 파티션과 B 파티션 간의 통신이 재개됩니다.

2. 리더 선출 확인:

   • B 파티션의 노드들은 A 파티션의 리더로부터 하트비트를 수신하면 자신의 리더를 팔로워로 변경합니다.
   • 임기가 높은 리더가 있다면, 기존의 리더는 팔로워로 돌아갑니다.

3. 로그 일관성 확인 및 동기화:

   • 새로운 리더는 두 파티션 사이의 로그 상태를 확인하고, 필요한 경우 로그를 동기화합니다.
   • 리더는 AppendEntries RPC를 사용하여 팔로워의 로그를 최신 상태로 업데이트합니다.

4. 시스템 정상화:

   • 모든 노드의 로그가 일관되게 유지되면 시스템은 정상 운영 상태로 돌아갑니다.

사례 4: 리더 장애 복구

상황: 현재 리더가 장애로 인해 작동을 멈추었습니다.

초기 상태

1. 리더 장애 발생:

   • 현재 리더가 하드웨어 오류, 네트워크 장애, 소프트웨어 버그 등으로 인해 작동을 멈춥니다.
   • 리더는 더 이상 하트비트를 전송하지 못합니다.

2. 팔로워의 하트비트 손실 감지:

   • 팔로워들은 리더로부터 일정 시간 동안 하트비트를 받지 못합니다.
   • 각 팔로워는 하트비트를 받지 못한 시간을 측정하며, 선거 타임아웃이 만료되면 리더가 장애 상태임을 판단합니다.

리더 장애 복구 과정

1. 후보(Candidate) 전환:

   • 선거 타임아웃이 만료된 팔로워는 Candidate 상태로 전환됩니다.
   • 자신의 임기(term)를 증가시키고, 자신에게 투표합니다.

2. 투표 요청:

   • 후보는 클러스터 내의 다른 서버들에게 RequestVote RPC를 전송하여 투표를 요청합니다.
   • 투표 요청 메시지에는 후보의 임기, 후보의 ID, 그리고 후보의 로그 상태가 포함됩니다.

3. 투표 수집:

   • 각 서버는 투표 요청을 받으면 다음을 수행합니다:
     • 후보의 임기가 자신의 임기보다 크거나 같은 경우, 그리고 후보의 로그가 자신의 로그와 동일하거나 더 최신인 경우에만 투표합니다.
     • 서버는 각 임기마다 한 번만 투표할 수 있습니다.

4. 새로운 리더 선출:

   • 후보가 과반수 이상의 투표를 확보하면 Leader로 선출됩니다.
   • 새로운 리더는 즉시 하트비트를 클러스터 내의 모든 서버에 전송하여 자신의 리더 지위를 알립니다.

리더 복구 후 과정

1. 하트비트 전송:

   • 새 리더는 AppendEntries RPC를 통해 지속적으로 하트비트를 전송하여 리더 지위를 유지합니다.
   • 이는 팔로워의 타임아웃을 리셋하고, 새로운 리더가 선출되었음을 알립니다.

2. 로그 일관성 확인:

   • 새로운 리더는 클러스터 내의 모든 서버와 로그 상태를 동기화합니다.
   • 리더는 팔로워의 로그와 자신의 로그가 일치하도록 AppendEntries RPC를 사용하여 불일치한 로그를 수정합니다.

3. 클라이언트 요청 처리 재개:

   • 로그 일관성이 확보되면, 리더는 클라이언트로부터의 요청을 처리하기 시작합니다.
   • 리더는 새로운 요청을 로그에 기록하고, 이를 모든 팔로워에게 복제합니다.

사례 5: 클러스터 확장

상황: 새로운 서버를 클러스터에 추가하여 시스템을 확장합니다.

초기 상태

1. 현재 클러스터 구성:

   • 클러스터는 이미 하나의 리더와 여러 팔로워로 구성되어 있으며, 정상적으로 운영되고 있습니다.
   • 새로운 서버를 추가하여 클러스터의 확장을 계획하고 있습니다.

2. 새로운 서버 초기화:

   • 새 서버는 네트워크에 연결되고, 초기 Follower 상태로 시작합니다.
   • 새로운 서버는 아직 기존 클러스터의 로그 및 상태와 동기화되지 않은 상태입니다.

클러스터 확장 과정

1. 클러스터 구성 변경 제안:

   • 리더는 새로운 서버를 포함하는 클러스터 구성 변경을 제안합니다.
   • 클러스터 구성 변경은 기존 노드의 동의를 필요로 하며, 로그에 기록됩니다.

2. 새로운 서버에 로그 동기화:

   • 리더는 AppendEntries RPC를 통해 기존 로그 항목을 새로운 서버에 전송하여 동기화합니다.
   • 새로운 서버는 수신한 로그를 자신의 로그에 추가하고, 리더에게 동기화 상태를 응답합니다.

3. 로그 일치 검증:

   • 리더는 새로운 서버의 로그가 클러스터와 일치할 때까지 로그 항목을 전송합니다.
   • 모든 로그가 동기화되면, 새로운 서버는 클러스터의 최신 상태로 전환됩니다.

4. 구성 변경 커밋:

   • 로그 동기화가 완료되면 리더는 새로운 서버가 포함된 클러스터 구성을 커밋합니다.
   • 이 변경 사항은 로그에 기록되고, 상태 머신에 적용됩니다.

5. 새로운 서버의 리더 선출 참여:

   • 새로운 서버는 정상적인 클러스터 구성원이 되며, 향후 리더 선출 과정에 참여할 수 있게 됩니다.
   • 리더는 주기적으로 새로운 서버에 하트비트를 전송하여 지속적인 동기화를 유지합니다.

클러스터 확장 후

1. 시스템 안정성 확인:

   • 모든 서버가 새로운 구성에 동의했으며, 로그가 동기화되어 일관성을 유지합니다.
   • 새로운 서버는 클러스터의 나머지 서버들과 함께 클라이언트 요청을 처리할 준비가 됩니다.

2. 확장된 시스템 성능 모니터링:

   • 시스템 확장에 따른 성능 개선과 안정성을 모니터링하여 필요에 따라 조정을 수행합니다.

사례 6: 리더의 로그 손실 복구

상황: 리더가 비정상적으로 종료되면서 일부 로그 항목을 손실했습니다.

초기 상태

1. 로그 손실 발생:

   • 리더가 예기치 않은 장애로 인해 비정상적으로 종료되었습니다.
   • 이로 인해 최근 커밋되지 않은 로그 항목이 손실되었습니다.
   • 리더가 복구되었지만, 이 로그 항목들은 리더의 로컬 저장소에 존재하지 않습니다.

2. 클러스터의 잠재적 불일치:

   • 리더의 로그 손실로 인해 클러스터의 상태 일관성이 잠재적으로 위협받고 있습니다.

로그 손실 복구 과정

1. 리더 복구 및 재시작:

   • 리더가 장애로부터 복구되어 다시 실행됩니다.
   • 리더는 로그의 현재 상태를 확인하고, 자신이 리더로서의 역할을 계속할 수 있는지 점검합니다.

2. 로그 일관성 점검:

   • 리더는 현재 클러스터의 로그 상태를 점검하기 위해 팔로워에게 AppendEntries RPC를 전송합니다.
   • 리더는 각 팔로워로부터 로그 일치 여부에 대한 응답을 수신합니다.

3. 로그 불일치 감지:

   • 팔로워는 리더로부터 받은 요청에 대해 이전 로그 항목의 인덱스와 임기를 확인합니다.
   • 팔로워의 로그가 리더의 로그보다 최신인 경우, 리더는 불일치를 감지하고 조정이 필요함을 인식합니다.

4. 리더 재선출:

   • 로그 불일치가 큰 경우, 현재 리더는 팔로워의 상태를 동기화하기 어렵게 될 수 있습니다.
   • 이 경우, 새로운 리더 선출을 통해 로그 일관성을 유지할 수 있습니다.
   • 새로운 선거가 시작되어 과반수를 확보한 노드가 새로운 리더로 선출됩니다.

5. 로그 동기화 및 복구:

   • 새로운 리더는 가장 최신 로그를 가지고 있는 팔로워의 로그를 기준으로 다른 노드들과 로그를 동기화합니다.
   • AppendEntries RPC를 사용하여 손실된 로그 항목을 팔로워로부터 복구합니다.

6. 로그 커밋 및 일관성 회복:

   • 로그 동기화가 완료되면, 커밋되지 않은 로그 항목이 시스템의 상태 머신에 적용됩니다.
   • 로그가 커밋된 후, 클러스터 내 모든 노드의 상태가 일관성을 유지하게 됩니다.

로그 손실 복구 후

1. 시스템 정상화:

   • 로그가 일관된 상태로 복구되면, 시스템은 정상 운영 상태로 돌아갑니다.
   • 클라이언트 요청이 처리되며, 시스템의 가용성과 일관성이 보장됩니다.

2. 성능 모니터링 및 안정성 검증:

   • 로그 손실 복구 후 클러스터의 성능과 안정성을 모니터링하여 필요 시 추가적인 조치를 취합니다.

사례 7: 리더의 비효율적인 동작 복구

상황: 리더가 느린 네트워크 연결로 인해 비효율적으로 동작하고 있습니다.

초기 상태

1. 리더의 네트워크 지연:

   • 현재 리더는 느린 네트워크 연결로 인해 하트비트와 로그 복제를 팔로워들에게 제때 전송하지 못하고 있습니다.
   • 이는 클라이언트 요청 처리의 지연과 클러스터 전체의 성능 저하를 유발합니다.

2. 팔로워의 반응 지연:

   • 팔로워들은 리더로부터 하트비트를 늦게 받으며, 로그 동기화가 지연되고 있습니다.
   • 클러스터의 응답성이 저하되고, 일관성이 위협받고 있습니다.

비효율적인 동작 복구 과정

1. 리더 성능 모니터링:

   • 팔로워들은 리더로부터 수신하는 하트비트와 로그 복제의 지연을 모니터링합니다.
   • 팔로워들은 하트비트를 지정된 시간 내에 충분히 받지 못하면 리더의 비효율적인 동작을 감지합니다.

2. 팔로워의 타임아웃 설정:

   • 팔로워들은 하트비트를 기다리는 동안 타임아웃을 설정합니다.
   • 타임아웃이 만료되면, 리더가 더 이상 효율적으로 동작하지 않는다고 판단합니다.

3. 후보(Candidate) 전환:

   • 선거 타임아웃이 만료된 팔로워는 Candidate 상태로 전환되고, 새로운 리더 선출을 위한 선거를 시작합니다.
   • 팔로워들은 새로운 리더를 선출하기 위해 투표를 요청합니다.

4. 투표 요청 및 리더 선출:

   • 각 팔로워는 현재 리더의 성능을 고려하여 새로운 후보에게 투표를 제공합니다.
   • 과반수 이상의 투표를 받은 후보가 새로운 리더로 선출됩니다.
   • 새 리더는 클러스터 내 모든 서버에게 하트비트를 전송하여 리더 지위를 알립니다.

5. 로그 동기화 및 최적화:

   • 새로운 리더는 팔로워들과 로그 상태를 동기화하여 일관성을 확보합니다.
   • 하트비트와 로그 복제를 최적화하여 클러스터의 성능을 개선합니다.

비효율적인 동작 복구 후

1. 시스템 성능 향상:

   • 새로운 리더는 더 빠르고 효율적인 네트워크 연결을 통해 클러스터의 성능을 향상시킵니다.
   • 클라이언트 요청이 빠르게 처리되고, 시스템의 안정성이 개선됩니다.

2. 지속적인 성능 모니터링:

   • 클러스터는 새로운 리더의 성능을 지속적으로 모니터링하여 잠재적인 비효율성을 조기에 감지합니다.
   • 필요 시, 추가적인 조치를 통해 클러스터 성능을 유지합니다.

사례 8: 클러스터 축소

상황: 기존 서버를 클러스터에서 제거하여 시스템을 축소해야 합니다.

초기 상태

1. 현재 클러스터 구성:

   • 클러스터는 여러 개의 서버로 구성되어 있으며, 정상적으로 운영되고 있습니다.
   • 시스템 관리자는 특정 서버를 클러스터에서 제거하여 자원을 최적화하려고 합니다.

2. 자원 최적화 필요:

   • 클러스터 내 일부 서버가 과다하게 자원을 사용하고 있거나, 불필요한 운영 비용이 발생하고 있습니다.
   • 클러스터 크기를 줄임으로써 운영 비용을 절감하고, 관리 복잡성을 줄이려는 목표가 있습니다.

클러스터 축소 과정

1. 클러스터 구성 변경 계획:

   • 관리자는 클러스터 구성 변경 계획을 수립합니다. 이는 클러스터에서 제거할 서버를 식별하는 과정을 포함합니다.

2. 구성 변경 제안:

   • 리더는 클러스터 내 다른 서버들에게 특정 서버를 제거하는 제안을 합니다.
   • 구성 변경은 로그에 기록되어야 하며, 클러스터의 과반수의 동의를 필요로 합니다.

3. 제거 서버의 로그 동기화:

   • 제거될 서버는 클러스터에서 제거되기 전까지의 모든 로그 항목을 커밋하도록 동기화됩니다.
   • 리더는 해당 서버와의 로그 일관성을 확인하고, 필요한 경우 로그 항목을 전송하여 동기화합니다.

4. 구성 변경 커밋:

   • 리더는 과반수 이상의 동의를 얻으면, 로그에 구성 변경을 커밋하고 상태 머신에 적용합니다.
   • 제거된 서버는 공식적으로 클러스터 구성에서 제외됩니다.

5. 서버 연결 종료:

   • 제거된 서버는 클러스터 내 다른 서버와의 연결을 종료하고, 클러스터의 관리에서 완전히 제외됩니다.
   • 나머지 서버들은 새로운 클러스터 구성에 따라 동작을 계속합니다.

클러스터 축소 후

1. 시스템 정상화:

   • 클러스터는 축소된 상태에서 정상적으로 운영됩니다.
   • 클라이언트 요청은 나머지 서버에 의해 처리되며, 시스템의 일관성과 가용성이 유지됩니다.

2. 자원 사용 최적화:

   • 불필요한 서버 제거로 자원 사용이 최적화되고, 운영 비용이 절감됩니다.
   • 성능과 안정성을 지속적으로 모니터링하여 필요에 따라 추가적인 조치를 취합니다.

사례 9: 로그 압축을 통한 시스템 최적화

상황: 장기적인 운영으로 인해 로그 크기가 매우 커져서 시스템의 성능과 저장 공간에 영향을 미치고 있습니다.

초기 상태

1. 로그의 증가:

   • 클러스터는 오랜 기간 운영되어 왔고, 로그 항목이 지속적으로 증가해왔습니다.
   • 로그 크기가 커지면서 디스크 사용량이 증가하고, 로그의 동기화 및 복구가 비효율적이 될 수 있습니다.

2. 저장 공간 제한:

   • 저장 공간이 제한적이거나 비용이 큰 경우, 로그 크기의 증가가 자원 관리에 문제를 일으킬 수 있습니다.

로그 압축 과정

1. 스냅샷 생성:

   • 리더는 일정 시점에서 전체 상태 머신의 상태를 스냅샷으로 저장합니다.
   • 스냅샷은 현재까지의 로그 항목을 적용한 상태를 나타내며, 로그의 시작점부터 스냅샷 시점까지의 상태를 포함합니다.

2. 스냅샷 전파:

   • 리더는 팔로워에게도 스냅샷을 전파하여 각 서버가 동일한 상태를 유지하도록 합니다.
   • 스냅샷은 InstallSnapshot RPC를 통해 전송되며, 팔로워는 이를 적용하여 자신의 상태를 갱신합니다.

3. 로그 항목 삭제:

   • 스냅샷이 성공적으로 생성되고 전파된 후, 리더와 팔로워는 스냅샷 이전의 로그 항목을 삭제하여 디스크 사용량을 줄입니다.
   • 이를 통해 로그의 크기를 줄이고, 저장 공간을 효율적으로 사용하게 됩니다.

4. 새로운 로그 항목 추가:

   • 스냅샷 이후 발생하는 새로운 로그 항목은 계속해서 기록됩니다.
   • 로그 압축은 이전 로그의 복잡성을 줄이고, 새로운 로그가 더 효율적으로 관리될 수 있도록 돕습니다.

로그 압축 후

1. 시스템 성능 최적화:

   • 로그 압축을 통해 디스크 사용량이 줄어들고, 로그 관리의 효율성이 향상됩니다.
   • 스냅샷을 통해 빠르게 시스템 상태를 복구할 수 있어, 장애 복구 시 성능이 개선됩니다.

2. 자원 사용 최적화:

   • 저장 공간의 최적화로 인해 비용 절감과 자원 관리의 효율성이 높아집니다.
   • 시스템의 확장성을 고려하여 저장 공간과 성능을 최적화합니다.