시작하며... 🚀

이번에는 4개의 성능 목표 중 첫 번째로 Throughput에 대해서 어떤 파라미터를 튜닝하는지 알아보겠습니다. 프로듀서와 컨슈머의 option 중 어떤 option이 Throughput에 영향을 주는지 알아보며 어떻게 이 옵션의 파라미터가 영향을 주며, 어떻게 설정해야 하는지를 보도록 하겠습니다.

Throughput : 처리량으로 불리우며, 카프카가 얼마나 많은 데이터를 처리할 수 있는지에 대한 메트릭이다.

1. Producer를 통한 Throughput 최대화 🚀🚀

Partition

Throughput를 최적화하는 방법은 Partition 수를 증가시키는 방법이 대표적입니다.
Partition의 수를 증가시키면, 분산 효과를 가져오며 분산처리를 하면 할 수 록 더 많은 데이터를 처리할 수 있어 Throughput를 증가시킬 수 있습니다.

Batch size

해당 옵션은 prodcuer의 옵션으로 Batch size는 같은 파티션으로 보내는 여러 데이터를 함께 배치로 보내려고 하는 양을 조절하는 옵션입니다.

이 값을 증가시키면 한번에 많은 양을 보내며, 전송 횟수도 줄어들어 서버 부하를 감소시킬 수 있습니다.

linger.ms

해당 옵션은 prodcuer의 옵션으로 그 다음 배치 형태의 메시지를 보내기 전에 추가적인 메시지들을 위해 기다리는 시간을 조절하는 옵션입니다. 이 옵션은 batch.size가 꽉 찰 수 있도록 시간을 설정하면 Throughput 최적화에 도움이 됩니다.

그 이유는 한번에 보내는 양에 따라서 전송 횟수도 줄일 수 있으며, 서버의 부하를 줄일 수 있다 했으니 batch.size가 꽉 찰 수 있도록 설정하면 당연히 유리할 수 있는 것입니다.

compression.type

해당 옵션은 prodcuer의 옵션으로 데이터를 압축해서 보낼 수 있는데, 어떤 타입으로 압출할지를 정할 수 있는 옵션입니다.

옵션으로는 none, gzip, snappy, lz4 같은 다양한 포맷이 존재하는데 이 알고리즘별로 Throughput에 영향을 줍니다. 그래서 데이터의 유형에 따라서 compression.type를 선택해야 합니다.

acks

해당 옵션은 prodcuer의 옵션으로 프로듀서가 카프카 토픽의 리더에게 메시지를 보낸 후 요청을 완료하기 전 ack의 수입니다.

해당 옵션은 0, 1, all or -1 값을 가질 수 있는데, 이 값에 따라서 프로듀서가 다음 메시지를 전달하는 시간을 결정할 수 있으므로 Throughput에 영향을 줄 수 있습니다.

retries

해당 옵션은 prodcuer의 옵션으로 일시적인 오류로 인해 전송에 실패한 데이터를 다시 보내는 횟수입니다.

이 옵션에 따라서 메시지가 전송실패할때 다시 시도하는 별도의 작업이 추가되기 때문에 처리량에 영향을 줄 수 있습니다.

buffer.memory

해당 옵션은 prodcuer의 옵션으로 프로듀서가 카프카 서버로 데이터를 보내기 위해 잠시 대기할 수 있는 전체 메모리 바이트입니다.

다시 말해 Producer가 보내지 못한 메시지를 보관할 메모리의 크기로 만약 메모리가 full이 되면, 다른 메시지 전송을 blocking 하게 됩니다. 또한 memory 여유가 생기거나, max.block.ms를 초과하면 전송할 수 있습니다.

파티션이 많지 않으면, 조정할 필요가 없지만 파티션이 많다면 메모리를 늘려 blocking 없이 더 많은 데이터가 전송되도록 설정할 필요가 있습니다.

2. Consumer를 통한 Throughput 최대화 🚀🚀

fetch.min.bytes

해당 옵션은 Consumer의 옵션으로 한번에 가져올 수 있는 최소 데이터 사이즈입니다. 만약 지정한 사이즈보다 작은 경우, 데이터가 누적될 때까지 기다립니다.

이 옵션의 값을 증가시키면 브로커로 요청하는 횟수가 감소하며, 브로커의 리소스 사용을 절감합니다. 또한 프로듀서에서 batch.size를 증가하는 것과 동일한 효과를 보입니다.

fetch.max.wait.ms

해당 옵션은 Consumer의 옵션으로 consumer에서 데이터를 가져오는 최소 시간으로 새로운 데이터가 입력되어도, 해당 시간 이전에는 가져가지 않습니다.

이 옵션을 통해서 내부적으로 consumer가 fetch 요청을 해도, 브로커가 보내지 않습니다.

Consumer group 활용

이번에는 컨슈머 그룹을 활용해서 카프카 브로커 큐에 있는 데이터를 바로바로 처리하며, 여러 개의 컨슈머가 처리할 수 있어서 처리량이 높아질 수 있습니다.

3. Throughput 최대화 설정 가이드

Producer

batch.size: 증가 (100,000 – 200,000) (default 16384)
linger.ms: 증가 (10 – 100) (default 0)
compression.type=lz4 (default none)
acks=1 (default 1)
retries=0 (default 0)
buffer.memory: partition이 많다면 증가 (default 33,554,432)

Consumer

fetch.min.bytes : ~100,000 까지 증가 (default 1)

REFERENCE

[1]. https://devidea.tistory.com/90
[2]. https://firststep-de.tistory.com/35
[3]. https://www.ibm.com/docs/ko/oala/1.3.5?topic=SSPFMY_1.3.5/com.ibm.scala.doc/config/iwa_cnf_scldc_cnf_kfk_t.html
[4]. https://www.popit.kr/kafka-%EC%9A%B4%EC%98%81%EC%9E%90%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-producer-acks/
[5]. https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=freepsw&logNo=221028179182
[6]. https://www.confluent.io/blog/optimizing-apache-kafka-deployment/

728x90

저작자표시