Mar 23, 2026

마지막 업데이트 Mar 23, 2026

Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드

Kafka consumer lag가 계속 늘어날 때 먼저 던져야 할 질문은 “lag를 어떻게 초기화하지?”가 아니라 “왜 consumer가 들어오는 속도를 따라가지 못하고 있지?”입니다.

이 글은 가장 빠른 점검 순서에 집중합니다. consumer가 규칙적으로 polling 하는지, 처리 속도가 충분한지, rebalance나 downstream 작업 때문에 시간이 새고 있지는 않은지부터 봅니다.

지금 증상이 정말 Kafka 문제인지, RabbitMQ backlog나 Redis 쪽 문제인지 아직 확신이 없다면 미들웨어 트러블슈팅 가이드부터 보고 분기를 잡는 편이 좋습니다.

consumer lag는 보통 무엇을 뜻할까

실무 관점에서 lag는 적어도 일부 partition에서 consumer가 뒤처지고 있다는 뜻입니다.

Apache Kafka 모니터링 문서는 consumer 쪽 max lag와 fetch rate를 함께 보라고 권장합니다. consumer가 따라가려면 max lag는 기준 이하이고, minimum fetch rate는 0보다 커야 합니다.

즉 lag는 숫자 하나가 아니라 처리율 균형이 깨졌다는 신호로 보는 편이 맞습니다.

poll timing부터 확인하기

Kafka consumer 설정 문서에 따르면 max.poll.interval.ms는 poll() 호출 사이에 허용되는 최대 지연 시간입니다. 이 시간이 너무 길면 consumer가 실패한 것으로 간주되고 그룹 rebalance가 발생할 수 있습니다.

그래서 이런 패턴을 먼저 의심해야 합니다.

consumer가 poll()을 너무 늦게 호출함
rebalance가 계속 끼어듦
poll 사이에 너무 많은 처리를 함

lag가 커지고 rebalance도 같이 보인다면 가장 먼저 볼 구간입니다.

처리 속도와 publish rate 비교하기

lag는 소비 속도가 생산 속도보다 느릴 때 커집니다.

흔한 원인은 이렇습니다.

downstream DB나 API가 느림
특정 partition에 트래픽이 몰림
handler가 동기적으로 너무 많은 일을 함
batch 크기와 poll 주기가 잘 맞지 않음

중요한 것은 lag를 독립된 메트릭으로 보지 말고 처리율 불균형의 증상으로 보는 것입니다.

자주 봐야 하는 consumer 설정

실무에서 자주 보는 설정은 다음과 같습니다.

max.poll.interval.ms
max.poll.records
max.partition.fetch.bytes
heartbeat 및 session 관련 설정

핵심은 “모든 값을 튜닝하자”가 아니라, 현재 값이 실제 처리 비용과 맞느냐입니다.

rebalance 부작용도 같이 보기

lag 증가는 consumer group 불안정성과 함께 나타나는 경우가 많습니다.

대표적인 흐름은 이렇습니다.

처리 속도가 떨어진다
poll 간격이 나빠진다
그룹 rebalance가 발생한다
진행이 다시 끊긴다
lag가 더 커진다

이 루프가 의심된다면 lag 그래프만 보지 말고 group 안정성도 같이 봐야 합니다. 반대로 레코드가 단순히 느린 것이 아니라 아예 애플리케이션으로 안 들어오는 것처럼 보인다면 Kafka 메시지가 소비되지 않을 때와 같이 보는 편이 좋습니다.

실전 점검 순서

lag를 partition별로 확인
consumer가 규칙적으로 poll하는지 확인
handler processing latency 확인
rebalance 빈도 확인
max.poll.interval.ms, max.poll.records 점검
input rate와 실제 consume rate 비교

이 순서가 offset reset보다 훨씬 빨리 원인을 설명해 줍니다.

흔한 원인

1. 비즈니스 로직이 느리다

consumer는 살아 있지만 handler가 따라가지 못합니다.

2. poll loop가 굶고 있다

앱이 poll()을 너무 늦게 호출합니다.

3. rebalance가 너무 자주 생긴다

유효한 처리 시간이 반복적으로 잘립니다.

4. partition 부하가 한쪽으로 몰린다

전체는 괜찮아 보여도 일부 partition이 병목입니다.

이 점검에서 churn, poll timing, idle consumer 패턴이 보이면 offset 조치보다 연결된 Kafka 후속 글로 바로 들어가는 편이 더 빠릅니다.

증상별 진입 힌트

consumer group은 살아 있는 것 같은데 lag만 계속 늘어나면 여기부터 보면 됩니다.
records가 아예 안 들어오는 쪽에 가깝다면 messages-not-consumed 글이 더 먼저일 수 있습니다.

바로 확인할 명령어

kafka-consumer-groups.sh --bootstrap-server <broker:9092> --group <group> --describe
kafka-topics.sh --bootstrap-server <broker:9092> --describe --topic <topic>
kafka-configs.sh --bootstrap-server <broker:9092> --entity-type topics --entity-name <topic> --describe

이 명령어로 partition별 lag, topic layout, 현재 topic 설정이 기대하는 처리 패턴과 맞는지를 먼저 볼 수 있습니다.

한 partition만 유난히 lag가 큰지, current offset이 멈춰 있는지, topic이나 consumer 설정이 handler 속도와 안 맞는지를 보세요.

FAQ

Q. lag가 늘면 무조건 Kafka 클러스터 문제인가요?

아닙니다. 애플리케이션 처리율 문제나 consumer group 동작 문제인 경우가 많습니다.

Q. 어떤 설정을 먼저 봐야 하나요?

보통 max.poll.interval.ms, max.poll.records, 그리고 실제 handler latency를 먼저 봅니다.

Q. offset reset으로 lag를 없애면 해결인가요?

원인을 이해하기 전에는 아닙니다. offset reset은 증상은 가릴 수 있어도 원인은 남길 수 있습니다.

먼저 읽어볼 가이드

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