Kafka consumer lag가 큰 파티션이 보일 때 소비자 수를 늘리기 전에 어떤 원인을 어떻게 구분하나요?

Consumer lag는 파티션의 최신 위치와 소비자가 기록한 위치 사이의 차이를 나타내는 운영 단서입니다. lag 개수가 곧 처리 완료되지 않은 레코드 수나 사용자 영향의 크기를 직접 뜻하지는 않습니다. 레코드 크기·처리 비용·입력률·재시도·offset 커밋 시점에 따라 같은 1,000개도 회복 시간이 다릅니다. 저는 파티션별 lag, 가장 오래된 레코드의 age, 입력률, 실제 처리 완료율, 오류·재시도율과 하위 시스템 대기를 함께 보겠습니다. lag는 지연의 단서이며 원인과 완료 보장의 대체 지표는 아닙니다.

편중과 전체 포화를 구분합니다

한 파티션만 밀리면 특정 key의 hot partition, 무거운 레코드, 독성 메시지, 파티션 내 순서 제약을 의심합니다. 파티션은 충분한데 한 consumer의 CPU·I/O가 포화라면 처리 코드나 데이터 분포가 원인일 수 있습니다. 모든 파티션이 함께 밀리고 DB 연결 풀, 저장소, 외부 API가 포화라면 consumer 수를 늘리는 것이 하위 큐와 오류만 키울 수 있습니다. 반대로 파티션 수와 하위 자원에 여유가 있고 consumer 처리율이 병목이면 scale-out으로 입력보다 높은 처리율을 만들 수 있습니다.

커밋을 처리 시작 전에 하면 lag가 작아 보여도 처리 중 장애에서 레코드가 누락될 수 있고, 처리 완료 뒤 커밋하면 안전한 재처리 범위가 lag에 남습니다. 따라서 lag 0은 외부 DB 변경이나 사용자 효과가 확정됐다는 뜻이 아닙니다. DLQ로 보낸 레코드도 원래 비즈니스 처리가 성공한 것이 아니므로 정상 처리율과 복구 대상을 별도 집계합니다. 파티션을 늘리지 않고 consumer를 파티션보다 많이 두면 유휴 consumer가 생겨 수평 확장이 처리율을 높이지 못할 수 있습니다.

확장 성공 기준을 정합니다

입력률보다 처리율이 높아지는지, oldest message age가 허용 범위 안으로 회복되는지, 재할당 중복·DB 대기·비용이 감당 가능한지 실험합니다. 긴 DB 트랜잭션, 재시도 backoff, 배치 처리 때문에 표시 lag와 실제 효과 시점이 어긋나는 경우를 trace와 offset 기록으로 확인합니다. KEDA 같은 자동 확장은 lag를 신호로 삼을 수 있지만 파티션 수·Pod 수·하위 한도와 함께 설계해야 하며, lag를 줄이는 가장 싼 방법이 무조건 consumer 증설은 아닙니다.

offset commit 시점은 lag 숫자와 장애 시 의미를 바꿉니다. 처리 시작 전에 commit하면 소비자는 이미 처리한 것으로 기록하지만 실제 DB 변경 전에 죽을 수 있어 메시지가 누락될 수 있습니다. 처리 완료 뒤 commit하면 commit 전 장애에서 재처리될 수 있지만, 외부 효과가 멱등적이어야 중복이 안전합니다. 따라서 lag 0은 외부 DB 변경이나 사용자 효과가 확정됐다는 뜻이 아닙니다.

한 파티션의 독성 메시지가 뒤의 정상 메시지까지 막으면 consumer를 늘려도 같은 순서 제약 안에서는 해결되지 않습니다. key별 순서를 완화할지, 문제 레코드를 격리·DLQ할지 정해야 합니다. 자동 확장은 lag 개수 하나가 아니라 oldest age, 입력률, 처리율, 파티션 수, DB pool 포화, rebalance 시간과 cooldown을 사용하고, scale-out 전후 중복 처리율과 외부 부하를 비교하겠습니다.

처리 전에 offset을 commit하면 lag는 줄어도 commit 뒤 DB 변경 전에 죽은 레코드가 누락될 수 있습니다. 처리 후 commit은 commit 전 장애에서 재처리를 만들므로 외부 변경의 멱등성이 필요합니다. 이 둘을 구분하지 않으면 ‘lag를 줄였다’는 운영 목표가 데이터 유실을 감추는 결과가 될 수 있습니다.