Feb 14, 2026

마지막 업데이트 Apr 18, 2026

Kafka Leader Imbalance: broker를 늘리기 전에 leader 수부터 세야 한다

Kafka broker 몇 대만 계속 뜨거우면, 팀은 종종 “트래픽이 원래 늘었다”거나 “브로커를 더 넣자”고 결론부터 내립니다. 실제로 프로덕션 Kafka 클러스터에서 broker 3대 중 1대의 CPU만 90%를 찍고 있었는데, 확인해 보니 그 broker가 전체 partition의 leader 60%를 혼자 들고 있었습니다. 전날 밤 다른 broker 2대가 롤링 리스타트된 뒤 leader가 돌아오지 않은 것이었습니다. kafka-leader-election.sh로 preferred leader election을 수동 실행하니 5분 만에 CPU가 45%로 떨어졌습니다. 그런데 실제 incident에서는 더 단순한 질문이 먼저일 때가 많습니다. 그 broker들이 다른 broker보다 partition leader를 더 많이 들고 있지는 않은가?

짧게 말하면 먼저 workload skew와 leadership skew를 나눠야 합니다. restart나 recovery 뒤에 broker가 뜨거워졌다면, leadership이 preferred replica 쪽으로 정상화되지 않았을 가능성이 큽니다.

이 글이 맞는 상황

아래 중 하나면 여기서 시작하면 됩니다.

restart, failure, maintenance 뒤에 몇몇 broker만 계속 뜨겁다
재기동된 broker는 시원한데 다른 broker만 과부하처럼 보인다
producer latency나 retry가 같은 broker들에 집중된다
이게 traffic-shape 문제인지 leader-placement 문제인지 모르겠다
preferred replica가 균형을 잡아줄 줄 알았는데 cluster가 계속 uneven하다

처음 10분에 볼 것

topic describe와 broker config 문맥부터 잡으세요.

kafka-topics.sh --bootstrap-server <broker:9092> --describe --topic <topic>

그리고 hot broker의 leader 수와 최근 restart 이력을 같이 비교하세요.

이 단계에서 답해야 할 질문은 네 개입니다.

hotspot이 restart, failure, maintenance 뒤에 시작됐는가
가장 뜨거운 broker가 실제로 leader를 더 많이 들고 있는가
traffic 자체가 skew된 건가, leadership이 skew된 건가
이 cluster에서는 automatic leader rebalancing이 기대되는가, 실제로 켜져 있는가

workload skew와 leadership skew를 먼저 분리해야 합니다

이 분리만 해도 엉뚱한 튜닝을 많이 막을 수 있습니다.

보이는 현상	보통 의미	다음 확인 포인트
broker event 전부터 특정 topic family만 뜨거웠다	workload skew	partitioning, key distribution, traffic shape 확인
restart나 failure 뒤 broker가 uneven해졌다	leadership skew	leader placement와 recovery 동작 확인
hot broker에서 producer latency나 retry도 같이 오른다	leader 집중을 client가 따라간다	producer 튜닝보다 leaders 먼저 확인
재기동된 broker는 시원하고 다른 broker만 뜨겁다	leader가 돌아오지 않았다	preferred replica와 rebalance 설정 확인

어느 갈래인지 모르고 있으면 client tuning이나 capacity 결정이 전부 추측이 됩니다.

restart 후 broker는 follower로 돌아옵니다

Kafka operations 문서는 broker가 restart하면 그 broker의 partition들이 처음에는 follower로 복귀한다고 설명합니다.

즉 아래가 가능합니다.

broker는 health 상태로 돌아왔다
하지만 client-facing leader load는 바로 회복되지 않는다
다른 broker가 계속 reads/writes를 leader 입장에서 처리한다

그래서 “broker가 돌아왔다”와 “leadership이 균형을 회복했다”는 같은 말이 아닙니다.

preferred replica가 cluster가 생각하는 정상 상태입니다

Kafka 문서는 partition replica 목록의 첫 번째 replica를 preferred replica로 설명합니다. 그리고 cluster는 leader load를 더 고르게 만들기 위해 leadership을 preferred replica 쪽으로 되돌리려 합니다.

그래서 hot-broker incident는 보통 두 단계로 보입니다.

cluster는 일단 traffic을 다시 받기 시작했다
하지만 leadership은 preferred shape로 돌아가지 않았다
일부 broker만 계속 뜨겁고 다른 broker는 시원하다

`auto.leader.rebalance.enable`가 핵심 background 제어입니다

Kafka broker config에는 auto.leader.rebalance.enable가 있고 기본값은 true입니다.

이 값이 켜져 있으면 controller가 leadership 분포를 주기적으로 점검합니다. 여기에 연결된 broker config 두 개가 더 있습니다.

leader.imbalance.check.interval.seconds
leader.imbalance.per.broker.percentage

이 둘은 결국 아래를 뜻합니다.

얼마나 자주 imbalance를 검사하는가
어느 정도까지는 편차를 허용하는가

운영자가 “클러스터가 알아서 leader를 되돌리겠지”라고 기대한다면, 먼저 이 값부터 확인해야 합니다.

broker heat는 CPU보다 leader 수가 더 잘 설명할 때가 많습니다

leader를 더 많이 가진 broker는 보통 더 많은 client-facing work를 처리합니다.

producer request는 leader로 간다
consumer fetch도 보통 leader를 본다
request handling, disk work, network load가 먼저 leader 쪽에 몰린다

즉 hot broker와 leader concentration은 같이 움직이는 경우가 많습니다. 같은 node가 뜨겁고 leader도 많다면, leadership skew는 더 이상 막연한 가설이 아닙니다.

producer 증상도 leader imbalance를 따라갑니다

leader imbalance는 broker 운영 문제로만 끝나지 않습니다. application 증상으로 위로 새어 나오는 경우가 많습니다.

hot broker에서 producer request latency가 올라간다
같은 partition이나 broker 쪽 retry가 늘어난다
가장 바쁜 leader를 가진 topic에서 pressure가 더 잘 보인다

그래서 Kafka Producer Retries가 자연스럽게 다음 글이 됩니다.

planned maintenance에서는 controlled shutdown도 중요합니다

Kafka operations 문서는 replication 조건이 맞으면 controlled shutdown으로 broker가 내려가기 전에 leader를 다른 곳으로 옮길 수 있다고 설명합니다.

즉 planned maintenance와 crash는 cluster 모양이 다르게 남습니다.

controlled shutdown은 급격한 leader skew를 줄이는 편이다
crash나 강제 종료는 더 거친 leader 분포를 남기기 쉽다

planned work 뒤 hotspot이 시작됐다면, shutdown 과정이 실제로 부드러웠는지도 다시 봐야 합니다.

먼저 확인할 broker config 블록

auto.leader.rebalance.enable=true
leader.imbalance.check.interval.seconds=300
leader.imbalance.per.broker.percentage=10

이 값들이 정답은 아니지만, cluster가 leader drift를 어떻게 다룰지 읽는 기본 틀입니다.

흔한 원인

1. restart한 broker가 follower로 돌아온 뒤 그대로 남음

cluster는 복구됐지만 leader load는 다시 균형으로 안 갔습니다.

2. preferred leader recovery가 기대한 대로 동작하지 않음

운영자는 자동 균형을 기대했지만 leader shape는 skew된 채 남았습니다.

3. 실제 workload skew를 leadership skew로 오해함

traffic pattern 자체가 이미 uneven할 수 있습니다.

4. hot leader가 producer 증상까지 키움

latency와 retry가 leader가 몰린 broker에서 더 먼저 커집니다.

5. maintenance가 생각만큼 graceful하지 않았음

restart나 shutdown 과정의 leader 이동이 cluster를 uneven한 상태로 남겼습니다.

흔한 잘못된 시작

leader 수도 안 세고 broker부터 추가하기
어떤 broker가 leader를 들고 있는지 안 보고 producer 튜닝하기
“broker restart 성공”을 “leader balance 회복”과 같은 말로 보기
consumer lag만 보고 hot broker 패턴을 설명하려 하기
rebalance config도 안 보고 preferred replica healing을 기대하기

실전 점검 순서

1. broker heat와 leader 수를 비교합니다

가장 뜨거운 broker가 leader도 많다면 조사 방향이 금방 날카로워집니다.

2. restart, failure, maintenance 이력을 확인합니다

leadership incident에서는 timing이 정말 중요합니다.

3. preferred replica 기대값과 auto rebalance 설정을 확인합니다

cluster가 스스로 무엇을 해 줘야 하는지 알아야 합니다.

4. workload shape와 비교합니다

여기서 true traffic skew와 recovery skew를 가릅니다.

5. 답이 cluster recovery인지 workload design인지 결정합니다

잘못된 문제를 client나 broker 수로 풀면 안 됩니다.

체크리스트

hot broker와 leader 수를 비교했다
패턴이 restart나 failure 뒤에 시작됐는지 확인했다
preferred replica 기대값을 확인했다
auto.leader.rebalance.enable와 관련 threshold를 확인했다
workload skew와 leadership skew를 분리했다

FAQ

Q. 왜 restart한 broker는 시원한데 다른 broker만 계속 뜨겁죠?

restart한 broker는 follower로 먼저 돌아오고, leader를 바로 되찾지 못할 수 있기 때문입니다.

Q. hot broker imbalance는 항상 traffic 자체가 uneven하다는 뜻인가요?

아니요. recovery 뒤 leadership이 uneven하게 남았다는 뜻일 때가 많습니다.

Q. 자동 leader balancing에서 제일 중요한 broker 설정은 뭔가요?

auto.leader.rebalance.enable, leader.imbalance.check.interval.seconds, leader.imbalance.per.broker.percentage입니다.

Q. producer retry를 leader imbalance와 같이 봐야 하는 이유가 뭔가요?

producer request는 leader로 가기 때문에, leader가 몰린 broker에서는 latency와 retry도 함께 올라가기 쉽기 때문입니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.