KRaft
KRaft란?
- Kafka Raft의 약자
- 기존의 주키퍼를 사용하는 방식이 아닌 주키퍼 없이 카프카 자체에서 모든 것을 관리하는 방식
- 기존 방식보다 설정이 간단해졌으며, 성능 및 안정성이 개선됨
핵심 개념
(1) Controller
- 카프카 클러스터의 메타데이터 관리자
- 주키퍼를 제거하면서 카프카 내부에서 클러스터 메타데이터를 직접 관리하는 역할을 하는 노드
- 항상 Controller Quorum의 일부로 존재함
(2) Controller Quorum
- 컨트롤러 노드들의 그룹으로, KRaft 모드에서 클러스터 메타데이터의 일관성과 안정성을 보장함
- 컨트롤러 Quorum의 과반수 이상이 동작해야 클러스터가 정상적으로 작동함
- 컨트롤러 Quorum이 3개일 경우, 최소 2개 노드가 살아있어야 함
# 설정 예시
controller.quorum.voters=1@kafka1:9093,2@kafka2:9093,3@kafka3:9093
(3) Leader Controller
- Controller Quorum 내에서 선출된 단일 노드로, 메타데이터 변경 작업의 중심
- 모든 메타데이터를 관리 및 처리하며, 이를 팔로워 컨트롤러에 복제함
- 클라이언트(프로듀서, 컨슈머)나 브로커가 메타데이터를 요청할 때 리더 컨트롤러가 이를 제공함
- 클러스터 내 모든 브로커 모니터링
- 장애 발생 시, ISR(In-Sync Replica) 내에서 리더 파티션을 재선출함
- __consumer_offsets 토픽을 통해 컨슈머 그룹의 상태를 저장하고 관리함
- 장애가 발생하면, 새로운 리더 컨트롤러가 Raft 알고리즘에 따라 자동으로 선출됨
(4) Follower Controllers
- Controller Quorum 내에서 리더 컨트롤러가 아닌 모든 컨트롤러
- 리더 컨트롤러에서 발생한 모든 메타데이터 변경 사항을 지속적으로 복제함
- 리더 컨트롤러가 정상적으로 동작하는지 감시함
- 리더 컨트롤러에 장애가 발생한 경우, 새로운 리더를 선출하기 위한 투표에 참여함
- 리더 컨트롤러에 장애가 발생하면, 팔로워 컨트롤러 중 하나가 새 리더로 승격됨
- 장애가 난 팔로워는 Quorum에서 제외되며, 클러스터는 정상적으로 작동함
(5) Raft Consensus Algorithm
- 데이터의 일관성과 신뢰성을 보장하기 위해 사용되는 합의(Consensus) 알고리즘
- 합의 : 여러 노드가 동일한 데이터를 가지도록 만드는 과정
- KRaft 모드에서 Controller Quorum 간의 데이터 일관성을 유지하는 데 활용됨
- Raft 노드의 상태
- 리더 (Leader) : 클라이언트 요청 처리, 변경 사항을 팔로워에 복제
- 후보 (Candidate) : 리더가 없을 때, 새로운 리더가 되기 위해 투표 요청
- 팔로워 (Follower) : 리더의 명령을 따르고 데이터를 복제, 투표 참여
- 리더 선출 과정 (Leader Election)
- 리더 비활성 상태
- 클러스터 시작 시, 모든 노드는 팔로워 상태
- 리더가 일정 시간 동안 응답하지 않으면, 팔로워 중 하나가 후보로 전환
- 투표 요청
- 후보는 다른 노드들에게 자신을 리더로 선출해 달라고 요청
- 리더 선출
- 과반수 노드가 후보에게 투표하면 후보가 리더로 승격
- 리더는 주기적으로 Heartbeat를 보내 팔로워에게 자신이 살아있음을 알림
- 리더가 일정 시간 동안 Heartbeat를 보내지 않으면 팔로워 중 하나가 후보로 전환됨
(6) Broker와 Controller의 결합
- KRaft 모드에서 각 Kafka 노드가 Broker 역할과 Controller 역할을 동시에 수행할 수 있음
# 해당 노드가 브로커와 컨트롤러 역할을 동시에 수행
process.roles=broker,controller
