Mar 23, 2026

마지막 업데이트 Mar 31, 2026

Kafka leader imbalance: 왜 어떤 broker만 계속 뜨거울까

Kafka에서 몇몇 broker만 유난히 뜨겁게 보일 때 원인은 무작정 트래픽 증가보다 leadership 분포가 고르지 않게 남아 있기 때문인 경우가 많습니다. 많은 팀이 producer 튜닝이나 증설부터 생각하지만, 실제로는 일부 broker가 leader 역할을 지나치게 많이 들고 있는 것이 먼저 보정되어야 할 수 있습니다.

핵심은 먼저 진짜 workload skew인지 leadership skew인지 구분하고, hot broker와 restart 이력, preferred replica 동작을 같이 보는 것입니다.

먼저 workload skew와 leadership skew를 구분하세요

hot broker가 항상 workload 자체가 치우쳤다는 뜻은 아닙니다.

어떤 경우에는 실제로 특정 topic이나 partition family에 트래픽이 몰려 있습니다. 하지만 적지 않은 경우에는 cluster가 장애에서 복구된 뒤 leadership이 고르게 돌아오지 않아 일부 broker가 계속 더 많은 client-facing work를 처리하게 됩니다.

이 구분이 중요한 이유는 전자는 partitioning이나 workload 설계 문제이고, 후자는 cluster leadership 분포 문제이기 때문입니다.

leader imbalance는 보통 무엇을 뜻하나

Kafka 운영 문서는 broker가 restart되면 해당 partition에서 follower로 돌아온다고 설명합니다.

즉 restart 뒤에는 현재 leader를 가진 broker들이 계속 read와 write를 더 많이 받습니다. leadership이 균형 있게 복구되지 않으면 일부 broker만 계속 뜨거워지고, 다른 broker는 상대적으로 덜 바빠집니다.

preferred replica가 중요한 이유

Kafka는 preferred replica라는 개념을 사용해 leadership 분포를 더 건강하게 되돌리려 합니다.

문서에서도 auto.leader.rebalance.enable=true일 때 leadership을 preferred replica 쪽으로 되돌리려 시도할 수 있다고 설명합니다.

그래서 leader imbalance는 단순히 Kafka가 바쁘다가 아니라, 복구는 됐지만 leadership이 정상화되지 않았다는 신호일 수 있습니다.

broker 이력과 leadership 분포를 먼저 보세요

좋은 첫 질문은 아래입니다.

최근 broker restart나 crash가 있었는가
incident 중 leadership이 이동한 뒤 돌아오지 않았는가
뜨거운 broker가 실제로 leader를 더 많이 들고 있는가
leadership 문제 전부터 traffic 자체가 uneven했는가

hot broker 패턴이 복구 이후 시작됐다면 leadership imbalance 가능성이 매우 빠르게 올라갑니다.

consumer lag와는 다른 문제입니다

둘은 같이 나타날 수는 있지만 같은 문제는 아닙니다.

leader imbalance는 partition leadership 위치 문제
consumer lag는 consumer가 records를 따라가는 문제

서로 영향을 줄 수는 있지만, 조사 시작점은 다릅니다.

흔한 원인

1. broker restart 뒤 leadership이 고르지 않게 남음

cluster는 서비스 가능한 상태로는 복구됐지만 leadership 분포는 균형을 찾지 못했습니다.

2. preferred replica 쪽 복구가 기대만큼 일어나지 않음

cluster는 healthy해 보여도 운영자가 기대한 분포와는 다를 수 있습니다.

3. hot leader를 단순 트래픽 증가로 오해함

실제로는 특정 broker가 leader를 너무 많이 들고 있을 수 있습니다.

4. producer pressure가 imbalance를 더 악화시킴

retry, latency, broker load가 leader가 몰린 broker에서 더 크게 보입니다.

실전 점검 순서

1. hot broker와 leader placement를 비교하세요

가장 바쁜 broker가 실제로 leader를 더 많이 들고 있다면 leadership skew는 더 이상 막연한 의심이 아닙니다.

2. restart와 failure 이력을 확인하세요

hotspot 패턴이 broker event 직후 시작됐다면 추측이 훨씬 줄어듭니다.

3. preferred-replica rebalance가 기대되는 cluster인지 확인하세요

현재 환경에서 정상 분포가 무엇인지 먼저 알아야 지금 상태가 진짜 이상한지 판단할 수 있습니다.

4. workload heat와 leadership 분포를 비교하세요

이 단계에서 진짜 traffic skew와 cluster-state skew를 나눌 수 있습니다.

5. 해결이 cluster leadership 쪽인지 workload design 쪽인지 결정하세요

cluster가 leadership을 불균형하게 들고 있는데 producer tuning부터 들어가면 순서가 어긋납니다.

조사에 바로 쓰는 명령

kafka-topics.sh --bootstrap-server <broker:9092> --describe --topic <topic>
kafka-configs.sh --bootstrap-server <broker:9092> --entity-type brokers --describe
grep -i leader <broker-log-file>

이 명령으로 partition leadership, broker 설정 맥락, leader movement 로그를 같이 볼 수 있습니다.

첫 분기에 좋은 shortcut

일부 broker만 뜨거울 때는 아래 중 무엇이 먼저 보이는지 보세요.

broker restart나 failure
leader 수의 불균형
같은 node에서 producer retry와 latency 증가
broker event 이전부터 존재한 traffic skew

이 분기만으로도 cluster recovery 문제를 볼지 workload design 문제를 볼지 빨리 정할 수 있습니다.

FAQ

Q. leader imbalance면 Kafka가 고장 난 건가요?

아니요. 장애에서 복구된 뒤 leadership이 uneven하게 남은 경우가 많습니다.

Q. 가장 빠른 첫 단계는 무엇인가요?

hot broker 패턴이 broker restart나 failure 이후 시작됐는지 확인하는 것입니다.

Q. 다음으로 같이 볼 글은 무엇인가요?

보통 Kafka Producer Retries Too Much나 Kafka Consumer Lag Increasing입니다.

Q. 언제 workload skew 탓을 멈춰야 하나요?

recovery 이후 가장 뜨거운 broker가 실제로 leader를 불균형하게 많이 들고 있을 때입니다.

먼저 읽어볼 가이드

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