KRaft 컨트롤러 쿼럼 사이징 — controller.quorum.voters와 홀수 노드
Kafka Connect SMT 공식 문서 및 KRaft 컨트롤러 쿼럼 사이징 가이드 종합 (웹 리서치, 2026) — Confluent 공식 문서(kafka-connectors/transforms) + Apache Kafka 공식 문서(operations/kraft) Apache Kafka 공식 문서 operations/kraft
이 모듈을 다 읽으면
- controller.quorum.voters의 설정 문법을 설명할 수 있다
- 컨트롤러 노드 수가 왜 홀수여야 하는지, 3개와 5개의 트레이드오프가 무엇인지 판단할 수 있다
kafka-learn-34에서 다룬 KRaft 컨트롤러 쿼럼의 개념(Raft 합의, __cluster_metadata)을 전제로, 실제로 이를 몇 대의 노드로, 어떻게 설정하는지의 실무적 사이징을 정리한다.
controller.quorum.voters 설정 문법
controller.quorum.voters=1@node1:9093,2@node2:9093,3@node3:9093처럼 id@host:port 형식으로, 쿼럼에 참여하는 모든 컨트롤러 노드를 콤마로 나열한다. 각 노드는 이 설정을 보고 서로가 누구인지, 쿼럼이 몇 대로 구성되는지 알게 된다. 작은 클러스터에서는 브로커 역할과 컨트롤러 역할을 한 프로세스에 결합할 수도 있지만(개발/테스트 환경), 프로덕션에서는 컨트롤러 전용 노드로 분리해 브로커 부하가 컨트롤러 합의 과정에 영향을 안 주게 하는 것이 일반적이다.
핵심 포인트
- controller.quorum.voters=id@host:port 형식으로 쿼럼 참여 노드 전체를 나열한다
- 프로덕션에서는 컨트롤러를 브로커와 분리한 전용 노드로 두는 것이 일반적
왜 홀수인가 — 과반수(majority) 합의의 산수
Raft 합의는 '과반수(majority)'가 동의해야 결정이 확정되는 방식이다. 노드 수가 짝수면(예: 4대) 딱 절반씩(2 vs 2) 갈리는 상황이 만들어질 수 있어 과반수를 명확히 가릴 수 없는 동점 상황의 위험이 생긴다. 홀수(3, 5, 7...)로 구성하면 항상 명확한 과반수가 존재한다. 실무에서는 보통 3대 또는 5대 중에서 고르는데, 3대는 1대까지 장애를 견디고(2대만 살아있어도 과반수 유지), 5대는 2대까지 장애를 견딘다(3대만 살아있어도 과반수 유지) — 더 많은 장애 허용치를 얻는 대신 노드 수만큼 자원(각 컨트롤러 노드의 메모리·디스크)과 운영 복잡도가 늘어나는 트레이드오프다.
핵심 포인트
- Raft는 과반수 동의로 결정 — 노드 수가 짝수면 동점(예: 2대2) 상황이 가능해 홀수가 표준
- 3대: 1대 장애까지 허용 / 5대: 2대 장애까지 허용 — 장애 허용치가 늘수록 자원·운영 복잡도도 늘어나는 트레이드오프