'카프카 성능'에 해당되는 글 1건

  1. 2019.01.16 [카프카(Kafka)] 성능 관련 고찰 (2)


사내 시스템의 임시버퍼 용도로 Redis를 도입하여 성능 테스트를 진행하던 중, 버퍼 용량 이슈로 인하여 Redis와 Kafka를 비교하게 되었다. 

우선 결론적으로는 Redis(List)와 Kafka 사용 시 성능 차이는 거의 없었고, Kafka가 보관 용량에 대해선 유리하였다.


이번 주제에서는 Kafka 성능에 대한 정리이므로 Redis & Kafka 비교는 나중에 진행하기로 한다. 

궁금증

Kafka는 대용량 메시지 처리 성능이 좋다고 조금만 리서치 해보면 알 수 있다. 그러면.... 

처리량이 얼마나 될까? 

HDD와 SSD는 차이가 발생할까? 

Producer와 Consumer 수에 따라서 성능 차이가 날까?  

여러 Consumer Group이 같은 토픽을 조회해도 성능 차이가 없다고 하던데 과연 그럴까?

이러한 궁금증이 생겼다.


가장 궁금한 부분은 HDD와 SSD 성능 차이였다. 

어떤 블로그에서는 HDD보다 SSD가 최대 2.7배 성능이 높다고 하고, 어떤 학술 논문집에서는 차이가 거의 없다고 한다.

이번 성능 테스트를 진행하면서 알아보려 한다.


테스트 케이스

  • 하드웨어 스펙 차이에 따른 성능 비교 (CPU, Memory, SSD, HDD)
  • 브로커 증가에 따른 성능 비교
  • Producer 및 Consumer 수에 따른 성능 비교
  • Consumer Group 수에 따른 성능 비교

테스트 환경, 스펙, 설정

테스트 환경 구성

  • Zookpeer 3노드
  • Kafka 6노드
  • Test 장비 4노드

Zookeeper 스펙

클라우드

Azure 표준 F2s

CPU

2Core 

Memory 

4GB 

스토리지 

SSD 32GB(120 iops)

 Bandwidth

 1.5GbE

OS

CentOS Linux release 7.5.1804

Java

java(TM) SE 10.0.1

버전

kafka_2.11-2.0.0

Kafka 스펙

클라우드

Azure 표준 F4s

Azure 표준 F8s

CPU

4Core 

 8Core

Memory 

8GB 

16GB 

스토리지 

HDD 1024GB(500 iops) VS SSD 1024GB(5000 ipos)

Bandwidth

 10GbE

OS

CentOS Linux release 7.5.1804

Java

java(TM) SE 10.0.1

버전

kafka_2.11-2.0.0

 Heap Memory

 Xmx6G -Xms6G

 Xmx10G -Xms10G

토픽 및 파티션 구성

하나의 물리적 노드 당 하나의 파티션으로 정의한다. 

예를 들어 5개의 노드를 사용하는 토픽은 5개의 파티션을 가지고 있다. 

추가로 정확한 throughput을 측정하기 위해 복제는 사용하지 않았다. 


테스트 툴 선택

Kafka는 자체적으로 테스트 툴을 제공하고 있다.

응답시간을 지원하지 않으므로 테스트 평가 기준은 초당 처리량(MB/sec)으로 정의한다. 

아래와 같이 producer, consumer 별로 테스트를 진행하였다. 

 구분

테스트 명령어 

설명 

producer 

 ./kafka_2.11-2.0.0/bin/kafka-producer-perf-test.sh \

--topic test \

--record-size 1000 \

--num-records 20000000 \

--producer-props \

bootstrap.servers=10.10.20.14:9092...... \

--throughput 1000000

topic : 토픽이름

record-size : 테스트 레코드 사이즈(byte) 

num-records : 생성할 메시지수

producer-prop : 프로듀서 옵션 처리

bootstrap.servers : 브로커 리스트

throughput : 최대 메시지 처리량 제한(초당 몇개의 메시지)

 consumer

 ./kafka_2.11-2.0.0/bin/kafka-consumer-perf-test.sh \

--topic test \

--show-detailed-stats \

--group test_group \

--broker-list 10.10.20.14:9092...... \

--reporting-interval 500 \

--messages 1000000

topic : 토픽이름

messages : 소비할 메시지 개수

show-detailed-stats : 통계 지표 리포트

group : consumer group 

broker-list : 브로커 리스트

reporting-interval : 리포팅 간격

kafka 설정

6노드 모두 아래와 같이 동일하게 설정하였다.


...

num.network.threads=3

num.io.threads=8

socket.send.buffer.bytes=102400

socket.receive.buffer.bytes=102400

socket.request.max.bytes=104857600


num.partitions=1 #기본 파티션 개수

num.recovery.threads.per.data.dir=1

offsets.topic.replication.factor=1 #기본 복제 개수

transaction.state.log.replication.factor=1 

transaction.state.log.min.isr=1


log.retention.hours=168 #토픽 보관시간 

log.segment.bytes=1073741824 

log.retention.check.interval.ms=300000




테스트 결과

하드웨어 스펙 차이에 따른 성능 비교

Producer 테스트 (Test 토픽 6 파티션 기준)

  • 1개의 Producer일 경우 스토리지(SSD, HDD) 및 하드웨어 스펙(F4s, F8s) 상관없이 동일한 처리량을 보여준다.
  • F4s 스펙에서는 n개의 Producer가 늘어나면,  처리량은 1/n로 나눠진다. (전체 처리량 같음)
  • F8s 스펙에서는 n개의 Producer가 늘어나더라도 처리량은 1/n 나뉘지 않고 더 높은 성능을 보여준다. (전체 처리량 많아짐)

Comsumer 테스트 (Test 토픽 4 파티션 기준)

  • 1개의 Consumer일 경우 SSD가 HDD보다 약 2.4배 빠르다.
  • F4s , F8s 스펙에서는 성능 차이가 크지 않았다.
  • n개의 Consumer가 늘어나면, SSD 환경 처리량은 1/n으로 나뉘지 않고 더 높은 성능을 보여준다. (전체 처리량 많아짐)
  • n개의 Consumer가 늘어날 경우 HDD 환경 처리량은 1/n으로 나눠진다. (전체 처리량 같음)

하드웨어 사용률

1개의 Producer, Consumer 기준으로 하드웨어 사용률을 확인해 보았다.

Producer는 사용률이 높고, Consumer는 낮다.

 구분

하드웨어 사용률 (HTOP) 

Producer 

 



Consumer

 



결론

 구분

결과 

producer 

Producer가 늘어날수록 하드웨어 사용량이 많아 처리량은 줄어든다. 하드웨어 스펙을 올리면 더 높은 성능을 보여준다.

SSD vs HDD 비교에서 하드웨어 스펙이 낮으면 차이가 별로 없고, 높으면 차이가 난다.(측정 오류 발생 소지)

 consumer

Consumer가 늘어날수록 전체 처리량의 차이는 SSD 많아지고 HDD는 거의 없다..

SSD와 HDD의 처리량은 약2.3배 차이가 난다.

SSD에 비해서 성능 차이가 있을 뿐이지 HDD도 성능이 엄청 좋다. 
HDD 기준 전체처리량은 Producer 초당 10~12만 메시지(1kb)를 적재, Consumer는 초당 22~24만 메시지를 소비한다. 

브로커 수에 따른 성능 비교

테스트 환경은 Azure F4s, SSD에서 진행하고, 브로커가 1 증가하면 파티션도 1 증가한다. 
예를 들어 4 브로커면 테스트 토픽의 4개의 파티션이라고 생각하면 된다. 

Producer 테스트

  • 브로커가 늘어나면 Producer 처리량도 같이 증가
  • 4 브로커 이상에서는 처리량 변화가 없음

Consumer 테스트 (같은 Consumer Group 기준)

  • 브로커가 증가하면 Consumer 처리량도 같이 증가

브로커 수에 따른 처리량 그래프

브로커 수에 따른 결론

브로커가 늘어나면 Producer나 Consumer 모두 처리량이 같이 증가한다. 


브로커 1노드 기준 최대  처리량

스토리지 타입

 1 Producer

 1 Consumer

 hdd

 쓰기 45~52MB/sec

(55649 records/sec)

 읽기 250~260MB/sec

(262208 records/sec)

 ssd

 쓰기 100~110MB/sec

(117094 records/sec)

 읽기 250~260MB/sec

(264654 records/sec)

여러 브로커 기준 최대  처리량

스토리지 타입

 1 Producer

 1 Consumer

 hdd

 쓰기 190~200MB/sec

(206745 records/sec)

 읽기 600~700MB/sec

 ssd

 쓰기 195~200MB/sec

(206582 records/sec)

 읽기 600~700MB/sec




Producer 및 Consumer 수에 따른 성능 비교

이전 테스트의 결과를 보면 확인할 수 있다. 

Producer 및 Consumer 수에 따른 결론

하드웨어 스펙이 좋으면 Producer, Consumer 수가 증가할수록 처리량은 늘어난다. 


Consumer Group 수에 따른 성능 비교

2 broker 기준 (Test 토픽 2파티션)

Consumer Group 수에 따른 결론

컨슈머 그룹이 늘어나도 성능 저하가 없다.




결론

브로커 1노드 기준으로 ssd hdd보다 처리량이 2 높으나 hdd Raid 묶으면 ssd 비슷한 성능이 가능하다. (비용 측면 검토 필요)
Producer와 Consumer를 같이 사용하기 때문에 처리량에 따른 하드웨어 스펙을 검토되어야  한다. 

프로덕션 환경 권장사양






Posted by 사용자 피랑이

댓글을 달아 주세요

  1. AndersonChoi 2019.08.30 16:44 신고  댓글주소  수정/삭제  댓글쓰기

    직접 node를 띄워서 테스트하시느라고 비용(시간, 돈)이 많이 들었을거 같아요.
    소중한 정보 공유주셔서 감사합니다.

  2. Lucsa Lee 2020.05.26 11:41  댓글주소  수정/삭제  댓글쓰기

    고생 많이 하셨습니다. Kafka 공부하는데 큰 도움이 되었습니다. 감사합니다.