컨센서스

컨센서스 (Consensus)

Raft 프로토콜과 Consul에서의 구현에 대한 개념적 정보를 설명해 드릴게요. 분산 데이터센터 운영을 관리하는 핵심 합의 알고리즘인 Raft가 Consul에서 어떤 원리로 동작하는지 이해할 수 있어요.

출처: 문서

본문

이 페이지는 Raft 프로토콜과 Consul에서의 구현에 대한 개념적 정보를 제공해요. 기반 아키텍처에 대한 자세한 내용은 지속성 백엔드 아키텍처를 참고해 주세요.

소개

Raft는 Consul이 분산 데이터센터 운영을 관리하기 위해 구현하는 합의(consensus) 알고리즘이에요. Consul이 Raft를 구현하는 방법을 배우기 전에 Raft Consensus Algorithm에 대한 일반적인 이해가 있어야 해요. Raft 프로토콜이 어떻게 작동하는지에 대한 대화형 가이드는 The Secret Lives of Data를 참고해 주세요.

Consul에서 Raft 프로토콜은 다음 개념에 따라 작동해요:

로그 엔트리(log entries) 는 Raft 시스템에서 작업의 기본 단위예요. 로그는 엔트리의 순서 있는 시퀀스이며, 엔트리에는 노드 추가, 서비스 등록, 키-값 쌍 업데이트 같은 모든 클러스터 변경 사항이 포함돼요.
Raft 인덱스는 로그 엔트리가 만들어진 시점을 권위 있는 순서로 기록해요. 모든 구성원이 엔트리와 그 순서에 동의할 때 로그가 일관적이라고 간주해요.
피어 집합(peer set) 은 로그 복제에 참여하는 모든 구성원의 집합이에요. Consul에서 데이터센터의 서버 노드가 피어 집합의 구성원이에요.
쿼럼(quorum) 은 피어 집합 구성원의 과반수를 의미해요. 수학적으로, 크기가 N인 집합의 경우 쿼럼에는 최소 (N/2)+1명의 구성원이 필요해요. 예를 들어 피어 집합에 5명의 구성원이 있으면 쿼럼을 형성하려면 3개의 노드가 필요해요. 쿼럼의 노드를 사용할 수 없으면 새 로그를 커밋할 수 없기 때문에 Consul 클러스터가 사용 불가능(unavailable) 상태가 돼요.

노드 선거

팔로워(Follower)
후보(Candidate)
리더(Leader)

모든 노드는 팔로워로 시작해요. 팔로워 상태에서 노드는 다음을 수행할 수 있어요:

리더로부터 로그 엔트리 수락
선거에서 투표

일정 시간 동안 엔트리를 받지 못하면 노드는 스스로 후보 상태로 승격돼요. 후보 상태에서 노드는 피어 집합의 다른 구성원에게 투표를 요청해요. 후보가 쿼럼의 투표를 받으면 리더로 승격돼요.

리더는 권위 있는 Raft 로그를 기록하는 피어 집합의 구성원이에요. 그런 다음 로그를 피어 집합의 다른 구성원에게 복제해요. 리더는 새 로그 엔트리를 수락하고 다른 모든 팔로워에게 복제해야 해요. 오래된 읽기(stale read)가 허용되지 않으면 Consul은 모든 쿼리도 리더에서 수행해요.

로그 엔트리

클러스터에 리더가 있으면 새 로그 엔트리를 수락할 수 있어요. 클라이언트는 리더에게 새 로그 엔트리 추가를 요청할 수 있어요. 그러면 리더는 엔트리를 내구성 있는 저장소에 기록하고 쿼럼의 팔로워에게 복제하려고 시도해요.

엔트리가 쿼럼의 노드에 내구성 있게 저장되면 커밋(committed) 된 것으로 간주돼요. 엔트리가 커밋된 후에는 유한 상태 머신(finite state machine)에 적용(applied) 될 수 있어요. Consul은 로그가 커밋되고 적용될 때까지 쓰기를 차단해요. 이 구성은 HTTP API 쿼리에 일관성 모드를 활성화해요.

Consul은 MemDB를 사용하여 일관된 로그를 유지해요. MemDB를 사용하는 장점 중 하나는 snapshot에서 이전 상태를 캡처하는 동안에도 Consul이 새 트랜잭션을 계속 수락할 수 있어 가용성 문제를 방지한다는 점이에요. 클러스터 상태의 스냅샷은 로그를 압축하여 크기가 무한정 커지는 것과 다른 노드로 복제하는 데 필요한 리소스를 방지해요.

쿼럼

Raft는 쿼럼을 사용할 수 있는 지점까지 내결함성이 있어요. 예를 들어 3개 노드의 Raft 클러스터는 단일 노드 장애를 견딜 수 있고, 5개 노드 클러스터는 2개 노드 장애를 견딜 수 있어요.

쿼럼의 노드를 사용할 수 없으면 로그 엔트리를 처리하거나 피어 구성원에 대해 추론하는 것이 불가능해요. 일반적으로 이 상황에서는 리더를 다시 설정하기 위해 수동 개입이 필요해요.

다음 표는 다양한 클러스터 크기에 대한 쿼럼 크기와 장애 허용도를 보여줘요. 프로덕션 배포에는 서버 3개 또는 5개를 권장해요. 단일 서버 에이전트 데이터센터의 사용은 개발 시나리오로 제한해야 해요.

Servers	Quorum size	Fault tolerance
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3
8	5	3

자세한 내용은 잠재적인 클러스터 크기 옵션과 그 장애 허용도를 요약한 쿼럼 크기를 참고해 주세요.

Consul 운영에서의 Raft

Consul에서는 Consul 서버 노드만 피어 집합의 일부예요. 클라이언트 에이전트는 피어 집합의 일부가 아니므로, 서버 에이전트 그룹이 스케일이 클러스터의 Raft 성능에 영향을 주지 않으면서 수천 개의 클라이언트 노드를 지원할 수 있어요.

부트스트랩 모드

새 데이터센터를 시작하려면 단일 Consul 서버를 부트스트랩 모드에 배치해야 해요. 이 모드는 서버가 스스로 리더로 선출되도록 해줘요. 리더가 선출되면 다른 서버가 일관성을 유지하는 방식으로 피어 집합에 합류할 수 있어요. 첫 번째 서버 집합이 합류한 후에는 부트스트랩 모드를 비활성화할 수 있어요. 자세한 내용은 Consul 데이터센터 부트스트랩을 참고해 주세요.

카탈로그 트랜잭션

비서버 리더는 카탈로그 정보에 대한 요청 또는 카탈로그 업데이트를 리더에게 전달해요. 요청(request) 인 경우(읽기 전용) 리더는 Raft 로그의 현재 상태를 기반으로 결과를 생성해요. 업데이트(update) 인 경우(상태를 수정) 리더는 새 로그 엔트리를 생성하고 Raft를 사용하여 적용해요. 로그 엔트리가 커밋되고 적용된 후 트랜잭션이 완료돼요.

추가 정보

Raft 프로토콜에 대한 자세한 내용은 다음 외부 리소스를 참고해 주세요: