시작하며... 🚀

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

Latency : 지연 시간으로 불리우며, 카프카가 얼마나 빠르게 하나의 메시지를 빠르게 전달하는지의 메트릭이다.

1. Broker를 통한 Latency 최적화 🚀🚀

Partition 개수 제한

Latency을 줄이기 위해서는 파티션의 개수를 줄이는 방법이 존재합니다. 파티션의 수가 많으면 많을수록 메시지의 Latency를 유발하게 되는데, 파티션에 복사를 위한 시간만큼 Latency가 발생되기 때문입니다.

그렇기 때문에 파티션의 개수를 제한하는 방식으로 Latency를 줄일 수 있습니다.

Broker 수 ⬆︎, partition ⬇︎

그 다음 방법으로는 중개인의 수를 늘리고 파티션 수를 줄이는 방법입니다. 하나의 broker에서 담당하는 partition 수를 줄여서 Replication 하는 데에 소요되는 시간을 최소화시킬 수 있도록 합니다.

num.replica.fetchers

해당 옵션은 Broker의 옵션으로 소스 브로커의 메시지를 복제하는 데 사용되는 스레드 수를 지정하는 것입니다. 이 값을 늘리면 브로커의 I/O 조작에서 병렬 처리가 늘어날 수 있습니다. 때문에 병렬 처리가 늘어나 처리하는데 Latency를 줄일 수 있습니다.

2. Producer를 통한 Latency 최적화 🚀🚀

linger.ms (default 0)

해당 옵션은 prodcuer의 옵션으로 그다음 배치 형태의 메시지를 보내기 전에 추가적인 메시지들을 위해 기다리는 시간을 조절하는 옵션입니다.

0으로 설정하면 데이터를 수집하는 순간 broker로 전송합니다. (지연 없음)

compression.type

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

CPU : 압축을 위한 자원 사용

NW : 압축된 경우 NW bandwidth 사용량 줄어듦
압축 성능에 따라 cpu 사용, nw bandwidth 줄여서 지연 최소화 가능

acks

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

해당 옵션은 0, 1, all or -1 값을 가질 수 있는데, 1로 설정하면 데이터 복제 없이, 원본만 저장되며 결과를 리턴하여 Latency를 줄일 수 있습니다.

3. Consumer를 통한 Latency 최적화 🚀🚀

fetch.min.bytes (default 1)

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

해당 옵션의 파라미터를 1로 설정하면 요청 시 바로 전송할 수 있어 Latency가 없습니다.

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

저작자표시