Kafka 운영과 모니터링

운영의 목표

Kafka 클러스터를 운영한다는 것은 메시지 손실 없이, 지연 없이, 균형 있게 클러스터를 유지하는 것이다. 이 세 가지 목표가 흔들릴 때 어떤 지표가 먼저 빨간불을 켜는지 아는 것이 운영의 핵심이다.

모니터링 아키텍처

Kafka 브로커·프로듀서·컨슈머는 모두 JMX(Java Management Extensions) 로 메트릭을 노출한다. 일반적인 수집 파이프라인은 다음과 같다.

Kafka 4.0 기준으로 ZooKeeper가 제거되어 KRaft 모드가 기본이다. ZooKeeper 전용 메트릭은 더 이상 관련 없다.

반드시 모니터링해야 할 브로커 메트릭

1. UnderReplicatedPartitions

kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

ISR 수가 replication factor보다 작은 파티션 수다. 0 이상이면 즉시 확인해야 한다. 브로커 장애, 네트워크 단절, GC 지연이 원인인 경우가 많다.

2. ActiveControllerCount

kafka.controller:type=KafkaController,name=ActiveControllerCount

클러스터 전체 합이 정확히 1이어야 한다. 0이면 컨트롤러가 없고, 2 이상이면 스플릿 브레인 상태다.

3. OfflinePartitionsCount

kafka.controller:type=KafkaController,name=OfflinePartitionsCount

리더가 없어 읽기/쓰기가 불가능한 파티션 수. 0이 아니면 데이터 접근 장애가 발생 중이다.

4. BytesInPerSec / BytesOutPerSec

kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec

브로커 처리량 추이. 급격한 스파이크는 소비자 재균형(rebalance) 폭풍이나 프로듀서 폭발 쓰기를 나타낼 수 있다.

5. RequestQueueSize

kafka.network:type=RequestChannel,name=RequestQueueSize

브로커 요청 큐 길이. 이 값이 지속적으로 증가하면 브로커가 요청을 처리하는 속도보다 들어오는 속도가 빠르다는 신호다.

컨슈머 랙(Consumer Lag) — 가장 중요한 지표

컨슈머 랙은 파티션의 최신 오프셋(LEO)과 컨슈머 그룹이 커밋한 오프셋의 차이다.

lag = log_end_offset − committed_offset

랙이 증가한다는 것은 컨슈머가 프로듀서를 따라가지 못한다는 뜻이다. 방치하면 처리 지연이 무한정 누적된다.

컨슈머 랙은 kafka-consumer-groups.sh --describe CLI 또는 Prometheus + Kafka Lag Exporter 조합으로 수집한다. 알림 임계값은 서비스 SLA에 따라 다르지만, 랙이 지속적으로 증가하는 추이(slope > 0)를 감지하는 것이 중요하다.

토픽 관리

보존 정책(Retention)

보존 기간을 너무 짧게 설정하면 컨슈머가 다운됐다가 돌아올 때 처리할 메시지가 이미 삭제돼 있을 수 있다. 처리 지연 SLA와 스토리지 비용을 균형 있게 설정해야 한다.

파티션 증가

파티션 수는 늘릴 수 있지만 줄일 수 없다. 파티션이 늘어나면 동일 키 레코드가 다른 파티션으로 이동할 수 있으므로 키 기반 순서 보장이 깨진다. 증가는 신중하게 계획하자.

# 파티션 늘리기
kafka-topics.sh --alter --topic my-topic --partitions 12 \
  --bootstrap-server localhost:9092

리밸런스(Consumer Rebalance)

컨슈머 그룹에 멤버가 추가·제거될 때 파티션 할당이 재조정된다. 리밸런스가 일어나는 동안 컨슈머는 처리를 멈춘다. 이를 STW(stop-the-world) 리밸런스라 부른다.

리밸런스를 줄이는 방법:

• heartbeat.interval.ms / session.timeout.ms 적절히 설정 (너무 짧으면 불필요한 리밸런스)
• max.poll.interval.ms 내에 처리를 완료하도록 배치 크기 조절
• Cooperative Sticky Assignor 사용: 파티션 이동을 최소화하는 증분 리밸런스 방식

Kafka 3.1+ 기본 파티션 할당자는 CooperativeStickyAssignor다.

운영 CLI 도구 모음

오프셋 리셋

처리 오류 후 다시 처음부터 처리하거나 특정 시점으로 되돌릴 때 사용한다.

# 특정 타임스탬프 이후부터 재처리
kafka-consumer-groups.sh \
  --bootstrap-server localhost:9092 \
  --group my-consumer-group \
  --topic my-topic \
  --reset-offsets \
  --to-datetime 2026-06-01T00:00:00.000 \
  --execute

성능 튜닝 핵심 포인트

브로커

• num.io.threads: 디스크 I/O 스레드 수. CPU 코어의 2배 정도가 일반적 출발점.
• log.segment.bytes: 세그먼트 크기. 너무 작으면 파일 수가 많아져 오버헤드 증가.
• socket.send.buffer.bytes / socket.receive.buffer.bytes: 네트워크 처리량이 병목이라면 조정.

프로듀서

• linger.ms: 배치 대기 시간. 0이면 즉시 전송(낮은 지연), 높을수록 처리량 증가.
• batch.size: 배치 크기. 기본 16KB; 높은 처리량에서는 64KB~128KB 고려.
• compression.type=lz4|zstd: 압축으로 네트워크 대역폭과 스토리지 절약.

컨슈머

• fetch.min.bytes: 최소 응답 크기. 높일수록 처리량↑, 지연↑.
• max.poll.records: 한 번에 받는 최대 레코드 수. 처리 시간과 균형 맞춤.

요약: 운영 점검 체크리스트

1. UnderReplicatedPartitions = 0 유지
2. ActiveControllerCount = 1 확인
3. 컨슈머 랙 증가 추이 알림 설정
4. 토픽 보존 정책이 처리 지연 SLA와 맞는지 정기 검토
5. 리밸런스 빈도 모니터링; STW 리밸런스가 잦으면 max.poll.interval.ms 또는 할당 전략 재검토
6. 브로커 디스크 사용률 80% 초과 전 확장 계획

Open Questions

• KRaft 모드에서 컨트롤러 브로커와 일반 브로커를 분리할지 겸용으로 운영할지는 클러스터 규모에 따라 다르며, 대규모 프로덕션 권고 기준은 추가 조사 필요.
• 멀티 클러스터 환경(MirrorMaker 2)의 컨슈머 랙 집계 방식은 단일 클러스터와 다르게 구성해야 하는데 실제 사례 확인 필요.

References

• https://kafka.apache.org/documentation/#monitoring
• https://www.datadoghq.com/blog/monitoring-kafka-performance-metrics/
• https://signoz.io/guides/kafka-metrics/
• https://www.instaclustr.com/education/apache-kafka/kafka-monitoring-key-metrics-and-5-tools-to-know-in-2025/
• https://edgedelta.com/company/knowledge-center/kafka-metrics-monitoring
• https://docs.confluent.io/platform/current/kafka/broker-metrics.html
• https://www.automq.com/blog/kafka-retention-policy-concept-best-practices
• https://www.automq.com/blog/apache-kafka-performance-tuning-tips-best-practices
• https://newrelic.com/blog/best-practices/kafka-best-practices