Raft Consensus Algorithm 개요
Raft는 분산 시스템에서 합의 문제를 해결하기 위한 알고리즘임.
이는 Paxos와 같은 다른 합의 알고리즘들과 목적은 동일하지만, Raft는 가독성과 구현 용이성을 우선시하여 설계됨.
Raft는 리더 선출, 로그 복제, 안정성 보장을 포함한 세 가지 주요 목표에 초점을 맞추며, 분산 환경에서 상태 머신의 일관성을 유지하는 데 도움을 줌.
Raft는 특정한 조건 하에서 여러 노드들이 동일한 결정을 내릴 수 있도록 보장하며, 이는 특히 분산된 시스템에서 중요한 요구사항임.
분산 환경에서는 노드 간의 통신 지연, 네트워크 분할, 일부 노드의 장애와 같은 문제들이 발생할 수 있는데, Raft는 이를 극복하면서도 안정적인 상태 유지가 가능함.
1. 노드와 리더쉽
Raft는 클러스터 내의 노드를 세 가지 상태로 나눔.
1. 리더
클러스터에서 유일한 쓰기 권한을 가지며, 다른 노드들에게 명령을 전달하고 로그 복제를 책임짐.
2. 팔로워
리더의 지시를 따르며, 리더가 보내는 로그를 수신하여 자신의 로그에 저장함.
3. 후보자
리더가 없거나 리더를 새로 선출해야 할 때, 자신을 리더로 선출되기 위해 다른 노드들에게 투표를 요청함.
리더는 클러스터에서 단 하나만 존재하며, 리더가 없는 상황에서는 새로운 리더가 선출됨.
이 리더 선출 과정이 Raft의 합의 프로세스 중 핵심적인 역할을 함.
2. 리더 선출 과정
리더 선출은 아래 과정으로 이루어짐.
1. Election Timeout
각 노드는 랜덤한 시간 간격으로 리더의 메시지를 기다림.
만약 일정 시간 동안 리더로부터 메시지가 도착하지 않으면, 그 노드는 리더가 실패했다고 간주하고 스스로를 후보자로 변환함.
2. Vote Request
후보자가 되면 그 후보자는 다른 모든 노드에게 리더로 자신을 선출해 달라고 요청을 보냄.
3. 투표
각 노드는 일정한 조건을 충족하는 후보자에게 투표할 수 있음.
클러스터의 과반수 이상이 특정 후보자에게 투표하면 그 후보자가 새로운 리더로 선출됨.
4. Heartbeat
리더로 선출된 후, 리더는 주기적으로 하트비트 메시지를 팔로워에게 전송하여 자신이 여전히 살아있음을 알리고 리더 자격을 유지함.
3. 로그 복제
리더가 선출되면, 클라이언트의 모든 쓰기 요청은 리더에게 전달되고, 리더는 이를 클러스터의 다른 노드들에게 복제함.
1. LogEntry
리더는 클라이언트로부터 받은 명령을 자신의 로그에 엔트리로 추가함.
2. 복제
리더는 그 로그 엔트리를 다른 팔로워에게 전송함.
이 과정에서 노드들은 해당 로그가 자신의 로그에 추가되었는지 확인한 후 리더에게 응답함.
3. 커밋
리더는 해당 로그가 클러스터의 과반수에 복제되면 그 로그를 커밋함.
커밋된 로그는 적용이 확정되었고 시스템의 일관성이 유지됨을 의미함.
4. 적용
로그가 커밋되면 각 노드는 그 로그의 명령을 상태 머신에 적용함.
이는 시스템이 클라이언트의 요청을 실제로 수행했음을 나타냄.
4. 안정성 보장
Raft는 몇 가지 메커니즘을 통해 시스템의 안정성을 보장함.
1. 동시성 제어
하나의 리더만 존재하므로 동시성 문제가 발생하지 않음.
로그는 리더에 의해 제어되고, 로그가 과반수 노드에 복제되기 전까지는 커밋되지 않으므로, 로그의 일관성이 유지됨.
2. 리더 실패 복구
리더가 실패해도 빠르게 새로운 리더가 선출되며, 새로운 리더는 반드시 이전 리더가 커밋한 로그까지 동일한 상태를 가지고 있어야 함.
이렇게 함으로써 장애 복구 후에도 로그의 일관성을 보장할 수 있음.
3. 로그 일관성 유지
각 로그 엔트리는 특정한 Term에 속함.
리더는 자신의 Term이 다른 노드들보다 최신임을 보장하며, 이전 Term에서 커밋되지 않은 로그는 새로운 리더에 의해 덮어씌워질 수 있음.
5. 시간 개념과 Term
Raft는 Term이라는 개념을 통해 시스템의 시간 흐름을 추적함.
각각의 Term은 리더 선출을 포함한 중요한 시스템 이벤트를 나타내며, 각 Term은 고유한 번호를 가짐.
1. 임기 구분
각 Term은 새로운 리더 선출로 시작됨.
한 Term 동안에는 하나의 리더만 존재할 수 있음.
2. Term의 기능
Term은 리더와 팔로워 간의 로그 동기화 및 합의 여부를 판단하는 중요한 기준이 됨.
리더는 항상 자신이 속한 Term을 포함한 정보를 보내고, 팔로워들은 리더의 Term이 자신보다 오래되었는지 확인하여 그에 맞게 행동함.
6. 안정성과 가용성
Raft는 Paxos와 유사하게 안정성과 가용성을 중점으로 설계됨.
1. 안정성
어떠한 경우에도 두 개 이상의 리더가 동시에 존재할 수 없고, 커밋된 로그는 절대 삭제되거나 덮어쓰여지지 않도록 보장함.
2. 가용성
일부 노드가 실패하더라도 과반수의 노드만 정상 작동하면 새로운 리더를 선출하고 시스템이 계속 동작할 수 있음.
7. 장점화 한계
1. 장점
Raft는 Paxos보다 이해하기 쉽고 구현이 상대적으로 간단함.
리더 중심 아키텍처를 사용해 동시성 문제를 효과적으로 제어함.
로그 복제를 통해 시스템의 일관성을 강력하게 보장함.
리더 선출 과정을 명확하게 정의하여 장애 복구가 빠름.
2. 한계
리더에게 집중된 책임 때문에 리더 노드의 부하가 상대적으로 높음.
네트워크가 불안정할 때 리더 선출 과정에서 클러스터 전체가 일시적으로 작동하지 않을 수 있음.
Raft Consensus Algorithm 정리
Raft는 분산 시스템에서 상태 복제와 일관성 유지라는 중요한 문제를 직관적으로 해결하기 위해 고안된 합의 알고리즘임.
Paxos와 같은 다른 합의 알고리즘에 비해 명확한 리더 선출 메커니즘과 쉬운 구현을 제공하여 널리 사용됨.
Raft는 리더 선출, 로그 복제, 안정성 보장 메커니즘은 시스템이 장애를 겪더라도 일관성을 유지하며 운영될 수 있도록 보장함.
'Data Engineering > Zeppelin' 카테고리의 다른 글
[Zeppelin] 아파치 제플린의 인터프리터 (2) | 2024.09.17 |
---|---|
[Zeppelin] 아파치 제플린의 장단점 (2) | 2024.09.16 |
[Zeppelin] 쿠버네티스의 라벨 (0) | 2024.09.11 |
[Zeppelin] 쿠버네티스란 (1) | 2024.09.11 |
[Zeppelin] 도커 이미지 경량화 방법 (0) | 2024.09.10 |