Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Apache kafka performance(throughput) - without data loss and guaranteeing data order

2,393 views

Published on

Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.

Published in: Software

Apache kafka performance(throughput) - without data loss and guaranteeing data order

  1. 1. Apache Kafka Throughput Benchmark 1 2017.08 freepsw 데이터 전송순서를 유지하면서, 유실을 최소화 하는 환경에서…
  2. 2. 2 우리가 원하는 Apache Kafka의 역할은? 데이터 전송순서를 유지하면서, 절대로 데이터를 유실하면 안된다! 데이터 전송순서를 유지하려면? 데이터 유실을 방지하려면? • 반드시 전송이 성공 한 후에 다음 데이터 전송 à sync 방식 • Topic을 분산하면 안됨 à partition 1개 • Topic 당 1개의 Producer만 할당 • 복사본을 최대한 증가 à replica 3개 • 모든 복사본까지 저장된 후 다음 메시지 처리 à acks = -1 Throughput 최대화 Durability 보장
  3. 3. 3 요구하는 환경을 위한 Apache Kafka 설정은? 순서보장을 위한 producer 설정과, 유실방지를 위한 broker 설정 변경 Producer 설정 Apache Kafka 설정 • 데이터 전송 순서 보장 • Sync 방식 전송 (thread 1개) • 데이터 유실 방지 • Acks : -1 (모든 복제본 저장 후, 다음 메시지 전송) • Retris : 최대한 많은 재시도 (메시지 유실 없도록) • 처리량 향상 • Compression : 압축알고리즘 최적화 (gzip, lz4, snappy) • batch_size : 1회 전송에 보내는 size • Topic 생성시 설정 • replication-factor : 3 (원본 포함 3개) • partitions : 1 (데이터가 분산되지 않도록 설정, 순서보장) • Kafka Broker 설정 • min.insync.replicas : 2 • 최소 2개의 복사본 있어야, 서비스 가능 • 가용성을 높이려면 1로 설정 • 데이터 유실을 최소화 하려면 높게 설정
  4. 4. 4 테스트 환경을 구성하자 Kafka Cluster로 데이터를 전송 및 수신하고, 성능지표를 수집하여 모니터링 • Topic은 partition 1로 구성하여 2번 Broker만 생성하도록 설정 • 나머지 broker는 replication을 위한 용도로 활용 • 3대 서버 • CPU : Dual Intel Xeon E5-2650 v4 (24 Cores, 2.20 GHz) • MEM : 64 GB • DISK : 2 TB, MegaRAID SAS 9361-8i, 12Gb/s • Node 1 • Kafka Broker1, Zookeeper1 • Producer • ELK Stack (logstash, kibana, elasticsearch) • Node 2 (Topic 생성) • Kafka Broker2, Zookeeper2 • Node 3 • Kafka Broker3, Zookeeper3 • Consumer Producer (filebeat) 테스트 환경 구성 테스트 서버 스펙 Kafka Cluster Consumer (logstash) Monitoring (ELK Stack) JMX Metric 수집 Broker 1 Broker 2 Broker 3 • Message Size : 3 KB (3,000 byte) • Apache Kafka 0.11.0
  5. 5. 5 [성능비교 1] 1개 Producer로 전송 (acks=1 vs acks=-1) 원본만 저장하는 방식이 1,000건 빠른걸 보면, 복제본에 많은 시간이 소요되지 않음 원본만 저장후 처리하는 방식(acks 1) vs 모든 복제본 저장후 처리 방식(acks -1) (100만건 데이터를 전송후 평균처리속도 계산) 측정 항목 측정 값 (acks = -1) 측정 값 (acks = 1) 비고 처리 건수 4,600 건 / sec 5,600 건 / sec - 평균 초당 처리 건수 처리 용량 90 KB / sec 100 KB / sec - 기본 압축 (gzip) 적용 전송 파일 비교(건수) 동일 동일 - Consumer에서 수신한 파일과 동일 전송 파일 비교(순서) 동일 동일 - Consumer에서 수신한 파일과 동일 - Diff Command 로 확인 자원 사용량 (CPU) 평균 1 core 평균 1 core 자원 사용량 (Memory) 200 ~ 700 MB 200 ~ 700 MB - Heap Memory 2G 이하로 설정
  6. 6. 6 [성능비교 2] Producer 개수를 증가 (4, 10 개) Producer를 증가시키면 처리성능도 함께 증가함 (4,600 à 29,000건) (100만건 데이터를 전송 후 평균처리속도 계산) 측정 항목 측정 값 (acks = -1, producer = 4) 측정 값 (acks = -1, producer = 10) 비고 처리 건수 38,000 건 / sec 58,000 건 / sec - 평균 초당 처리 건수 처리 용량 280 KB / sec 370 KB / sec - gzip 알고리즘 적용 전송 파일 비교(건수) 동일 동일 - Consumer에서 수신한 파일과 동일 전송 파일 비교(순서) 동일 동일 - Consumer에서 수신한 파일과 동일 - Diff Command 로 확인 자원 사용량 (CPU) 평균 3 core 평균 3 core 자원 사용량 (Memory) 200 ~ 700 MB 200 ~ 700 MB - CPU 사용률이 증가하는 것을 볼 때, Kafka Broker가 더 많은 메시지를 처리가능 - 즉, Producer가 모든 복제본이 완료되기까지 대기하는 시간으로 인하여, 많은 데이터를 전송하지 못함.
  7. 7. 7 [성능비교 3] 압축 알고리즘 변경 (gzip, snappy, lz4) 압축성능 및 처리성능 관점에서 lz4가 가장 효과적임 (100만건 데이터를 전송 후 평균처리속도 계산) - 처리 성능만을 고려한다면, lz4 또는 snappy 알고리즘을 선택해야 하지만, - Snappy 알고리즘은 압축률이 좋지 않아, lz4를 사용하는 것이 효과적 측정 항목 측정 값 (compression = lz4) 측정 값 (compression = snappy) 측정 값 (compression = gzip) 측정 값 (compression = none) 비고 처리 건수 88,000 건 / sec 90,000 건 / sec 57,000 건 / sec 33,000 건 / sec - 처리량은 lz4, snappy 가 높음 처리 용량 1,790 KB / sec 12,432 KB / sec 622 KB / sec 96,593 KB / sec - 압축률은 gzip이 가장 높음 전송 파일 비교(건수) 동일 동일 동일 동일 전송 파일 비교(순서) 동일 동일 동일 동일 자원 사용량 (CPU) 평균 0.7 core 평균 1.2 core 평균 1 core 평균 1.3 core - Lz4가 cpu 사용률이 가장 낮음 - 압축을 하지 않은 경우, 더 많은 cpu time을 소요함. 자원 사용량 (Memory) 200 ~ 700 MB 200 ~ 700 MB 200 ~ 700 MB 200 ~ 700 MB
  8. 8. 8 [성능비교 3] 압축 알고리즘 변경 (gzip, snappy, lz4) 처리성능이 높으면서 CPU 사용량이 가장 적은 것이 lz4 압축 LZ4 snappy gzip 압축없음 [초당 처리 건수] LZ4 snappy gzip 압축없음 [초당 데이터 처리량] [CPU 사용량] snappy gzip 압축없음LZ4
  9. 9. 9 테스트에서 사용한 Apache kafka 설정 구분 설정 파라미터 (Default) 내용 비고 Broker replication.factor (1) - Topic 의 유실 방지를 위해 원본을 포함한 복제본 개수 (1 이상) - 많은 경우 유실방지 - 적은 경우 성능향상 min.insync.replicas (1) - Broker 서버의 장애를 허용하는 최소 서버 개수 - 2인 경우 2대 까지는 서비스 가능 (1대만 남은 경수 서비스 불가) - 많은 경우 데이터 유실방지 - 적은 경우 가용성 향상 message.max.bytes (1,000,000) - 한번의 요청 batch에서 전송 가능한 최대 bytes - Message가 큰 경우(이미지 binary 등) 값을 증가 unclean.leader.election.enable (false) - 정상적으로 원본을 복제하지 못한 broker가 서비스를 할 수 있는지 여부 - True : 가능 (유실 가능) - False : 불가(가용성 저하) Producer acks (1) - 0 : 원본 저장 확인 없이 응답 - 1 : 원본 저장 확인 후 응답 - -1 : 복제본 저장 완료 후 응답(가장 느림) - 데이터 유실방지를 위해 -1 옵션 사용 max_retries (3) - 데이터 전송 실패시 재전송 회수 - 네트워크 및 시스템이 불안전한 환경에서는 높게 설정 batch.size (16,384) - 한번에 전송할 데이터의 크기 (byte) - 테스트를 위해 사용한 Filebeat에서는 bulk_max_size를 이용하여 한번에 전송할 메시지 건수로 지정 - 많은 경우 전송효율 높음 - 적을 경우 전송효율 낮음 compression.type (Gzip) - 전송할 데이터를 압출할 알고리즘 지정 (gzip, lz4, snappy, none) - Lz4 알고리즘이 효율적 Consumer enable_auto_commit (true) - 데이터를 수신한 뒤 자동으로 Commit할 것인지 지정 - 유실방지 위해 False로 설정하고, Biz 로직 동작후 직접 commit auto_commit_interval_ms (5,000) - Auto commit이 true인 경우, commit할 주기를 지정 - 많은 경우 처리 성능 높음 - 적은 경우 처리성능 낮음 max.partition.fetch.bytes (1,000,000) - Broker의 message.max.bytes 설정이 변경될 경우, 최대 batch size를 가져올 수 있도록 함께 변경
  10. 10. 10 Apache Kafka 성능 개선을 위한 하드웨어 고려사항 고려사항 주요 설명 CPU CORE • 처리량이 CPU에 많은 영향을 받지는 않지만, multi core를 권장 • 병행처리를 위해서는 빠른 core보다는 많은 core를 권장 Memory • CPU보다는 MEMORY가 성능에 미치는 영향이 더 크다. • 왜냐하면, 많은 데이터가 서버로 유입되고 관리되면서 발생하는 데이터를 page cache를 이용 하여 처리하기 위함. DISK • DISK의 처리성능이 중요함. (SATA 7200 rpm 기준) • 병렬 Disk I/O를 위해 Disk의 개수가 많은 것이 좋음 • http://docs.confluent.io/1.0.1/kafka/deployment.html OS 설정 • file descriptors 의 개수를 사전에 충분히 증가시켜야 함 (Topic의 수가 많아지고, connection하는 producer, consumer가 증가할 경우) • socket buffer size를 최대화 하여, 한번에 처리할 수 있는 처리량을 증가시킨다. • OS 최적화 : https://kafka.apache.org/documentation.html#hwandos 참고
  11. 11. 11 테스트 결과 정리 초당 처리 건수는 Topic당 최대 90,00건을 처리하며, 유실없이 데이터 순서보장 초당 90,000 건 이상 (1개 Topic, 10개 producer 동시전송) 데이터 유실없이, 전송순서 보장 [ 고려사항 ] • 전체 처리량 = 90,000건 * TOPIC 수 • Producer용 서버의 자원을 추가하면, 더 많은 데이터 처리 가능 • 압축 알고리즘 선택에 따라서 성능 및 전송효율 향상 가 능 (lz4 권장) [ 고려사항 ] • Network 장애로 인하여 특정 상황에서 데이터 중복 가 능 (유실 없음) • 중복 제거를 위하여, Producer/Consumer API 활용하여 로직구현 필요
  12. 12. 12 END

×