일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 알림무시
- Slack Rate Limit
- Tuckman
- 파이어베이스
- FCM
- 슬랙
- Rate Limit
- 카프카 성능
- Slack Limit
- 팀 발달 모델
- 카프카
- 해킹
- 웹보안
- 스카우터
- 스케일 큐브
- bag of words
- 머신러닝
- Scale Cube
- kafka
- firebase
- n-gram
- 자연어처리 #konlpy #형태소분석
- Spark
- 슬랙 파일업로드 제한
- Slack File Upload
- 슬랙 파일업로드
- 이미지 푸시
- Core/Context
- 코어/컨텍스트
- Scouter
- Today
- Total
플랫폼 개발팀 기술 블로그
[카프카(Kafka)] 성능 관련 고찰 본문
사내 시스템의 임시버퍼 용도로 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배 차이가 난다. |
브로커 수에 따른 성능 비교
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 수가 증가할수록 처리량은 늘어난다.
하드웨어 스펙이 좋으면 Producer, Consumer 수가 증가할수록 처리량은 늘어난다.
Consumer Group 수에 따른 성능 비교
Consumer Group 수에 따른 결론
컨슈머 그룹이 늘어나도 성능 저하가 없다.
컨슈머 그룹이 늘어나도 성능 저하가 없다.
결론
프로덕션 환경 권장사양
'Kafka' 카테고리의 다른 글
[카프카(Kafka) 어플리케이션 제작 ] #2. 컨슈머 (0) | 2019.03.21 |
---|---|
[카프카(Kafka) 어플리케이션 제작 ] #1. 프로듀서 (2) | 2019.03.07 |
카프카(Kafka) 설치 및 클러스터 구성 (3) | 2019.01.24 |
카프카(Kafka)의 이해 (1) | 2019.01.17 |