카프카 성능 최적화를 위한 기본 튜닝 포인트

 

 

카프카의 성능은 “메시지 묶음 크기(배치)·버퍼 메모리·압축 방식·스레드/소켓 설정 같은 단 몇 가지 파라미터 조합으로도 수 배 이상 달라집니다. 프로듀서는 batch.size·linger.ms·compression.type을 키로 네트워크 효율을 극대화하고, 컨슈머는 fetch.min.bytes·max.poll.records 등으로 읽기 배치를 조절합니다. 브로커는 num.network.threads·num.io.threads·socket.* 버퍼·log.segment.bytes·replica.* 값을 하드웨어 대역폭에 맞춰야 병목을 없앨 수 있습니다. 아래 가이드는 프로듀서 → 컨슈머 → 브로커 순으로 핵심 튜닝 포인트를 정리하고, 각 설정이 TPS·지연·CPU·디스크 I/O에 미치는 영향을 실제 벤치마크·공식 문서 기반으로 설명합니다.

---

1. 프로듀서 튜닝 핵심

1.1 배치 크기와 지연

• batch.size를 기본 16 KB에서 100–200 KB로 늘리면 패킷당 헤더·ACK 오버헤드가 줄어 대역폭이 3–4 배 효율화됩니다.
• linger.ms를 0→10-100 ms로 높이면 지정 시간 동안 레코드를 모아 한 번에 전송하므로 TPS가 증가하지만, 그만큼 엔드투엔드 지연이 추가됩니다.

1.2 버퍼 메모리 & 인플라이트

• buffer.memory는 전송 대기 중인 레코드를 위한 프로듀서 JVM 힙 공간(기본 32 MB)입니다. 애플리케이션이 burst 트래픽을 내면 buffer.exhausted 오류가 날 수 있으므로 예상 TPS×linger.ms에 맞춰 늘립니다. 
• max.in.flight.requests.per.connection을 1→5 사이에서 조정하면 순서를 유지하면서도 동시 전송 파이프라인을 늘려 CPU idle 시간을 줄일 수 있습니다. 

1.3 압축

• LZ4·Snappy는 CPU 대비 최고 처리량을, Zstd는 최고 압축률을 제공합니다. 8 KB 메시지를 기준으로 LZ4/Snappy ≈ 3.4 K msg/s, Zstd ≈ 2.1 K msg/s, Gzip ≈ 0.8 K msg/s 벤치마크가 보고되었습니다. 
• 압축은 브로커 디스크·네트워크 사용량을 40–75 % 절감하므로 꾸준한 고부하 파이프라인(로그·IoT)에서 필수입니다. 

1.4 대용량 메시지 대비

• 1 MB가 넘는 레코드는 compression.type 활성화 후 message.max.bytes·replica.fetch.max.bytes·max.request.size 를 함께 늘립니다.

---

2. 컨슈머 튜닝 핵심

2.1 Fetch 배치

• fetch.min.bytes를 1→50 KB 이상으로 올리면 브로커가 적당히 데이터를 모아 한 번에 내려주어 I/O 호출 수가 감소합니다(지연 ↑).
• fetch.max.wait.ms는 위 조건이 충족되지 않을 때 최대 대기 시간을 제한합니다. 낮추면 지연을 줄이지만 빈 패킷이 많아집니다. 

2.2 폴링·레코드 수

• max.poll.records 값이 너무 크면 애플리케이션이 처리하기 전 세션 타임아웃(session.timeout.ms)에 걸려 리밸런스가 발생할 수 있으므로, 처리 시간 × 레코드 수 < max.poll.interval.ms를 만족하게 조정합니다. 

2.3 파티션당 페치

• max.partition.fetch.bytes 기본 1 MB → 4–16 MB로 확대하면 큰 배치가 잘려 반환되는 현상을 막아 디스크 seek를 줄입니다.

2.4 하트비트 & 리밸런스

• heartbeat.interval.ms는 session.timeout.ms의 1/3 이하로, 너무 크면 장애 감지가 늦고 너무 작으면 브로커 CPU를 낭비합니다.

---

3. 브로커 튜닝 핵심

3.1 스레드 풀

파라미터 기본 권장 시작점 설명

num.network.threads	3	CPU 코어 ÷ 2	소켓 읽기/쓰기 스레드 · AWS MSK는 m5.4xlarge에 8 개 권장
num.io.threads	8	디스크 수 × 8	요청 처리·로그 플러시 스레드, CPU 코어 수 이하로 설정
queued.max.requests	500	부하에 따라 1-2 K	대기열 포화 시 back-pressure 조정

3.2 소켓 버퍼

• 대역폭-지연 곱(BDP)보다 작으면 TCP 윈도 확장에 발목이 잡힙니다. 원거리 복제라면 socket.send/receive.buffer.bytes를 1 MB 이상으로 확대합니다. 

3.3 로그 세그먼트 & 보존

• log.segment.bytes 기본 1 GB를 2–4 GB로 키우면 segment flush 회수가 줄어 디스크 IOPS를 절감하지만, 레플리카 재복구 시간이 늘어납니다. 
• retention.bytes/ms 로 보존 정책을 분리(용량 vs 시간)하면 장기 보관 토픽의 디스크 압박을 예측 가능하게 관리할 수 있습니다. 

3.4 복제 지표

• replica.lag.time.max.ms 는 팔로워가 뒤처졌다고 판단하기까지의 허용 지연(기본 30 초)입니다. 너무 짧으면 빈번한 ISR 제외로 리더 쓰기 중단, 너무 길면 장애 복구 시간이 길어집니다. 

3.5 파티션 수 & 하드웨어

• AWS MSK는 m5.large당 1 000 개 파티션(리더+팔로워 합) 을 권장 기준으로 제시합니다. 파티션이 과다하면 메타데이터 처리 부하가 급증해 컨트롤러 지연이 발생합니다.

---

4. 모니터링과 벤치마크

지표 의미 임계치

kafka.server:type=RequestMetrics,name=Produce,totalTimeMs	프로듀스 요청 전체 지연	P99 < 10 ms
NetworkProcessorAvgIdlePercent	네트워크 스레드 유휴율	< 25 %면 num.network.threads↑
UnderReplicatedPartitions	복제 지연 파티션 수	지속적으로 0 유지
records-lag(컨슈머)	브로커-컨슈머 간 지연 레코드 수	스파이크 시 fetch.*·max.poll.records 검토

kafka-producer-perf-test·kafka-consumer-perf-test로 메시지 크기·TPS·압축별 시나리오를 반복 측정하여 TPS/지연 곡선을 확보하고, 모니터링 대시보드로 실부하와 비교해야 합니다. 

---

5. 실전 체크리스트

1. 프로듀서: batch.size·linger.ms·compression.type 조정 후 buffer.memory 용량 확인
2. 컨슈머: 처리 시간에 맞춰 fetch.min.bytes·max.poll.records·session.timeout.ms 삼각 조정
3. 브로커: CPU 코어 수 대비 num.network/io.threads 맞추고 socket.*·queued.max.requests 튜닝
4. 디스크: log.segment.bytes·retention.* 으로 I/O 패턴과 스토리지 비용 균형
5. 복제: replica.lag.time.max.ms·min.insync.replicas 로 내구성 vs 가용성 정책 설정
6. 모니터링: TPS·지연·오류율·ISR·파일 핸들 등 핵심 지표를 대시보드화 후 부하-시험 주기마다 검증

위 포인트를 단계별로 적용-측정-조정하면 하드웨어 증설 없이도 카프카 클러스터의 처리량과 안정성을 눈에 띄게 높일 수 있습니다.