📗 Kafka 프로비저닝 ( 개발계 )

🏳️‍🌈 [궁금한점]

• 카프카 최적화 방법

---

🔗목차

• Kafka 최적화 가이드
  • Kafka broker
  • Kafka producer
  • Kafka consumer
  • Zookeeper or KRaft (Kafka Raft)
  • 모니터링 \& 알림
  • 분산 파일 시스템/DB 연동 (옵션)
• 최적화 설정 추천

아키텍처 구성 요소

구성 요소	역할 및 설정 내용
Kafka Brokers	- 최소 3대 이상 구성 - 고성능 디스크 (예: NVMe) - JVM Heap Size (-Xmx, -Xms) 동일하게 설정 - num.io.threads, num.network.threads 적절 조정
Producers	- batch.size, linger.ms 조정으로 throughput 향상 - compression.type=snappy 추천 - acks=all, retries 설정으로 안정성 강화
Consumers	- Consumer Group으로 병렬 처리 - max.poll.records, fetch.min.bytes, fetch.max.wait.ms 설정 최적화 - offset 수동 커밋 설정 (enable.auto.commit=false)
Partition 설계	- 토픽당 파티션 수는 CPU 수 * 2 이상 권장 - 파티션 키를 통한 workload 분산 - 리더 브로커 고르게 분산
Replication	- 각 토픽 replication.factor는 3 이상 - ISR(In-Sync Replica) 모니터링 중요 - 장애 복구 대비 구성
Storage	- log.retention.hours, log.segment.bytes 튜닝 - 장기 저장 시 S3, HDFS 연동 고려 - 디스크 Full 방지를 위한 모니터링
Monitoring	- Prometheus + Grafana + Kafka Exporter 권장 - Alertmanager 연동으로 이상 감지 - lag, throughput, ISR 등 주요 지표 확인
Scale-out 전략	- broker 수 또는 파티션 수 증가로 확장 - 자동 리밸런싱 주의 (동시 처리량 고려) - 토픽/파티션 배치 최적화 필요

Zookeeper, KRaft 비교

항목	Zookeeper 기반 Kafka	KRaft 기반 Kafka (Zookeeper-less)
메타데이터 관리	외부 Zookeeper에서 관리	Kafka 자체의 Controller Quorum에서 관리
구성 복잡도	Zookeeper 별도 설치/운영 필요	Zookeeper 불필요 → 구성 단순화
시작 버전	Kafka 0.x ~ 현재 (Legacy)	Kafka 2.8 (preview), Kafka 3.3부터 안정화
복제 방식	Zookeeper - ZAB 프로토콜	Kafka Raft (KRaft) 프로토콜 사용
Controller 구조	단일 active controller + standby	Multi-controller (Raft quorum 기반)
고가용성	Zookeeper 장애 시 controller 선출 지연	Raft quorum으로 빠른 failover 가능
운영 복잡도	Zookeeper와 Kafka 버전/구성 관리 필요	Kafka 하나로 통합되어 운영 간편
보안 설정	Kafka ↔ Zookeeper 간 ACL 별도 관리 필요	Kafka 내 일원화된 보안 관리 가능
성능/지연	Zookeeper와의 통신 지연 존재	더 빠른 controller 반응 가능
이식성/클라우드	Stateful 서비스 + 외부 종속성	Zookeeper 없이 클라우드 배포 용이
지원 현황	현재까지 안정적 운영됨	Kafka 3.5+에서 기본 구조로 점차 전환 중

Kafka 활용

• 로그 수집 플랫폼: Fluent Bit/Logstash → Kafka → Elasticsearch
• 실시간 추천 시스템: Kafka → Flink/Spark Streaming → Redis
• 데이터 파이프라인: Kafka → Kafka Connect → S3, HDFS, Iceberg 등

Kafka 최적화 가이드

Kafka broker

• 브로커 수 늘리기: 트래픽에 따라 다르지만, 최소 3대 이상으로 시작해 샤딩과 복제를 분산.
• 토픽 파티션 수 증가: 병렬 소비 가능성을 확보하기 위해 토픽당 많은 파티션 수 설정 (예: 12, 24, 48 등).
• 리소스 설정: 디스크는 NVMe 또는 SSD 권장. RAM은 페이지 캐시용으로 넉넉히 (16GB 이상 권장). num.network.threads, num.io.threads, socket.send.buffer.bytes, log.segment.bytes 등 튜닝.

Kafka producer

• Batching & 압축: batch.size, linger.ms 튜닝하여 전송 효율 극대화.compression.type은 snappy 또는 lz4 권장.
• Ack 설정: acks=all + retries 로 안정성 확보.
• 병렬 처리: 멀티스레드 또는 async 방식으로 producer 풀 구성.

Kafka consumer

• 컨슈머 그룹 병렬성: 파티션 수 >= 컨슈머 인스턴스 수로 유지. max.poll.records / fetch.min.bytes 등 튜닝. 역직렬화 처리 최적화 (JSON, Avro 등 처리 속도 고려).

Zookeeper or KRaft (Kafka Raft)

Kafka 3.x 이상이라면 KRaft 모드 고려.안정적 운영 위해 별도 노드 구성 권장.

모니터링 & 알림

• Prometheus + Grafana 연동.
• 주요 메트릭: Under-replicated partitions, Consumer lag, Produce/Consume rate, Disk usage per broker

분산 파일 시스템/DB 연동 (옵션)

대량 데이터 처리 후 HDFS, S3, Iceberg, Delta Lake 등과 연계.
Kafka Connect, Flink, Spark Streaming 사용 가능.

최적화 설정 추천

구성 요소	설정 항목	설명	추천 값	설정 효과	트레이드오프 / 주의사항
Producer	acks	메시지 수신 확인 수준	all	모든 replica에 저장될 때까지 대기 → 데이터 안정성 ↑	latency ↑, throughput ↓ 가능
Producer	retries	전송 실패 시 재시도 횟수	5 이상	네트워크 오류 등 재시도 처리 → 신뢰성 ↑	순서 보장 위해 max.in.flight.requests.per.connection 조정 필요
Producer	batch.size	배치 전송 크기 (bytes)	32KB~512KB	여러 메시지를 모아 전송 → 네트워크 효율 ↑	너무 크면 latency ↑
Producer	linger.ms	배치 전 대기 시간 (ms)	5~10ms	메시지 모을 시간 확보 → Throughput ↑	latency ↑ 가능성
Producer	compression.type	메시지 압축 방식	snappy, lz4	데이터 전송량 ↓ → throughput ↑	CPU 사용량 증가
Producer	max.in.flight.requests.per.connection	동시 전송 요청 수	1~5	높은 값으로 throughput ↑	retries와 함께 순서 꼬임 주의
Broker	num.network.threads	네트워크 IO 처리 스레드 수	CPU 수의 절반	요청 처리 성능 향상	CPU 사용량 증가
Broker	num.io.threads	디스크 IO 스레드 수	CPU 수 또는 그 이상	병렬 디스크 처리 가능 → 성능 ↑	context switching 과다 가능성
Broker	socket.send.buffer.bytes socket.receive.buffer.bytes socket.request.max.bytes	소켓 버퍼 크기	128KB ~ 512KB	대용량 전송 효율 ↑	과도하면 메모리 사용량 급증
Broker	log.segment.bytes	로그 세그먼트 최대 크기	1GB 이상	세그먼트 파일 단위 조절 가능	너무 작으면 세그먼트 수 증가로 관리 부담
Broker	log.retention.hours	메시지 보관 기간	업무 요건에 따라	자동 삭제 주기 설정 가능	길면 디스크 공간 부족 가능
Broker	message.max.bytes	단일 메시지 최대 크기	1MB ~ 10MB	대용량 메시지 허용	너무 크면 처리 부담, 작으면 전송 실패
Broker	replica.fetch.max.bytes	리더 → 팔로워 복제 시 최대 크기	10MB ~ 50MB	복제 효율 ↑	너무 크면 디스크 IO 부담, 작으면 지연 발생
Broker	num.partitions	파티션 수	workload 기반 (예: 12, 24 등)	병렬 처리량 증가	파티션 수 많으면 메타데이터/리더 관리 오버헤드 증가
Consumer	fetch.min.bytes	최소 fetch 크기	1KB ~ 50KB	데이터 모아서 가져오기 → 대역폭 효율 ↑	너무 크면 처리 지연 가능성 ↑
Consumer	fetch.max.wait.ms	최대 대기 시간	100 ~ 500ms	데이터 부족 시 대기 시간 제한	너무 길면 응답 지연, 짧으면 polling 증가
Consumer	max.poll.records	poll 당 레코드 수	500 ~ 5000	메시지 처리량 조절 가능	너무 크면 처리 지연, 너무 작으면 poll 과다 발생
Consumer	enable.auto.commit	자동 offset 커밋	false 권장	수동 커밋 가능 → 데이터 제어 ↑	개발자가 커밋 직접 구현해야 함
Consumer	max.partition.fetch.bytes	파티션당 fetch 크기	1MB ~ 10MB	대용량 메시지 처리 가능	너무 작으면 fetch 횟수 ↑
Consumer	session.timeout.ms	컨슈머 장애 탐지 시간	10000 (10초) 이상	빠른 장애 탐지 가능	너무 짧으면 false positive ↑