Kafka Consumer Lag 장애 분석 - 적체가 커질 때 어디부터 봐야 할까

Consumer Lag이 의미하는 것

Consumer Lag은 producer가 넣은 메시지를 consumer가 얼마나 뒤늦게 따라가고 있는지를 보여줍니다.

하지만 중요한 것은 lag 숫자 자체보다도 아래입니다.

• 증가 속도
• 특정 토픽만의 문제인지
• 특정 consumer group만의 문제인지
• 일시적 스파이크인지 지속적 적체인지

장애 상황에서 먼저 구분할 것

Lag이 늘어난다고 해서 항상 Kafka broker가 문제인 것은 아닙니다.

먼저 아래 둘 중 어디에 가까운지 나눕니다.

1. 생산량 증가형

• producer 트래픽 급증
• consumer 처리량은 정상이나 따라가지 못함

2. 처리량 저하형

• consumer 애플리케이션 장애
• 외부 API/DB 병목
• 재시도 폭증
• GC, CPU, 네트워크 문제

이 구분을 먼저 해야 대응이 빨라집니다.

가장 먼저 보는 지표

• topic별 incoming rate
• consumer group lag
• partition별 lag 편차
• consumer 처리 성공/실패 건수
• 재시도 큐 또는 DLQ 증가
• broker/network/disk 상태

특히 partition별 lag 편차가 크면 consumer 수평 확장만으로 해결되지 않을 수 있습니다.

흔한 원인 1: 외부 의존성 병목

가장 흔한 실제 원인은 consumer 코드가 Kafka보다 뒤쪽 시스템에서 막히는 경우입니다.

예:

• DB insert 지연
• 외부 API timeout
• Redis 장애
• 내부 서비스 응답 지연

이 경우 consumer thread는 살아 있지만 처리 속도는 급격히 떨어집니다.

증상:

• lag 증가
• 애플리케이션 timeout 증가
• CPU는 높지 않을 수도 있음

흔한 원인 2: partition 불균형

메시지 키 분포가 치우치면 특정 partition에만 적체가 몰릴 수 있습니다.

증상:

• 일부 partition lag만 유독 큼
• consumer 인스턴스를 늘려도 효과가 작음
• 특정 key 처리에 병목이 집중됨

이 경우는 consumer 수보다 partition 설계와 key 전략을 다시 봐야 합니다.

흔한 원인 3: 재시도 폭증

일부 메시지가 계속 실패하며 재처리 루프를 돌면 전체 처리량이 무너집니다.

문제 패턴:

• poison message 존재
• validation 실패 메시지가 계속 재시도
• 외부 API 5xx로 대량 재시도 발생

이럴 때는 무조건 재시도보다:

• 즉시 DLQ 전환
• 특정 에러는 skip
• 재시도 backoff 조정

같은 완충 설계가 필요합니다.

흔한 원인 4: consumer rebalance 반복

rebalance가 자주 일어나면 정상 처리 시간이 계속 깎입니다.

원인:

• consumer 인스턴스 불안정
• GC pause
• heartbeat timeout
• 배포 중 잦은 재시작

이 경우 lag는 결과일 뿐, 진짜 문제는 consumer 안정성입니다.

장애 분석 순서 예시

실무에서는 대체로 아래 순서가 빠릅니다.

1. 특정 consumer group만 문제인지 확인
2. producer rate 급증 여부 확인
3. partition별 lag 편차 확인
4. consumer 에러율과 timeout 확인
5. 외부 의존성 지연 확인
6. rebalance 로그와 재시작 이력 확인

이 순서로 보면 broker 문제인지 애플리케이션 문제인지 대체로 빠르게 좁혀집니다.

대응 전략

단기 대응

• consumer replica 일시 확장
• 재시도 제한
• 문제 메시지 DLQ 전환
• 비핵심 후처리 비활성화

중기 대응

• 병목 API/DB 튜닝
• batch 처리 또는 async 전환
• partition 재설계
• 소비 로직 최적화

장기 대응

• consumer별 SLO 정의
• lag 기반 알림 정교화
• poison message 방지 체계
• 부하 테스트에 lag 시나리오 포함

알림 기준도 숫자 하나로 정하면 안 된다

예를 들어 lag 10,000이 항상 심각한 것은 아닙니다.

중요한 것은:

• 초당 유입량 대비 lag 증가율
• 복구 예상 시간
• 비즈니스 임계 시간 초과 여부

즉, lag count만이 아니라 time behind 관점도 같이 봐야 합니다.

재발 방지를 위해 남겨야 할 것

• 어느 토픽/partition에서 시작됐는가
• producer 급증인지 consumer 처리 저하인지
• 외부 의존성 영향이 있었는가
• DLQ/재시도 정책이 적절했는가
• 경보가 너무 늦었는가

이 기록이 있어야 같은 패턴의 장애를 다시 줄일 수 있습니다.

마무리

Kafka Consumer Lag 장애는 Kafka 자체 문제로 보이지만, 실제로는 애플리케이션 처리 병목이나 외부 의존성 문제가 원인인 경우가 많습니다.

좋은 대응의 핵심은 단순히 consumer 수를 늘리는 것이 아니라:

• 어디에서 처리량이 떨어졌는지 구분하고
• partition, 재시도, rebalance, 외부 의존성을 함께 보고
• 단기 복구와 장기 구조 개선을 나눠서 대응하는 것

입니다.