프로젝트에 Apache Kafka 도입이 오버 엔지니어링인지 판단해보자 (feat. Kafka Benchmark)

캡스톤 아이디어 회의때, 다른 학생이 지역 기반의 소개팅 만남 앱, 커뮤니티 등에서 kafka, redis, kubernetes.. 온갖 화려한 기술들로 점철된 계획서를 들고 왔다.

 

아이디어보단 백엔드 기술에 치중한 계획서를 인공지능 교수님께 내는게 맞는지는 차차하고, 써본적은 없어서 어떤 기술인지는 모르지만 대규모 트래픽 처리에 쓰이니 써보고 싶다고 한다.

 

 

기술은 도구일뿐, 비즈니스가 우선시되어야한다.

 

기술 도입시 가져야할 마음가짐은 '굳이?'라고 생각한다. 기존 방식에서 기교를 통해 해결하는 것도 실력이 아닐까

 

공부하고 도입해보려는 시도는 좋지만.. 남 일인데도 걱정이 앞선다. 이번 포스트를 작성한 이유다.

 

 

본인의 프로젝트에 Apache Kafka 도입을 고민하는 당신. 오버 엔지니어링은 염두해보셨습니까?

 

 

 

이번 연구글을 통해서 Kakfa Cluster의 벤치마크를 통해 최적의 성능 퍼포먼스를 낼 수 있는 설정을 찾을 거다.

 

벤치마크(benchmark)는 특정 시스템이나 소프트웨어의 성능을 평가하기 위해 실행하는 테스트나 측정을 의미한다.

 

결과로 나온 메트릭 지표들이 현재 본인의 프로젝트 요구사항에 맞는지 비교해보면 ‘이정도는 되어야 Kafka 써야하는구나’라는 감이 잡힐 것이다.

 

 

현재 시스템의 요구사항과 잘 들어맞는다면, 벤치마크를 통해 불필요한 설정으로 Broker에 과도한 오버헤드를 주지않고도 최적화된 환경을 구축할 수 있다.

 

Kafka는 분산 환경에서 수행하면서 설치 및 관리가 복잡하고 리소스를 많이 소비하기에, 벤치마크를 통해 비용상의 이점도 명확히 파악할 수 있을 것이다.

 

Kafka 도입이 오버 엔지니어링인지 판단하는 기준

현재 시스템의 요구 사항을 잘 비교해보자

 

(처리량) - 초당 수십만 건 이상의 이벤트를 처리할 트래픽이 있는가?

(운영의 복잡성) - 분산 환경에 따른 인프라 및 운영 복잡도를 감당할 수 있는가?

 

(다중 소비자) - 동일한 메시지를 여러 시스템이 소비해야 하는가?

(내구성) - 데이터 유실을 허용하지 않는 서비스인가?

(확장성) - 트래픽이 향후 10 배 이상 증가할 가능성이 있는가?

 

 

위에서부터 순서대로 가장 중요한 요소라고 생각한다.

 

특히 처리량 부분에서 납득시킬 수 없다면 다른 메시징 큐 도입(Redis, RabbitMQ...)을 고려해보는 것이 좋다.

 

 

성능 측정 목표

Kafka는 각 Broker마다 파티셔닝을 통해 Scale Out하는 분산 처리가 핵심이라 볼 수 있다.

• Broker Cluster를 구성했을 때 Throughput이 얼마나 증가하는지?
• 최대 처리량은 언제 어떤 시점에서 나타나는지?
• 로그 데이터를 기록하는 디스크의 성능에 따라 얼마나 성능이 차이나는지?

 

여러 지표들을 통해 옵션이나 클러스터 설정에 따른 성능 비교가 필요한 순간이 있다.

 

이 비교를 통해 Apache Kafka의 성능이 얼마나 좋은지 벤치마크를 비교하면 기술 스택 도입 시 검토하는 데 좋은 자료로 사용할 수 있을 것이다.

 

특히, 처음 배우는 사람들이 진행 중인 프로젝트에서 Kafka 도입이 오버 엔지니어링인지 확인하는데 도움이 됐으면 좋겠다.

 

 

테스트 환경 준비하기

테스트 도구

Kafka에서는 Benchmark Test를 위해 기본적으로 Performance 측정 도구를 제공한다.

 

Kafka를 설치하면 $KAFKA_HOME/bin에 kafka-producer-perf-test.sh 파일과 kafka-consumer-perf-test.sh 파일을 확인할 수 있는데, 이 파일을 실행하여 Performance Test를 수행할 수 있다.

 

테스트 범위가 Producer-Broker 구간이므로, kafka-producer-perf-test.sh 쉘 스크립트를 이용하여 테스트를 수행하였다.

 

주요 옵션 정리

--topic	테스트할 토픽 이름
--record-size	각 메시지 크기 (바이트)
--num-records	생성할 메시지 개수
--throughput	초당 메시지 처리량 (-1: 최대)
--producer-props	프로듀서 설정값 추가
--producer.config	프로듀서 설정 파일 경로

 

 

나는 Docker 위에서 Kafka를 돌리고 있다.

 

*.sh 파일들은 컨테이너 내부의 /opt/bitnami/kafka/bin/ 혹은 /opt/kafka/bin/ 디렉토리에서 찾을 수 있다.

ls /opt/bitnami/kafka/bin/
ls /opt/kafka/bin/

 

bitnami의 kafka 같은 경우는 위의 /opt/bitnami/kafka/bin/에서 찾을 수 있다.

 

 

 

 

테스트 시나리오 및 수행 방법

• 메시지 개수: 500개
• 처리량: 초당 10개씩 발송
• 메시지 크기: 1024바이트

 

예시 명령문

kafka-producer-perf-test.sh \\
--topic perf-topic-1 \\
--record-size 1024 \\
--num-records 500 \\
--producer-props bootstrap.servers={kafka ip:port} \\
--producer.config /usr/local/kafka/config/producer.properties \\
--throughput 10

 

예시 실행 결과

1000 records sent, 220.507166 records/sec (210.29 MB/sec), 139.82 ms avg latency, 320.00 ms max latency, 139 ms 50th, 170 ms 95th, 180 ms 99th, 320 ms 99.9th.

 

몇 건의 메시지를 보냈는지나 처리량이 얼마인지 대략적으로 확인할 수 있다.

 

 

테스트 환경 구성

• 클러스터 구조 

• Kafka 버전: bitnami/kafka:3.7.0, KRaft 모드
• 브로커 개수: 3개 (kafka-0, kafka-1, kafka-2)
• 컨트롤러 겸 브로커 노드: controller 및 broker 역할 수행
• Docker 네트워크 내에서 동작 (docker-compose.yaml)

 

 

• 가상 컨테이너의 리소스 사양

Docker 환경에서 진행하므로, Docker 컨테이너에 할당한 메모리나 디스크 자원에 맞추어 성능을 측정한다.

 

따라서 개발 환경의 물리적 하드웨어 자원과는 격리된 환경의 사양을 직접 확인해보자.

docker stats

 

 

 

 

•  

벤치마크 진행

프로젝트에서 도입하는 여러 압축 기술들 중에서 압축률보다는 빠른 성능이 중요하기 때문에 gzip → snappy 를 기본 압축으로 적용했다.

 

매칭이나 전적 결과는 스트리밍 과정에서 결코 유실되어선 안되는 비즈니스 데이터이다. (acks=all)

 

top, iostat 명령어를 활용하여 시스템 자원(CPU, 메모리, 디스크 I/O) 사용량을 모니터링한다.

 

Kafka에서 제공하는 여러 옵션을 선택하기 위한 성능 비교

• 배치 크기: acks=all을 사용할 경우, 배치 크기를 최적화해야 성능이 향상될 수 있음
• 압축 방식: compression.type 옵션을 추가하여 다양한 압축 방식 도입
• 로그 세그먼트 크기: log.segment.bytes 설정을 통해 세그먼트 크기를 변경
• 컨슈머 성능 최적화: fetch.min.bytes, fetch.max.bytes, max.poll.records 등 더 효율적인 Consumer 성능 테스트

 

테스트에 실제 사용한 상세한 코드는 생략하겠다.

 

 

벤치마크 결과 분석 및 결과

Kafka의 성능은 하드웨어 스펙, 디스크 I/O 성능, 프로듀서 개수 및 설정에 따라 달라질 수 있다. 따라서 시스템에 적합한 최적의 설정을 찾는 것이 중요하다.

 

준비한 벤치마크를 통해 실제 트래픽 요구사항과 비교하여 Kafka 도입 여부를 신중하게 검토해보자.

 

 

 

replica=3, records=100,000, record_size=512로 진행했다.

 

 

• Broker 수가 3개일때는 대체적으로 Partition 수가 9일때 가장 성능이 뛰어나다고 볼 수 있다.
• 압축률이 높은 Gzip을 적용했을때 Producer나 Consumer의 처리량이 제일 낮았다.
• acks=1가 ISR만큼 동기화시킬때(acks=all)보다 성능이 좋다.

 

 

kafka-performance-test 시각화에 대한 코드는 아래에서 확인할 수 있다.

 

kakfa-performance-test.ipynb

 

 

그냥 그렇구나하고 넘어가지말고 수치와 단위를 잘 보고, 프로젝트와 유의미한 비교가 가능한지 잘 확인해보길 바란다.

 

 

 

테스트 진행 과정에서 다음과 같이 미쳐날뛰고 컴퓨터는 비명을 지른다.

 

 

 

 

다같이 오버 엔지니어링을 막아보자