Mar 23, 2026

마지막 업데이트 Mar 31, 2026

Kafka Rebalancing Too Often 가이드

Kafka consumer group에서 rebalance가 너무 자주 일어나면 겉으로는 lag 증가, idle consumer, 작업이 계속 흔들리는 증상으로 보이기 쉽습니다. 하지만 많은 경우 Kafka 자체가 불안정한 것이 아니라 flapping runtime, delayed poll, deployment churn에 Kafka가 정상적으로 반응하고 있는 것입니다.

핵심은 먼저 membership이 실제로 흔들리는지 확인하고, 그다음 runtime instability, missed poll deadline, assignment나 protocol 문제를 분리해서 보는 것입니다. heartbeat 계열 설정을 먼저 만지기 전에 이 분기를 해야 합니다.

frequent rebalancing은 보통 무엇을 뜻하나

실무적으로 보면 frequent rebalancing은 group이 유효한 작업을 멈추고 assignment를 계속 다시 나누고 있다는 뜻입니다.

보통 아래 패턴 중 하나와 연결됩니다.

consumer가 자꾸 restart됨
consumer가 poll deadline을 놓침
heartbeat와 session timing이 환경과 맞지 않음
assignment 변경 비용이 workload에 비해 너무 큼

consumer가 실제로 안정적인지 먼저 보세요

설정을 바꾸기 전에 group 자체가 안정적인지 확인해야 합니다.

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

consumer가 자주 restart되거나 redeploy되는가
container가 부하 중에 reschedule되는가
downstream timeout 때문에 member가 흔들리는가
rollout 직후부터 rebalance가 시작됐는가

membership 자체가 불안정하다면 fix는 Kafka 바깥에 있을 가능성이 큽니다.

poll timing은 여전히 가장 먼저 볼 항목 중 하나입니다

Kafka consumer config 문서에서 max.poll.interval.ms는 poll() 호출 사이 최대 지연 시간입니다.

즉 프로세스가 살아 있어도 handler가 느리면 rebalance loop가 생길 수 있습니다.

흔한 흐름은 이렇습니다.

처리 속도가 느려진다
poll()이 너무 늦어진다
consumer가 실패한 것으로 간주된다
group이 rebalance한다
lag가 오르고 useful work가 멈춘다

group protocol과 assignment 전략은 생각보다 중요합니다

Kafka rebalance protocol 문서는 newer group behavior가 rebalance 시간을 줄이고 더 disruptive한 패턴을 피할 수 있다고 설명합니다.

많은 팀이 모든 rebalance를 Kafka 원래 동작으로 보지만, 실제로는 protocol이나 assignor choice가 disruption을 키우는 경우도 있습니다.

흔한 원인

1. consumer가 계속 restart됨

group이 흔들리는 이유가 Kafka보다 runtime 불안정성일 수 있습니다.

2. 처리 때문에 `poll()`이 너무 늦어짐

애플리케이션은 살아 있지만 Kafka 기준으로는 assignment를 유지하기에 너무 느립니다.

3. session과 heartbeat 기대치가 환경과 맞지 않음

network jitter, overloaded runtime, 좋지 않은 기본값이 group을 불안정하게 보이게 할 수 있습니다.

4. assignment churn 비용이 너무 큼

빈번한 변경이 반복적인 stop-and-resume 사이클로 이어집니다.

실전 점검 순서

1. membership이 실제로 flapping하는지 확인하세요

member가 실제로 바뀌지 않는데도 다른 증상을 rebalance churn으로 오해하고 있을 수 있습니다.

2. restart, deployment, rescheduling을 확인하세요

여기서 조사 방향이 훨씬 단순해지는 경우가 많습니다.

3. `poll()` timing과 handler latency를 보세요

많은 rebalance 문제는 Kafka 문제가 아니라 consumer-loop 문제가 Kafka 증상처럼 보이는 것입니다.

4. 어떤 group protocol과 assignment behavior를 쓰는지 확인하세요

팀이 기대하는 동작과 실제 동작이 다를 수 있습니다.

5. rebalance 빈도와 lag 증가, downstream slowdown을 비교하세요

Kafka가 불안정한 것인지, 불안정한 앱에 정상적으로 반응하는 것인지 구분할 수 있습니다.

바로 확인할 명령

kafka-consumer-groups.sh --bootstrap-server <broker:9092> --group <group> --describe
kafka-topics.sh --bootstrap-server <broker:9092> --describe --topic <topic>
grep -i rebalance <consumer-log-file>

이 명령으로 group membership, partition ownership, 로그 속 rebalance event 빈도를 같이 볼 수 있습니다.

초반 분기에 좋은 shortcut

group이 계속 rebalance할 때는 아래 중 무엇이 먼저 보이는지 보세요.

member가 반복적으로 join과 leave를 한다
handler가 느리고 poll() 간격이 길다
rollout이나 infrastructure churn이 같은 시점에 시작됐다
assignment 변경 자체가 workload에 특히 큰 비용을 만든다

이 분기만으로도 heartbeat 설정부터 만지는 실수를 줄일 수 있습니다.

실전 관점

frequent rebalance는 근본 원인인 경우보다, 이미 불안정한 consumer loop나 deployment loop, runtime loop가 있다는 신호인 경우가 많습니다.

즉 rebalance knob만 만지면 group은 조용해질 수 있어도 실제로 건강해지는 것은 아닐 수 있습니다.

하나 더 던지면 좋은 질문

group이 계속 rebalance할 때는 “Kafka가 interruption을 만들고 있나, 아니면 이미 있는 interruption에 반응하고 있나?”를 같이 물어보세요.

이 질문으로 보통 아래를 빠르게 좁힐 수 있습니다.

runtime churn
slow handler와 delayed poll
deployment나 infrastructure churn

이 관점이 heartbeat 계열 설정을 먼저 만지는 것보다 훨씬 실전적입니다.

FAQ

Q. rebalance가 자주 일어나면 항상 Kafka가 문제인가요?

아니요. consumer 애플리케이션이나 runtime이 불안정한 경우가 더 많습니다.

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

member restart와 missed poll deadline이 있는지 보는 것입니다.

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

보통 Kafka max.poll.interval.ms Troubleshooting이나 Kafka Consumer Lag Increasing입니다.

Q. 언제 heartbeat 계열 설정부터 만지는 걸 멈춰야 하나요?

restart churn이나 느린 handler가 rebalance를 만든다는 증거가 보이기 시작할 때입니다.

먼저 읽어볼 가이드

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