컨슈머에서 실제로 손대게 되는 항목만 정리한다. 기본값은 Kafka 4.3 문서 기준이다[1].
| 항목 | 기본값 | 설명 |
|---|---|---|
bootstrap.servers |
— | 브로커 목록. 두세 대만 적어도 나머지는 자동으로 찾는다 |
group.id |
— | 컨슈머 그룹 이름. 같은 그룹이면 파티션을 나눠 갖는다 |
group.protocol |
classic |
consumer 로 바꾸면 KIP-848 새 리밸런스 프로토콜을 쓴다 |
client.id |
"" |
로그와 메트릭에서 구분하려면 넣는다 |
Kafka 4.0 부터 KIP-848 이 정식 제공된다. 기존 방식은 리밸런스가 돌 때 그룹 전체가 멈추지만(stop-the-world), 새 프로토콜은 그렇지 않다.
group.protocol=consumer
브로커도 4.0 이상이어야 한다.
| 항목 | 기본값 | 설명 |
|---|---|---|
auto.offset.reset |
latest |
커밋된 오프셋이 없을 때. earliest 는 맨 처음부터 |
기본값이
latest라 새 그룹으로 붙으면 그 시점 이후 메시지만 받는다. 과거 데이터를 모두 받아야 하면earliest로 둔다.
| 항목 | 기본값 | 설명 |
|---|---|---|
enable.auto.commit |
true |
주기적으로 자동 커밋 |
auto.commit.interval.ms |
5000 |
자동 커밋 주기 |
자동 커밋은 처리 완료를 보장하지 않는다. 메시지를 받아 두고 처리 중에 죽으면 이미 커밋돼 유실된다. 정확히 한 번 처리해야 하면 자동 커밋을 끄고 직접 커밋한다.
enable.auto.commit=false
consumer.commitSync(); // 처리 끝난 뒤
| 항목 | 기본값 | 설명 |
|---|---|---|
max.poll.records |
500 |
한 번의 poll() 이 가져오는 최대 레코드 수 |
max.poll.interval.ms |
300000 |
이 시간 안에 다시 poll() 하지 않으면 그룹에서 빠진다 |
session.timeout.ms |
45000 |
하트비트가 이 시간 동안 없으면 죽은 것으로 본다 |
heartbeat.interval.ms |
3000 |
하트비트 주기. session.timeout.ms 의 1/3 이하로 둔다 |
리밸런스가 계속 도는 가장 흔한 원인은 한 배치의 처리 시간이
max.poll.interval.ms를 넘는 것이다.
처리가 오래 걸리면max.poll.records를 줄이거나max.poll.interval.ms를 늘린다. 둘 중 앞쪽이 대개 낫다.
| 항목 | 기본값 | 설명 |
|---|---|---|
fetch.min.bytes |
1 |
이만큼 쌓일 때까지 기다린다. 올리면 요청 수가 줄어 처리량이 오른다 |
fetch.max.wait.ms |
500 |
fetch.min.bytes 가 안 차도 이 시간이면 보낸다 |
fetch.max.bytes |
52428800 |
한 요청의 최대 크기 (50MiB) |
max.partition.fetch.bytes |
1048576 |
파티션당 최대 (1MiB) |
지연보다 처리량이 중요하면 fetch.min.bytes 를 수만~수십만 바이트로 올린다. 대신 fetch.max.wait.ms 만큼 지연이 생긴다.
| 항목 | 기본값 | 설명 |
|---|---|---|
isolation.level |
read_uncommitted |
커밋되지 않은 트랜잭션 메시지도 읽는다 |
트랜잭션 프로듀서가 쓰는 토픽을 읽을 때는 read_committed 로 둬야 커밋된 것만 받는다.
# 그룹 상태와 랙
/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server kafka01:9092 \
--describe --group <그룹>
# 그룹 목록
/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server kafka01:9092 --list
# 오프셋 되돌리기 (컨슈머가 멈춰 있어야 한다)
/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server kafka01:9092 \
--group <그룹> --topic <토픽> --reset-offsets --to-earliest --execute
LAG 이 계속 늘어나면 컨슈머가 생산 속도를 못 따라가는 것이다. 파티션 수와 컨슈머 수를 함께 본다 — 컨슈머 수가 파티션 수보다 많으면 남는 컨슈머는 논다.
Kafka 4.3 Consumer Configs — 2026-09-16 확인. https://kafka.apache.org/43/configuration/consumer-configs/ ↩︎