Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안

Apache Kafka 성능 최적화
(Metrics & Configuration Tunning)
2018.11
freepsw
성능 모니터링을 위한 Metric 이해 및 Configuration 튜닝 방안

2
어떤 성능 목표를 설정할 것인가?
서비스의 특징에 따른 성능목표를 정한 후 파라미터 튜닝 필요
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
보통 아래 4가지를 목표로 설정하며, 각 항목은 상호 trade-off 관계
모든 목표를 동시에 모두 최적화 할 수 없다.

3
4가지 목표에 따른 특징
각 특징에 따른 요건
• Kafka 특성상 많은 데이터를 빠르게 쓰는것은 문제가 없음Throughput
• 하나의 메세지를 가능한 빠르게 전달 (실시간 채팅 서비스)
• (producer à broker à consumer)
Latency
• 메세지의 유실을 최소화
• Event 기반 microservice 또는 데이터 수집 파이프라인
Durability
• Kafka 서버의 다운타임 최소화
• 장애시 가장 빠르게 복구 해야 하는 서비스
Availability

Kafka 모니터링에
필요한 Metric 이해
(System, Broker, Producer, Consumer)

5
Kafka Monitoring – Kafka Server is running?
Kafka server가 정상 동작하고 있는지 확인
https://blog.serverdensity.com/how-to-monitor-kafka/
> ps -ef | grep "kafka.Kafka"

6
Kafka Monitoring – System Metrics
Kafka server에서 사용하고 있는 자원 현황 및 이상치 감지
• Open File Handles, CPU, Network I/O

7
Kafka Monitoring – System Metrics (Swap usage)
Kafka Server에서 Swap이 발생하면, Disk I/O가 발생하여 성능에 영향
Swap이 발생하는 원인
• Kafka 구동시 설정한 Heap Memory를 초과하는 경우
에 데이터를 swap 공간으로 복사하게 됨. (프로그램이
중지되지 않도록 하는 역할)
• 이 부분은 Kafka에서 저장하는 데이터를 의미하는 것이
아니라, Kafka의 내부 프로세스에서 사용하는 메모리를
의미함.
• 또한 한번 swap공간으로 이동하면, 다시 메모리로 돌아
오게 할 수 없다. à 성능 저하 유발
• > sysctl vm.swappiness
• vm.swappiness = 60 à 디폴트 값
Swap 발생 조건 변경
• vm.swappiness
• 메모리에서 swap으로 이동을 언제 할지 결정
• vm.swappiness = 10 à 메모리 사용률 90% 이상일 때
• vm.swappiness = 60 à 메모리 사용률 40% 이상일 때
• Kafka 성능을 극대화 하려면,
• vm.swappiness = 0 à 메모리에서만 처리하도록
• 설정

8
Kafka Monitoring – System Metrics (Swap usage)
Kafka Server에서 Swap이 발생하면, Disk I/O가 발생하여 성능에 영향
Disk 사용률
• 아래 명령어를 이용해 kafka가 사용하는 disk 사용률이
85%가 넘는지 확인한다.
• > df –h

9
Kafka Monitoring – Kafka Broker Metrics
Kafka Server 동작중에 발생하는 metrics 정보들
Metric Comments Alert
UnderReplicatedPartitions
kafka.server: type=ReplicaManager
– 복제가 안된 partition의 개수
1개 이상
OfflinePartitionsCount
kafka.controller: type=KafkaController
- Leader가 없는 partition의 갯수 à partition을 읽거나, 쓰기가 불가능
1개 이상
ActiveControllerCount
kafka.controller: type=KafkaController
- 현재 동작중인 Broker의 개수 (반드시 1개만 구동되어 있어야 함)
1개가 아닌 경우
MessagesInPerSec
kafka.server: type=BrokerTopicMetrics
– 초당 유입되는 메세지 count (많을 수록 처리성능이 높음)
None
BytesInPerSec / BytesOutPe
rSec
kafka.server: type=BrokerTopicMetrics
– 초당 유입 & 유출 되는 byte (많을 수록 처리성능이 높음)
Incoming/outgoing bytes per second.
None

10
RequestsPerSec
kafka.network: type=RequestMetrics
request={Produce|FetchConsumer|FetchFollower}
- 초당 요청 건수
None
TotalTimeMs
kafka.network: type=RequestMetrics
request={Produce|FetchConsumer|FetchFollower}
- 하나의 요청을 처리하는데 소요된 전체 시간
- 구간별로 분할하여 시간 측정 가능
- QueueTimeMs, LocalTimeMs, RemoteTimeMs and RemoteTimeMs.
None
UncleanLeaderElectionsPerSec
kafka.controller: type=ControllerStats
- Leader election이 진행중인 비율
- 진행중이라면 그 동안 leader가 정상동작을 못하므로, 0이 되어야 함.
!= 0
LogFlushRateAndTimeMs
kafka.log: type=LogFlushStats
- 비동기적인 disk log flush 시간(ms)
None
UncleanLeaderElectionsPerSec
kafka.controller: type=ControllerStats
- unclean.leader.election 옵션은 In-Sync Replica 상태가 아닌 복제본도
leader로 선출될 수 있
When UncleanLe
aderElectionsPer
Sec != 0.
Bottleneck 구간
파악

요청의 유형
1. Producer
• 데이터를 전송하는 요청
2. Fetch-consumer
• Consumer가 데이터를 가져오는 요청
3. Fetch-follower
• Follower가 새로운 데이터를 복제하기
위한 요청
TotalTimeMs의 구성
- Queue : 요청 큐에 대기한 시간
- Local : leader에 의해 처리된 시간 (원본)
- Remote : follower에 의해 처리된 시간(복제)
- Response : 응답을 보낸 시간
요청을 처리에 소요된 전체 시간으로, 3가지 요청으로 구분
TotalTimeMs 이해

12
Kafka Monitoring – Kafka Broker 원인 추적(1/2)
TotalTimeMs이 너무 오래 걸리면, Bottleneck이 어디서 발생하는지 상세 metrics 확인
Metric Comments
name=RequestQueueTimeMs,
request=
{Produce|FetchConsumer|FetchFollower}
• 요청 큐에서 기다리는 시간을 producer, consumer fetch, follower fetch별로 측정
• 높은 값(대기 시간이 길어지는 현상)은 I/O thread가 부족하거나, CPU 부하 예상
name=LocalTimeMs
request=
{Produce|FetchConsumer|FetchFollower
• 전달된 요청을 leader에서 처리하는 시간. (leader가 local data 처리)
• 높은 값은 disk i/o가 낮음을 의미
name=RemoteTimeMs
request=
• 원격 client에서 요청을 기다리는 시간
• 높은 값은 NW 연결이 늦어짐을 의미
• Fetch 요청에서 이 값이 높은 것은, 가져올 데이터가 많지 않음을 의미할 수 있음
name=ResponseQueueTimeMs
request=
• 요청이 응답 큐에서 대기하는 시간.
• 높은 값은 NW thread가 부족함을 의미.
name=ResponseSendTimeMs
request=
• Client의 요청에 응답한 시간.
• 높은 값은 NW thread 또는 CPU가 부족하거나, NW부하가 높음을 의미

13
Kafka Monitoring – Kafka Broker 원인 추적(2/2)
TotalTimeMs이 너무 오래 걸리면, Bottleneck이 어디서 발생하는지 상세 metrics 확인
Metric Comments
kafka.network:type=RequestChannel,
name=ResponseQueueSize
• 요청 큐의 크기.
• 이상적으로는 0에 근접해야 함.
• 순간적인 요청으로 값이 커질 수는 있으나, 지속적으로 값이 큰 경우는 요청을 정상
적으로 처리하지 못하는 상태임.
kafka.network:type=RequestChannel,
name=ResponseQueueSize
• 응답 큐의 누적된 크기.
• 만약 지속적으로 증가하면, 전송 측에서 경합이 발생하고 있다는 의미일 수 있다.
• 경합 : 요청을 서로 하기 위하여 서로 경쟁하는 상태
kafka.network:type=SocketServer,
name=NetworkProcessorAvgIdlePercen
t
• Network thread가 idle 상태인 평균 시간
• 낮을 수록 thread가 많은 작업을 하고 있음을 의미. (request관련 jmx 지표와 함께
조회)
kafka.server:type=KafkaRequestHandle
rPool,
name=RequestHandlerAvgIdlePercent
• I/O thread가 idle 상태인 평균시간.
kafka.log:type=LogFlushStats,name=
LogFlushRateAndTimeMs
• Kafka log의 page cache의 flush가 발생하는 주기.
• Disk 속도가 느린지, page cache가 잘못 설정 되었는지 확인 가능

14
PurgatorySize
- kafka.server:type=ProducerRequestPurgatory,name=PurgatorySize
- kafka.server:type=FetchRequestPurgatory,name=PurgatorySize
- Broker에서 Producer 와 consumer의 요청을 처리하지 않고, 격리시킨
크기
- 어떤 경우에 이렇게 요청을 격리하나?
- Produce
- Request.required.acks = -1 일 때,
- 모든 follower가 복제가 완료되기 전까지 요청
- Fetch (consumer 관점)
- Fetch.wait.max.ms 시간동안
- fetch.min.bytes만큼의 데이터가 없는 경우

15
PartitionCount
- 시스템에 존재하는 partition 개수
Topic의 partition 개수
와 비교
ISR shrink/expansion rate
- Broker가 다운되었을때, 일부 partition의 ISR이 줄어든다.
- Broker가 정상으로 회복하면, OSR상태에서 ISR로 복귀되는 비율
=! 0
NetworkProcessorAvgIdlePerc
ent
kafka.network: type=SocketServer
- 네트워크 프로세서가 유휴상태인 비율
- 이 수치가 낮으면 유휴비율이 높다는 의미
When NetworkProces
sorAvgIdlePercent < 0
.3.
RequestHandlerAvgIdlePercent
kafka.server: type=KafkaRequestHandlerPool
- Request handler thread가 유휴상태인 시간의 평균
- 이 수치가 낮으면 일을 안한다는 의미.
When RequestHandle
rAvgIdlePercent < 0.3.
Heap Memory Usage - 메모리는 java 프로세스에 의해서 동적으로 할당된다. None

16
Kafka Monitoring – Kafka Consumer Metrics
Consumer에서 제공하는 metrics 정보들
MaxLag
kafka.consumer: type=ConsumerFetcherManager
- Producer가 write한 최근 메세지와 consumer에 의해 읽혀진 메세시간의 차이
- 이 수치가 크면 consumer에서 지연이 발생한다는 의미
MaxLag > 50.
MinFetchRate
kafka.consumer: type=ConsumerFetcherManager
- Consumer가 broker에게 요청을 보내는 최소 비율
- 만약 consumer가 중지되었다면, 0으로 낮아질 것이다.
MinFetchRate < 0.5.
MessagesPerSec
kafka.consumer: type=ConsumerTopicMetrics
- 초당 읽어들인 메세지 갯수 (이벤트 갯수인가? 전체 메세지 size인가?)
None
BytesPerSec
kafka.consumer: type=ConsumerTopicMetrics
- 초당 읽은 byte size
None
KafkaCommitsPerSec
kafka.consumer: type=ZookeeperConsumerConnector
- Consumer가 kafka에 offset을 commit한 비율 (초당 commit수)
None
OwnedPartitionsCount
kafka.consumer: type=ZookeeperConsumerConnector
- Consumer가 가지고 있는 partition의 갯수
만약 cluster에 설정
된 개수와 다르면, 동
적으로 조정 필요

17
Kafka Monitoring – Kafka Procuder Metrics
Producer의 성능관련 지표
io-ratio
kafka.producer:type=producer-metrics,client-id=([- .w]+)
- I/O 작업을 위해 I/O thread가 사용한 시간
io-wait-ratio
kafka.producer:type=producer-metrics,client-id=([- .w]+)
- I/O thread가 waiting에 소요한 시간
User processing time
- à 위 2개 시간을 제외하면, user processing time을 계산 가능
- à 만약 위 2개 수치가 낮다면, user processing time이 높아지고,
- à 그 의미는 producer I/O thread가 바쁘다는 의미이다.

18
Kafka Monitoring – Kafka Cluster Health check
정상 cluster 상태(broker가 동작중이고, partition이 복제되고 있는) 모니터링
IsrShrinksPerSec
kafka.server:type=ReplicaManager,
- ISR이 줄어드는 비율.
- 만약 broker가 중지하면, ISR 개수가 줄어들 것이다.
UnderReplicatedPartiti
ons
- 항상 0이 되어야 한다.
- 0보다 크다면, 복제가 제대로 되고있지 않음을 의미

19
Kafka Monitoring – Latency 관련
Offset의 상태
records-lag-max
kafka.consumer:type=consumer-fetch-manager- metrics,client-id=([-.w]+)
- Procucer가 쓰는 최신의 메세지 offset값과, consumer가 읽어간 offset값의
최대 차이(partition 들 중)
- 값이 증가한다면, consumer group이 데이터를 빠르게 가져가지 못함을 의미

20
Kafka Monitoring – 모니터링 도구들
JMX를 지원하는 모든 tool은 kafka 모니터링이 가능하다.
check_kafka.pl : 사용법
KafkaOffsetMonitor : offset 정보를 모니터링하는 웹 ui
Burrow. : consumer 상태 모니터링만 제공
Kafka-Manager. : ui기반의 모니터링 도구, Kafka 0.8.1.1 or 0.8.2.* or 0.9.0.* or 0.10.0.*
kafkat. : command line 기반의 관리 도구
버전이 너무 낮다

Apache Kafka 성능 최적화 방안
(Throughtput, Latency, Durability, Avalibility)

22
Producer 관련 설정들
Producer 최적화를 위한 옵션들
• batch.size
• linger.ms
• compression.type
• acks
• retries
• max.in.flight.requests.per.connection
• buffer.memory

23
Broker 관련 설정들
최적화를 위한 옵션들
• default.replication.factor
• num.replica.fetchers
• auto.create.topics.enable
• min.insync.replicas
• unclean.leader.election.enable
• broker.rack
• log.flush.interval.messages
• log.flush.interval.ms
• num.recovery.threads.per.data.dir

24
Consumer 관련 설정들
최적화를 위한 옵션들
• fetch.min.bytes
• auto.commit.enable
• session.timeout.ms

25
Throughput 최대화 방안 – Producer 설정 (1/3)
Partition 수를 증가
• Partition 수를 증가 à 분산효과 (partition 수는 어떻게 결정?)

26
Batch 전송 전략을 최적화
• Partition에 한번에 보내는 message 크기
• 한번에 많은 량을 보내면, 전송회수도 줄어들어 서버부하 감소
• Batch.size : 한번에 보낼 량 증가
• Linger.ms :
• producer가 전송전에 기다리는 시간
• (batch.size가 꽉 찰 수 있도록 시간 설정)
• compression.type : batch데이터를 압축할 알고리즘
• Acks : producer가 데이터 전송후 commit 결과를 받는 방식
• 1 : leader broker에만 저장되면 결과 리턴
• All : 모든 follower에 복사된 이후에 결과 리턴

27
Batch 전송 전략을 최적화
• Retries : 전송 실패시 다시 시도하는 회수
• Buffer.memory :
• Producer가 보내지 못한 message를 보관할 memory의 크기
• 만약 memory가 full이되면, 다른 message 전송을 blocking
• memory 여유가 생기거나, max.block.ms를 초과하면 전송
• Partition이 많지 않으면, 조정할 필요 없음.
• Partition이 많다면, memory를 늘려서 blocking 없이 더 많은 데이터가 전송
되도록 설정

28
Throughput 최대화 방안 – Consumer 설정
메세지 수신량을 최대화
• fetch.min.bytes : consumer에서 가져오는 최소 데이터 사이즈
• 이 값보다 적은 데이터가 있으면, broker에서 보내지 않음.
• 값 증가
• broker로 요청하는 회수 감소(한번에 많은 데이터 수신)
• Broker의 자원사용 절감(fetch 당 cpu 사용량)
• Producer에서 batch.size를 증가하는 것과 동일
• fetch.max.wait.ms : consumer에서 데이터를 가져오는 최소 시간
• 새로운 데이터가 입력되어도, 해당 시간 이전에는 가져가지 않는다.
• 내부적으로 consumer가 fetch 요청을 해도, broker가 보내지 않음
• Consumer group 활용 : 동시에 여러개 consumer 구동
• JVM 설정 : GC 최소화

29
Throughput 최대화 방안 – 요약 정리
Producer와 Consumer 설정 가이드
• 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)

30
Latency 최소화 방안 (1/3)
지연을 최소화 하기 위한 설정들 (broker)
• Partition 개수 제한
• 너무 많은 partition 수는 message 지연을 유발
• 왜냐하면, partition 복사를 위한 시간만큼 지연 (ACK > 1)
• Broker 수 ↑, partition 수 적게
• 하나의 broker에서 담당하는 partition 수를 줄여서
• 복제에 소요되는 시간을 최소화한다.
• Num.replica.fetchers
• Follower broker의 I/O 병렬수준을 정의 (default 1)
• Leader broker에서 데이터를 복제하는 thread의 개수

31
지연을 최소화 하기 위한 설정들 (producer)
• linger.ms (default 0)
• Producer에서 broker로 데이터를 보내기 위해 기다리는 시간
• 0 : 데이터를 수집하는 순간 broker로 전송 (지연 없음)
• compression.type : 압축이 필요한지 검토
• CPU : 압축을 위한 자원 사용
• NW : 압축된 경우 NW bandwidth 사용량 줄어듬
• 압축성능에 따라 cpu 사용, nw bandwidth 줄여서 지연 최소화 가능
• Acks
• 언제 broker로 부터 message 전송결과를 받을 것인지 정의
• 1 : 데이터 복제 없이, 원본만 저장되면 결과 리턴

32
지연을 최소화 하기 위한 설정들 (consumer)
• fetch.min.bytes (default 1)
• Broker에서 데이터를 가져오는 최소 size
• 1: 1byte만 있어도 요청시 바로 전송 (지연 없음)

33
Durability 보장 방안 – broker (1/4)
메세지 유실을 최소화 – broker (복제가 가장 중요한 요소)
• replication.factor
• 3 : 높은 수준의 durability 지원
• default.replication.factor
• auto.create.topics.enable 가 true인 경우
• 자동으로 생성되는 topic의 복제수 설정
• 운영상의 안정성을 위해 auto.create.topics.enable는 false가 권장
• acks = all (acks = -1 동일)
• 모든 replica에 복제가 완료된 후, producer에 ack 리턴

34
• Broker.rack
• 하나의 rack에 broker가 동작하지 않도록 설정
• Cloud 기반 서비스에서 broker가 각각 다른 zone에 구동되도록 함.
• 안정성은 높아지지만 데이터 복제시 NW 부하 증가.
• Broker가 죽었을 때, OSR replica도 leader로 선택될 수 있도록 설정 (true)
• OSR(out-of sync replica) : 죽은 broker의 최신 메세지를 복사히지 못한 replica à 데이
터 유실 가능.
• 유실보다는 서비스 가용성을 높이는 경우 (true)
• 유실을 최소화 하느 경우 (false)

35
unclean.leader.election.enable 동작 방식
unclean.leader.election.enable
- In-Sync Replica 상태가 아닌 복제본도 leader로 선출될
수 있도록 하는 옵션
- Kafka 서버는 여러 개의 동작중인 broker로 구성된다.
- 그리고 partition은 유실을 방지하기 위해서 다른 broker
로 복제된다.
- 또한 각 partition에 대하여 ISR(in-sync replica) 목록을
가지고 있다.
- Replica란 leader broker의 원본 메세지가 정상적으로 복
제된 follower broker의 partition
- Leader는 ISR replica를 가지고 있는 broker 중에서 선정
된다. 만약 ISR을 가진 broker가 없다면(즉, 최신 데이터
를 가지고 있지 않음), OSR(out-of-sync replica)중에서
leader를 선발할지 위 설정값을 보고 판단
https://www.slideshare.net/ConfluentInc/when-it-absolutely-positively-has-to-be-there-reliability-guarantees-in-kafka-gwen-shapira-jeff-holoman/17?src=clipshare
어떤 방식으로 동작하는가?
B1 B2
100 100
- Kafka 서버는 여러 개의 동작중인 broker로 구성된다.
- 모든 replica가 ISR 상태
B1 B2
100 100
101
- B2 broker가 중지된 상태에서
B1에 새로운 메세지 입력
B1 B2
100 100
101
- B1 broker까지 다운되어
leader선출 불가
B1 B2
100 100
101
- B2의 replica는 OSR 상태
- 설정값에 따라서 leader가 될
수 있으나, B1에 입력된 데이
터는 유실됨
1
2
3
4

36
• log.flush.interval.ms / log.flush.interval.messages
• 입력된 message를 memory(page cache)에서 disk로 저장하는 수준
• 값이 클수록 Disk I/O가 적게 발생 à 메모리 데이터 유실 가능
• 값이 작으면 Disk I/O 많이 발생 à 메모리 데이터 유실 거의 없음

37
Durability 보장 방안 – Producer (1/2)
메세지 유실을 최소화 – producer
• acks = all (acks = -1 동일)
• 모든 replica에 복제가 완료된 후, producer에 ack 리턴
• acks = all이면, min.insync.replicas = replication.factor 동일하게 설정
• min.insync.replicas : ISR상태를 가지는 replica의 최소 개수
• 즉, producer에 응답하기 위한 replica의 ISR 최소 개수 (복제된 수)

38
Durability 보장 방안 – Producer (2/2)
메세지 유실을 최소화 – producer
• retries
• Producer의 전송실패시 자동으로 재전송하는 회수
• API의 callback i/f인 onComplete()로 직적 코딩 가능
• Retry시 고려사항
• 메세지 중복 가능성 : 일시적 오류로 producer가 2번 전송 가능
• 메세지 순서 변경 가능
• 한번에 여러 번의 request가 nw에서 대기중 인 경우,
• Fail된 request 다음 메세지가 먼저 전송되는 경우 발생
• max.in.flight.requests.per.connection = 1로 설정 (한번에 1개 요청)

39
Durability 보장 방안 – Consumer (1/2)
읽어온 메세지의 위치를 정확하게 기록 (중복 읽기 없도록)
• 중복 읽기 가능한 상황
• Consumer가 데이터를 읽어오고,
• broker에 읽어온 offset 위치를 commit
• Consumer에서 읽어온 message를 처리할때 에러 발생(처리 못함)
• 해결방안 (auto.commit.enable)
• Default(true)로 consumer가 poll() 호출을 하는 시점에,
• Offset은 자동으로 commit
• False로 변경
• Poll()이후 commitSync() or commitAsync() 호출 후에
• Broker가 Offset을 commit

40
Durability 보장 방안 – SUMMARY
메세지 유실을 최소화 하기 위한 설정 가이드
• replication.factor: 3, configure per topic
• acks=all (default 1)
• retries: 1 or more (default 0)
• max.in.flight.requests.per.connection=1 (default 5), to prevent out of order
messages
• default.replication.factor=3 (default 1)
• auto.create.topics.enable=false (default true)
• min.insync.replicas=2 (default 1); topic override available
• unclean.leader.election.enable=false (default true); topic override available
• broker.rack: rack of the broker (default null)
• log.flush.interval.messages, log.flush.interval.ms: for topics with very low
throughput, set message interval or time interval low as needed (default allows the
OS to control flushing); topic override available
• auto.commit.enable=false (default true)
PRODUCER
BROKER
CONSUMER

41
Availability 보장 방안 – Broker (1/2)
장애로 부터 가능한 빠르게 복구하는데 중점
• 너무 많은 partition 수
• Partition별 leader 선출에 많은 시간 소요 (복구 시간 증가)
• min.insync.replicas
• Producer가 응답을 받기 위한 최소 복제 수
• 값이 크면, 복제 실패시 producer의 장애 유발 à durability 높음
• 값이 1이면, 원본만 저장되면 producer 정상 동작 à durability 낮음
• unclean.leader.election.enable=true
• Broker가 죽었을 때, OSR replica도 leader로 선택가능 (true)
• OSR(out-of sync replica) : 죽은 broker의 최신 메세지를 복사히지 못한 replica à 데이
터 유실 가능.
• 유실보다는 서비스 가용성을 높이는 경우 (true)

42
Availability 보장 방안 – Broker(2/2)
장애로 부터 가능한 빠르게 복구하는데 중점
• num.recovery.threads.per.data.dir
• Broker가 시작/중지 할 때, 다른 broker와 sync를 맞추기 위해
• log data file을 스캔하는 thread를 실행한다
• 이때 data directory 별로 할당되는 Thread 수
• 값이 크면 à 한번에 여러 log file을 동시처리 가능 (RAID 구성인 경우)
• 즉 Broker가 빠르게 구동됨

43
Availability 보장 방안 – Consumer
Consumer 장애를 감지하여, 남은 consumer로 partition 재배치
• session.timeout.ms
• Consumer가 비정상적으로 종료되었을 경우,
• Broker가 장애로 인지하는 최소시간
• 장애 유형
• Hard failure : SIGKILL (강제 종료)
• Soft failure : session time out (대부분의 경우 해당)
• Poll()호출 후, consumer에서 처리시간이 오래 걸리는 경우
• JVM GC로 인한 멈춤현상
• 값이 적으면 à 더 빠르게 장애를 감지 (복구 빠름)
• 장애가 더 자주 나타남. (조금만 지연되어도, failure 판단)
• 가능한 낮은 값을 설정하여, Hard failure를 빠르게 감지하도록 설정
• 고려사항
• 너무 낮게 설정하면, Soft failure까지 감지하여 너무 잦은 에러처리

44
Availability 보장 방안 – SUMMARY
Consumer 장애를 감지하여, 남은 consumer로 partition 재배치
• unclean.leader.election.enable=true (default true); topic override available
• min.insync.replicas=1 (default 1); topic override available
• num.recovery.threads.per.data.dir: number of directories in log.dirs (default 1)
• session.timeout.ms: as low as feasible (default 10000)
BROKER
CONSUMER

성능 테스트 수행 시 고려사항

46
Benchmark Test 고려사항
Benchmark test 고려사항
• Benchmark test결과에 따라
• 환경에 맞는 partition 수, cluster size, producer/consumer 수 결정
• Kafka 기본 설정으로 테스트 시작
• Kafka의 default설정에 익숙해 지는 것이 좋다
• Producer 성능에 영향을 주는 종속성 제거
• 외부에서 생성되는 데이터를 사용하지 말고,
• 자체 Data generator를 통해 데이터 생성속도 향상
• 1개 서버에 1개 producer 실행 및 JMX Metrics 측정
• Producer를 증가하며 측정 계속 à 적절한 producer 수 결정
• Consumer도 동일하게 측정

47
Benchmark Test 고려사항
Benchmark test 고려사항
• 특정 설정이 성능에 미치는 영향을 확인하라
• 4가지 유형에 따른 설정값 중심
• 각각의 설정값이 측정결과에 미치는 영향을 꼭 확인하고, 다른 값을 변경
• Confluence Control Center 활용 고려 (상용)
• http://docs.confluent.io/current/control-center/docs/index.html

Topics/Partitions 수를
어떻게 선택할까?

49
Topics/Partitions 수를 어떻게 선택할까?
More Partitions Lead to Higher Throughput
https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/
• Partition 수를 증가하면 처리량이 높아짐 (분산효과)
• Producer, Broker : Write 처리량이 증가, HW 자원사용 증가
• Consumer : partition 수 만큼 병렬 쓰레드 구동
• 목표 처리량(t)이 있다면, partition 개수를 정할 수 있다.
• 단일 partition의 쓰기 속도 계산(p)
• 단일 partition의 읽기 속도 계산(c)
• Partition 개수 = max(t/p, t/c)
• 고려사항으로
• Batch_size, compression codec, acknwledgement, replication factor 등에 따라 처리성
능이 달라짐.
• Key별로 partition을 할당해야 하는 경우, 향후 증가량을 고려하여 개수 할당

50
More Partitions Requires More Open File Handles
• 각 Partition은 broker의 특정 directory(log)에 저장됨
• Log segment당 2개의 파일 생성(index , data)
• Kafka는 모든 log segment의 index와 data file handler를 오픈
• Partition이 많아지면, OS의 file handler 관련 설정 변경

51
More Partitions May Increase Unavailability
• Kafka는 가용성과 유실을 방지하기 위해, 복제본(replica)을 관리한다.
• Leader broker는 복제본 중 1개를 가지게 되는데,
• leader가 다운되면 순간적으로 leader의 partition은 서비스가 불가능해 진다.
• 대부분 broker는 정상적으로 다운되어, 사전에 partition의 leader를 이동시킨다.
(controller broker의 역할)
• 하나의 partition leader를 이동하는 것은 순식간에 실행되어, consumer 관점에서는 잠깐
접속이 안되는 상황이 발생.
• 만약 broker에 1,000개의 partition이 있고, 비정상 종료(kill -9)가 되었다면?
• Partition의 서비스 중지 시간은 partition 개수에 비례
• 하나의 partition의 leader를 선출하는 시간이 5ms,
• 1,000 partition à 5 sec 소요 (5초 동안 서비스 불가)
• 만약 controller broker가 다운되었다면? à 새로운 controller가 실행될때 까지 모든
partition의 leader 선출 불가능

52
More Partitions May Increase End-to-end Latency
• Kafka에서 producer à consumer로의 전송은 message가 commit된 후에 가능
• 복제된 message가 모두 ISR상태에 있는 것
• Kafka는 broker간의 데이터 복제에 single thread만 사용
• 1,000개의 partition을 다른 broker로 복제하는데 20ms소요 (latency 영향)
• 만약 cluster가 크다면, 1,000개 partition이 여러 broker로 분산복제되어 복사 속도는 줄
어듬
• Latency가 중요하다면!
• Broker당 partition 개수는 제한
• Partition 수 = 100 * b * r
• b : broker 수
• r : replicator factor 수

53
More Partitions May Require More Memory In the Client
• 0.8.2 이후 kafka의 New producer 개선기능
• 유입되는 message의 buffer에서 사용하는 memory 제한 설정
• Producer는 partition별로 memory buffer를 생성
• 만약 partition이 증가하면, 전체 memory buffer가 증가 à Out Of Memory
• Throughput이 중요하다면!
• Producer에서 partition별로 할당하는 buffer memory를 수십 KB로 제한
• 전체 memory를 partition수 * buffer memory로 계산하여 재조정
• 위 사항은 producer, consumer 모두 유사하게 발생함.

54
요약해 보면..
많은 partition은 처리량을 높여주지만,
이후에 latency & availability에
잠재적인 문제를 유발할 수 있다.
운영관점에서 지속적인 모니터링 필요

Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안

Similar to Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안 (20)

More from SANG WON PARK

More from SANG WON PARK (16)

Recently uploaded

Recently uploaded (6)

Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안