Apache Kafka는 대규모 실시간 데이터를 처리하는 데 최적화된 분산 메시지 브로커다. 그런데 운영하다 보면 모니터링에서 CPU 사용률이 꽤 높게 보일 때가 있다. 그렇다면 Kafka는 원래 CPU를 많이 사용하는 구조일까? 실제 워커 방식과 내부 구성으로 설명해보겠다.
Kafka가 CPU를 많이 사용하는 이유
1) 네트워크 I/O + 배치 처리 구조
Kafka는 데이터를 한 건씩 처리하는 방식이 아니라 배치(batch)로 묶어 한 번에 처리한다.
이때 네트워크 요청을 계속 수신하고 패킷을 묶는 과정에서 브로커 스레드가 CPU를 지속적으로 사용한다.
2) 압축/해제(Compression/Decompression) 기능
프로듀서가 메시지를 압축해서 전송하면, 브로커는 다음을 수행한다.
- 메시지 압축 해제
- 디스크 저장 시 재압축 가능
- 컨슈머로 보낼 때 재압축
→ GZIP, Snappy, LZ4 등을 사용할수록 CPU 부담이 커진다.
→ 실제 운영 환경에서도 압축률을 높게 쓰면 CPU spikes(급등)가 자주 발생한다.
3) Replication 스레드 부하
Kafka는 기본적으로 replication factor 3을 많이 사용한다.
1개의 메시지를 처리하면 브로커는
→ 다른 2개 브로커로 복제
→ ACK 확인
→ ISR 관리
이 복제 과정이 CPU + 네트워크 + 디스크 I/O를 모두 사용한다.
특히 리더 브로커는 replication 처리 때문에 CPU 사용률이 더 높다.
4) Page Cache 기반 아키텍처
Kafka는 데이터 저장을 OS Page Cache로 처리한다.
이 과정에서 브로커가 디스크 대신 CPU 중심으로 처리 효율을 높이기 때문에, CPU 사용률이 생각보다 높게 나타나는 것이 정상이다.
그렇다면 Kafka는 원래 CPU를 많이 쓰는 서비스인가?
🔹 정답: “적당히 높은 CPU를 쓰는 것이 정상”
Kafka는 디스크 I/O보다 CPU 기반 처리가 많기 때문에,
CPU 40~70% 사용력이 지속적으로 나오는 것은 정상적인 동작 범위라고 보면 된다.
🔹 CPU가 정말 높은 경우는?
다음과 같은 경우는 튜닝이 필요할 수 있다.
- 메시지 압축 방식이 비효율적(GZIP)
- 브로커에 partitions가 과도하게 많음
- replication lag이 자주 발생함
- GC(가비지 컬렉션)로 CPU가 튀는 패턴 존재
- 잘못된 batch 설정으로 메시지를 자주 flush 하는 경우
CPU 사용량 줄이는 방법
✔ Compression 변경
GZIP → Snappy 또는 LZ4로 변경하면 CPU 사용량 크게 줄어듬.
✔ Producer Batch 조정
batch.size, linger.ms 등을 조정해 메시지 묶음 처리 효율을 높임.
✔ Partition 개수 점검
브로커당 파티션이 2000~3000을 넘으면 CPU 사용률 급등.
✔ GC 튜닝
JVM 옵션 조정
- G1GC
- heap 크기 최적화
✔ 리더 분산(Rebalance)
한 브로커에 리더 파티션이 과하게 몰리면 CPU가 한쪽만 90% 찍는 경우 발생.
결론: Kafka CPU 사용률은 높아 보일 수 있으나 대부분 정상
Kafka는 설계 자체가 CPU 중심 아키텍처이기 때문에 다른 시스템보다 CPU 사용률이 높게 보이는 것이 자연스럽다.
하지만
- 압축률
- 파티션 수
- replication 구조
- JVM GC
이 네 가지가 원인일 때는 튜닝을 통해 CPU 부하를 크게 줄일 수 있다.