Kafka Consumer Lag 실전 대응 — 원인 진단·리밸런싱·처리량 튜닝

Kafka 운영에서 Consumer Lag이 늘어난다는 것은 “아직 처리하지 못한 레코드가 쌓인다”는 뜻입니다. Lag 자체는 장애가 아니라 생산 속도와 소비 속도의 차이를 보여주는 신호입니다. 트래픽이 몰린 뒤 빠르게 줄면 정상적인 버퍼일 수 있지만, 계속 증가하면 지연 SLA와 보관 기간을 위협합니다.

문제 해결은 Consumer 인스턴스를 무조건 늘리는 것보다 유입량 → 파티션별 Lag → 처리시간 → 리밸런싱 → 외부 의존성 순서로 원인을 분리하는 것이 먼저입니다.

핵심 요약

• Lag은 최신 Log End Offset과 Consumer가 커밋한 Offset의 차이입니다.
• 평균 Lag보다 파티션별 Lag 증가 속도와 가장 오래된 메시지의 지연시간이 중요합니다.
• Consumer 수는 파티션 수를 넘겨도 같은 그룹의 병렬성이 더 늘지 않습니다.
• max.poll.interval.ms를 넘기면 Consumer가 실패로 간주되어 리밸런싱이 발생할 수 있습니다.
• 배치 크기·스레드 수를 바꾸기 전 DB, 외부 API, GC, CPU 병목을 확인해야 합니다.

1. Lag을 계산하는 기준

Consumer Lag = Log End Offset - Committed Offset

처리 여유율 ≈ 소비 처리량 / 생산 처리량
복구 예상시간 ≈ 누적 Lag / (소비 처리량 - 생산 처리량)

소비 처리량이 생산 처리량보다 작으면 복구 예상시간은 계산할 수 없고 Lag은 계속 증가합니다. Offset 기준 Lag은 메시지 크기와 처리 비용을 반영하지 않으므로, “가장 오래된 미처리 메시지의 나이”와 함께 봅니다.

2. 가장 먼저 확인할 명령과 지표

kafka-consumer-groups.sh \
  --bootstrap-server broker:9092 \
  --describe \
  --group order-worker

관찰가능한 원인다음 확인

모든 파티션 Lag 증가	전체 처리량 부족	CPU, DB, 외부 API, GC
한 파티션만 증가	Hot Key·데이터 불균형	Key 분포, 메시지별 처리시간
Lag이 톱니처럼 급등	리밸런싱·배치 작업	그룹 이벤트, 배포 시점
처리량은 높은데 커밋 지연	Offset 커밋·트랜잭션 문제	커밋 실패와 재처리 로그

3. max.poll.interval.ms와 리밸런싱

max.poll.interval.ms는 Consumer가 poll()을 다시 호출할 수 있는 최대 간격입니다. 한 번 가져온 레코드를 처리하는 시간이 이 값을 넘으면 Consumer가 응답하지 않는 것으로 판단되어 파티션이 재할당될 수 있습니다.

max.poll.records × 레코드당 P99 처리시간
  < max.poll.interval.ms 안의 안전한 처리 예산

해결책은 interval을 무한히 늘리는 것이 아닙니다. max.poll.records를 줄이거나 무거운 처리를 별도 Worker로 넘기고, 처리의 멱등성을 확보합니다. 배포 때 반복되는 리밸런싱은 Cooperative Sticky Assignor와 Static Membership의 적용 가능성도 검토합니다.

4. 처리량을 높이는 네 가지 레버

1. 파티션과 Consumer 병렬성: 현재 파티션 수 안에서 Consumer를 늘리고, 부족하면 Key 순서 보장과 운영 비용을 검토한 뒤 파티션을 늘립니다.
2. 배치 처리: DB Insert·외부 호출을 묶어 왕복 비용을 줄입니다. 실패 시 부분 재처리 정책이 필요합니다.
3. Fetch 튜닝: 처리량 중심 워크로드는 fetch.min.bytes와 fetch.max.wait.ms를 함께 조정해 작은 Fetch를 줄일 수 있습니다.
4. 느린 의존성 분리: DB Lock, Connection Pool, Rate Limit이 병목이면 Kafka 옵션보다 의존 서비스를 먼저 고칩니다.

5. Hot Partition 대응

특정 고객·상품 Key에 트래픽이 몰리면 한 파티션만 뒤처지고 다른 Consumer는 유휴 상태가 됩니다. Key별 이벤트 수와 처리시간을 상위 N개로 집계해 원인을 확인합니다.

• 순서 보장이 필요 없는 이벤트는 Key 분산 방식을 바꿉니다.
• 대형 고객은 별도 Topic 또는 전용 처리 경로로 분리합니다.
• 무거운 메시지를 별도 Queue로 넘기되 실패와 순서 정책을 명시합니다.
• 파티션 증가는 기존 Key의 배치 위치와 순서 의미에 영향을 줄 수 있어 사전 검증합니다.

6. 장애 대응 체크리스트

1. 생산·소비 records/s와 파티션별 Lag 증가율을 같은 시간축으로 봅니다.
2. 최근 배포, 스키마 변경, 리밸런싱 횟수를 확인합니다.
3. 처리시간 P50·P95·P99와 실패·재시도 비율을 측정합니다.
4. DB Pool, 외부 API, CPU, Heap, GC를 확인합니다.
5. Consumer 확장 전 파티션 수와 Hot Key를 점검합니다.
6. 복구 후 Lag뿐 아니라 중복·누락과 처리 순서를 검증합니다.

공식 자료

• Apache Kafka Documentation
• Apache Kafka Consumer Configs

정리: Consumer Lag은 원인이 아니라 결과입니다. 파티션별 증가 패턴과 처리시간을 먼저 확인하고, 리밸런싱·외부 의존성을 분리한 뒤 병렬성·배치·Fetch 설정을 조정해야 재발을 막을 수 있습니다.