KEMBAR78
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안 | PDF
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가지 목표에 따른 특징
각 특징에 따른 요건
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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에서 사용하고 있는 자원 현황 및 이상치 감지
https://blog.serverdensity.com/how-to-monitor-kafka/
• Open File Handles, CPU, Network I/O
7
Kafka Monitoring – System Metrics (Swap usage)
Kafka Server에서 Swap이 발생하면, Disk I/O가 발생하여 성능에 영향
https://blog.serverdensity.com/how-to-monitor-kafka/
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가 발생하여 성능에 영향
https://blog.serverdensity.com/how-to-monitor-kafka/
Disk 사용률
• 아래 명령어를 이용해 kafka가 사용하는 disk 사용률이
85%가 넘는지 확인한다.
• > df –h
9
Kafka Monitoring – Kafka Broker Metrics
Kafka Server 동작중에 발생하는 metrics 정보들
https://blog.serverdensity.com/how-to-monitor-kafka/
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
Kafka Monitoring – Kafka Broker Metrics
Kafka Server 동작중에 발생하는 metrics 정보들
Metric Comments Alert
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 구간
파악
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
요청의 유형
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=
{Produce|FetchConsumer|FetchFollower}
• 원격 client에서 요청을 기다리는 시간
• 높은 값은 NW 연결이 늦어짐을 의미
• Fetch 요청에서 이 값이 높은 것은, 가져올 데이터가 많지 않음을 의미할 수 있음
name=ResponseQueueTimeMs
request=
{Produce|FetchConsumer|FetchFollower}
• 요청이 응답 큐에서 대기하는 시간.
• 높은 값은 NW thread가 부족함을 의미.
name=ResponseSendTimeMs
request=
{Produce|FetchConsumer|FetchFollower}
• Client의 요청에 응답한 시간.
• 높은 값은 NW thread 또는 CPU가 부족하거나, NW부하가 높음을 의미
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
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가 잘못 설정 되었는지 확인 가능
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
14
Kafka Monitoring – Kafka Broker Metrics
Kafka Server 동작중에 발생하는 metrics 정보들
Metric Comments Alert
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만큼의 데이터가 없는 경우
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
15
Kafka Monitoring – Kafka Broker Metrics
Kafka Server 동작중에 발생하는 metrics 정보들
https://blog.serverdensity.com/how-to-monitor-kafka/
Metric Comments Alert
PartitionCount
kafka.server: type=ReplicaManager
- 시스템에 존재하는 partition 개수
Topic의 partition 개수
와 비교
ISR shrink/expansion rate
kafka.server: type=ReplicaManager
- 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 정보들
https://blog.serverdensity.com/how-to-monitor-kafka/
Metric Comments Alert
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의 성능관련 지표
Metric Comments Alert
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가 바쁘다는 의미이다.
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
18
Kafka Monitoring – Kafka Cluster Health check
정상 cluster 상태(broker가 동작중이고, partition이 복제되고 있는) 모니터링
Metric Comments Alert
IsrShrinksPerSec
kafka.server:type=ReplicaManager,
- ISR이 줄어드는 비율.
- 만약 broker가 중지하면, ISR 개수가 줄어들 것이다.
UnderReplicatedPartiti
ons
- 항상 0이 되어야 한다.
- 0보다 크다면, 복제가 제대로 되고있지 않음을 의미
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
19
Kafka Monitoring – Latency 관련
Offset의 상태
Metric Comments Alert
records-lag-max
kafka.consumer:type=consumer-fetch-manager- metrics,client-id=([-.w]+)
- Procucer가 쓰는 최신의 메세지 offset값과, consumer가 읽어간 offset값의
최대 차이(partition 들 중)
- 값이 증가한다면, consumer group이 데이터를 빠르게 가져가지 못함을 의미
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
20
Kafka Monitoring – 모니터링 도구들
JMX를 지원하는 모든 tool은 kafka 모니터링이 가능하다.
https://blog.serverdensity.com/how-to-monitor-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 최적화를 위한 옵션들
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• batch.size
• linger.ms
• compression.type
• acks
• retries
• max.in.flight.requests.per.connection
• buffer.memory
23
Broker 관련 설정들
최적화를 위한 옵션들
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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
• unclean.leader.election.enable
• num.recovery.threads.per.data.dir
24
Consumer 관련 설정들
최적화를 위한 옵션들
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• fetch.min.bytes
• auto.commit.enable
• session.timeout.ms
25
Throughput 최대화 방안 – Producer 설정 (1/3)
Partition 수를 증가
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• Partition 수를 증가 à 분산효과 (partition 수는 어떻게 결정?)
26
Throughput 최대화 방안 – Producer 설정 (2/3)
Batch 전송 전략을 최적화
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• Partition에 한번에 보내는 message 크기
• 한번에 많은 량을 보내면, 전송회수도 줄어들어 서버부하 감소
• Batch.size : 한번에 보낼 량 증가
• Linger.ms :
• producer가 전송전에 기다리는 시간
• (batch.size가 꽉 찰 수 있도록 시간 설정)
• compression.type : batch데이터를 압축할 알고리즘
• Acks : producer가 데이터 전송후 commit 결과를 받는 방식
• 1 : leader broker에만 저장되면 결과 리턴
• All : 모든 follower에 복사된 이후에 결과 리턴
27
Throughput 최대화 방안 – Producer 설정 (3/3)
Batch 전송 전략을 최적화
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• Retries : 전송 실패시 다시 시도하는 회수
• Buffer.memory :
• Producer가 보내지 못한 message를 보관할 memory의 크기
• 만약 memory가 full이되면, 다른 message 전송을 blocking
• memory 여유가 생기거나, max.block.ms를 초과하면 전송
• Partition이 많지 않으면, 조정할 필요 없음.
• Partition이 많다면, memory를 늘려서 blocking 없이 더 많은 데이터가 전송
되도록 설정
28
Throughput 최대화 방안 – Consumer 설정
메세지 수신량을 최대화
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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 설정 가이드
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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)
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• Partition 개수 제한
• 너무 많은 partition 수는 message 지연을 유발
• 왜냐하면, partition 복사를 위한 시간만큼 지연 (ACK > 1)
• Broker 수 ↑, partition 수 적게
• 하나의 broker에서 담당하는 partition 수를 줄여서
• 복제에 소요되는 시간을 최소화한다.
• Num.replica.fetchers
• Follower broker의 I/O 병렬수준을 정의 (default 1)
• Leader broker에서 데이터를 복제하는 thread의 개수
31
Latency 최소화 방안 (2/3)
지연을 최소화 하기 위한 설정들 (producer)
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• linger.ms (default 0)
• Producer에서 broker로 데이터를 보내기 위해 기다리는 시간
• 0 : 데이터를 수집하는 순간 broker로 전송 (지연 없음)
• compression.type : 압축이 필요한지 검토
• CPU : 압축을 위한 자원 사용
• NW : 압축된 경우 NW bandwidth 사용량 줄어듬
• 압축성능에 따라 cpu 사용, nw bandwidth 줄여서 지연 최소화 가능
• Acks
• 언제 broker로 부터 message 전송결과를 받을 것인지 정의
• 1 : 데이터 복제 없이, 원본만 저장되면 결과 리턴
32
Latency 최소화 방안 (3/3)
지연을 최소화 하기 위한 설정들 (consumer)
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• fetch.min.bytes (default 1)
• Broker에서 데이터를 가져오는 최소 size
• 1: 1byte만 있어도 요청시 바로 전송 (지연 없음)
33
Durability 보장 방안 – broker (1/4)
메세지 유실을 최소화 – broker (복제가 가장 중요한 요소)
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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
Durability 보장 방안 – broker (2/4)
메세지 유실을 최소화 – broker (복제가 가장 중요한 요소)
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• Broker.rack
• 하나의 rack에 broker가 동작하지 않도록 설정
• Cloud 기반 서비스에서 broker가 각각 다른 zone에 구동되도록 함.
• 안정성은 높아지지만 데이터 복제시 NW 부하 증가.
• unclean.leader.election.enable
• 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
Durability 보장 방안 – broker (3/4)
36
Durability 보장 방안 – broker (4/4)
메세지 유실을 최소화 – broker (복제가 가장 중요한 요소)
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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)
읽어온 메세지의 위치를 정확하게 기록 (중복 읽기 없도록)
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 중복 읽기 가능한 상황
• 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
메세지 유실을 최소화 하기 위한 설정 가이드
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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)
장애로 부터 가능한 빠르게 복구하는데 중점
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 너무 많은 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)
장애로 부터 가능한 빠르게 복구하는데 중점
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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 재배치
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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 재배치
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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 고려사항
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 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 고려사항
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
• 특정 설정이 성능에 미치는 영향을 확인하라
• 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
Topics/Partitions 수를 어떻게 선택할까?
More Partitions Requires More Open File Handles
https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/
• 각 Partition은 broker의 특정 directory(log)에 저장됨
• Log segment당 2개의 파일 생성(index , data)
• Kafka는 모든 log segment의 index와 data file handler를 오픈
• Partition이 많아지면, OS의 file handler 관련 설정 변경
51
Topics/Partitions 수를 어떻게 선택할까?
More Partitions May Increase Unavailability
https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/
• 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
Topics/Partitions 수를 어떻게 선택할까?
More Partitions May Increase End-to-end Latency
https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/
• 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
Topics/Partitions 수를 어떻게 선택할까?
More Partitions May Require More Memory In the Client
https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/
• 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
Topics/Partitions 수를 어떻게 선택할까?
요약해 보면..
https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/
많은 partition은 처리량을 높여주지만,
이후에 latency & availability에
잠재적인 문제를 유발할 수 있다.
운영관점에서 지속적인 모니터링 필요

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

  • 1.
    Apache Kafka 성능최적화 (Metrics & Configuration Tunning) 2018.11 freepsw 성능 모니터링을 위한 Metric 이해 및 Configuration 튜닝 방안
  • 2.
    2 어떤 성능 목표를설정할 것인가? 서비스의 특징에 따른 성능목표를 정한 후 파라미터 튜닝 필요 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ 보통 아래 4가지를 목표로 설정하며, 각 항목은 상호 trade-off 관계 모든 목표를 동시에 모두 최적화 할 수 없다.
  • 3.
    3 4가지 목표에 따른특징 각 특징에 따른 요건 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • Kafka 특성상 많은 데이터를 빠르게 쓰는것은 문제가 없음Throughput • 하나의 메세지를 가능한 빠르게 전달 (실시간 채팅 서비스) • (producer à broker à consumer) Latency • 메세지의 유실을 최소화 • Event 기반 microservice 또는 데이터 수집 파이프라인 Durability • Kafka 서버의 다운타임 최소화 • 장애시 가장 빠르게 복구 해야 하는 서비스 Availability
  • 4.
    Kafka 모니터링에 필요한 Metric이해 (System, Broker, Producer, Consumer)
  • 5.
    5 Kafka Monitoring –Kafka Server is running? Kafka server가 정상 동작하고 있는지 확인 https://blog.serverdensity.com/how-to-monitor-kafka/ > ps -ef | grep "kafka.Kafka"
  • 6.
    6 Kafka Monitoring –System Metrics Kafka server에서 사용하고 있는 자원 현황 및 이상치 감지 https://blog.serverdensity.com/how-to-monitor-kafka/ • Open File Handles, CPU, Network I/O
  • 7.
    7 Kafka Monitoring –System Metrics (Swap usage) Kafka Server에서 Swap이 발생하면, Disk I/O가 발생하여 성능에 영향 https://blog.serverdensity.com/how-to-monitor-kafka/ 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.
    8 Kafka Monitoring –System Metrics (Swap usage) Kafka Server에서 Swap이 발생하면, Disk I/O가 발생하여 성능에 영향 https://blog.serverdensity.com/how-to-monitor-kafka/ Disk 사용률 • 아래 명령어를 이용해 kafka가 사용하는 disk 사용률이 85%가 넘는지 확인한다. • > df –h
  • 9.
    9 Kafka Monitoring –Kafka Broker Metrics Kafka Server 동작중에 발생하는 metrics 정보들 https://blog.serverdensity.com/how-to-monitor-kafka/ 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.
    10 Kafka Monitoring –Kafka Broker Metrics Kafka Server 동작중에 발생하는 metrics 정보들 Metric Comments Alert 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 구간 파악 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
  • 11.
    요청의 유형 1. Producer •데이터를 전송하는 요청 2. Fetch-consumer • Consumer가 데이터를 가져오는 요청 3. Fetch-follower • Follower가 새로운 데이터를 복제하기 위한 요청 TotalTimeMs의 구성 - Queue : 요청 큐에 대기한 시간 - Local : leader에 의해 처리된 시간 (원본) - Remote : follower에 의해 처리된 시간(복제) - Response : 응답을 보낸 시간 요청을 처리에 소요된 전체 시간으로, 3가지 요청으로 구분 TotalTimeMs 이해
  • 12.
    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= {Produce|FetchConsumer|FetchFollower} • 원격 client에서 요청을 기다리는 시간 • 높은 값은 NW 연결이 늦어짐을 의미 • Fetch 요청에서 이 값이 높은 것은, 가져올 데이터가 많지 않음을 의미할 수 있음 name=ResponseQueueTimeMs request= {Produce|FetchConsumer|FetchFollower} • 요청이 응답 큐에서 대기하는 시간. • 높은 값은 NW thread가 부족함을 의미. name=ResponseSendTimeMs request= {Produce|FetchConsumer|FetchFollower} • Client의 요청에 응답한 시간. • 높은 값은 NW thread 또는 CPU가 부족하거나, NW부하가 높음을 의미 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
  • 13.
    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가 잘못 설정 되었는지 확인 가능 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
  • 14.
    14 Kafka Monitoring –Kafka Broker Metrics Kafka Server 동작중에 발생하는 metrics 정보들 Metric Comments Alert 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만큼의 데이터가 없는 경우 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
  • 15.
    15 Kafka Monitoring –Kafka Broker Metrics Kafka Server 동작중에 발생하는 metrics 정보들 https://blog.serverdensity.com/how-to-monitor-kafka/ Metric Comments Alert PartitionCount kafka.server: type=ReplicaManager - 시스템에 존재하는 partition 개수 Topic의 partition 개수 와 비교 ISR shrink/expansion rate kafka.server: type=ReplicaManager - 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.
    16 Kafka Monitoring –Kafka Consumer Metrics Consumer에서 제공하는 metrics 정보들 https://blog.serverdensity.com/how-to-monitor-kafka/ Metric Comments Alert 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.
    17 Kafka Monitoring –Kafka Procuder Metrics Producer의 성능관련 지표 Metric Comments Alert 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가 바쁘다는 의미이다. https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
  • 18.
    18 Kafka Monitoring –Kafka Cluster Health check 정상 cluster 상태(broker가 동작중이고, partition이 복제되고 있는) 모니터링 Metric Comments Alert IsrShrinksPerSec kafka.server:type=ReplicaManager, - ISR이 줄어드는 비율. - 만약 broker가 중지하면, ISR 개수가 줄어들 것이다. UnderReplicatedPartiti ons - 항상 0이 되어야 한다. - 0보다 크다면, 복제가 제대로 되고있지 않음을 의미 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
  • 19.
    19 Kafka Monitoring –Latency 관련 Offset의 상태 Metric Comments Alert records-lag-max kafka.consumer:type=consumer-fetch-manager- metrics,client-id=([-.w]+) - Procucer가 쓰는 최신의 메세지 offset값과, consumer가 읽어간 offset값의 최대 차이(partition 들 중) - 값이 증가한다면, consumer group이 데이터를 빠르게 가져가지 못함을 의미 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
  • 20.
    20 Kafka Monitoring –모니터링 도구들 JMX를 지원하는 모든 tool은 kafka 모니터링이 가능하다. https://blog.serverdensity.com/how-to-monitor-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 기반의 관리 도구 버전이 너무 낮다
  • 21.
    Apache Kafka 성능최적화 방안 (Throughtput, Latency, Durability, Avalibility)
  • 22.
    22 Producer 관련 설정들 Producer최적화를 위한 옵션들 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • batch.size • linger.ms • compression.type • acks • retries • max.in.flight.requests.per.connection • buffer.memory
  • 23.
    23 Broker 관련 설정들 최적화를위한 옵션들 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • 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 • unclean.leader.election.enable • num.recovery.threads.per.data.dir
  • 24.
    24 Consumer 관련 설정들 최적화를위한 옵션들 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • fetch.min.bytes • auto.commit.enable • session.timeout.ms
  • 25.
    25 Throughput 최대화 방안– Producer 설정 (1/3) Partition 수를 증가 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • Partition 수를 증가 à 분산효과 (partition 수는 어떻게 결정?)
  • 26.
    26 Throughput 최대화 방안– Producer 설정 (2/3) Batch 전송 전략을 최적화 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • Partition에 한번에 보내는 message 크기 • 한번에 많은 량을 보내면, 전송회수도 줄어들어 서버부하 감소 • Batch.size : 한번에 보낼 량 증가 • Linger.ms : • producer가 전송전에 기다리는 시간 • (batch.size가 꽉 찰 수 있도록 시간 설정) • compression.type : batch데이터를 압축할 알고리즘 • Acks : producer가 데이터 전송후 commit 결과를 받는 방식 • 1 : leader broker에만 저장되면 결과 리턴 • All : 모든 follower에 복사된 이후에 결과 리턴
  • 27.
    27 Throughput 최대화 방안– Producer 설정 (3/3) Batch 전송 전략을 최적화 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • Retries : 전송 실패시 다시 시도하는 회수 • Buffer.memory : • Producer가 보내지 못한 message를 보관할 memory의 크기 • 만약 memory가 full이되면, 다른 message 전송을 blocking • memory 여유가 생기거나, max.block.ms를 초과하면 전송 • Partition이 많지 않으면, 조정할 필요 없음. • Partition이 많다면, memory를 늘려서 blocking 없이 더 많은 데이터가 전송 되도록 설정
  • 28.
    28 Throughput 최대화 방안– Consumer 설정 메세지 수신량을 최대화 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • 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.
    29 Throughput 최대화 방안– 요약 정리 Producer와 Consumer 설정 가이드 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • 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.
    30 Latency 최소화 방안(1/3) 지연을 최소화 하기 위한 설정들 (broker) https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • Partition 개수 제한 • 너무 많은 partition 수는 message 지연을 유발 • 왜냐하면, partition 복사를 위한 시간만큼 지연 (ACK > 1) • Broker 수 ↑, partition 수 적게 • 하나의 broker에서 담당하는 partition 수를 줄여서 • 복제에 소요되는 시간을 최소화한다. • Num.replica.fetchers • Follower broker의 I/O 병렬수준을 정의 (default 1) • Leader broker에서 데이터를 복제하는 thread의 개수
  • 31.
    31 Latency 최소화 방안(2/3) 지연을 최소화 하기 위한 설정들 (producer) https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • linger.ms (default 0) • Producer에서 broker로 데이터를 보내기 위해 기다리는 시간 • 0 : 데이터를 수집하는 순간 broker로 전송 (지연 없음) • compression.type : 압축이 필요한지 검토 • CPU : 압축을 위한 자원 사용 • NW : 압축된 경우 NW bandwidth 사용량 줄어듬 • 압축성능에 따라 cpu 사용, nw bandwidth 줄여서 지연 최소화 가능 • Acks • 언제 broker로 부터 message 전송결과를 받을 것인지 정의 • 1 : 데이터 복제 없이, 원본만 저장되면 결과 리턴
  • 32.
    32 Latency 최소화 방안(3/3) 지연을 최소화 하기 위한 설정들 (consumer) https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • fetch.min.bytes (default 1) • Broker에서 데이터를 가져오는 최소 size • 1: 1byte만 있어도 요청시 바로 전송 (지연 없음)
  • 33.
    33 Durability 보장 방안– broker (1/4) 메세지 유실을 최소화 – broker (복제가 가장 중요한 요소) https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • 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.
    34 Durability 보장 방안– broker (2/4) 메세지 유실을 최소화 – broker (복제가 가장 중요한 요소) https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • Broker.rack • 하나의 rack에 broker가 동작하지 않도록 설정 • Cloud 기반 서비스에서 broker가 각각 다른 zone에 구동되도록 함. • 안정성은 높아지지만 데이터 복제시 NW 부하 증가. • unclean.leader.election.enable • Broker가 죽었을 때, OSR replica도 leader로 선택될 수 있도록 설정 (true) • OSR(out-of sync replica) : 죽은 broker의 최신 메세지를 복사히지 못한 replica à 데이 터 유실 가능. • 유실보다는 서비스 가용성을 높이는 경우 (true) • 유실을 최소화 하느 경우 (false)
  • 35.
    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 Durability 보장 방안 – broker (3/4)
  • 36.
    36 Durability 보장 방안– broker (4/4) 메세지 유실을 최소화 – broker (복제가 가장 중요한 요소) https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • log.flush.interval.ms / log.flush.interval.messages • 입력된 message를 memory(page cache)에서 disk로 저장하는 수준 • 값이 클수록 Disk I/O가 적게 발생 à 메모리 데이터 유실 가능 • 값이 작으면 Disk I/O 많이 발생 à 메모리 데이터 유실 거의 없음
  • 37.
    37 Durability 보장 방안– Producer (1/2) 메세지 유실을 최소화 – producer https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • acks = all (acks = -1 동일) • 모든 replica에 복제가 완료된 후, producer에 ack 리턴 • acks = all이면, min.insync.replicas = replication.factor 동일하게 설정 • min.insync.replicas : ISR상태를 가지는 replica의 최소 개수 • 즉, producer에 응답하기 위한 replica의 ISR 최소 개수 (복제된 수)
  • 38.
    38 Durability 보장 방안– Producer (2/2) 메세지 유실을 최소화 – producer https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • retries • Producer의 전송실패시 자동으로 재전송하는 회수 • API의 callback i/f인 onComplete()로 직적 코딩 가능 • Retry시 고려사항 • 메세지 중복 가능성 : 일시적 오류로 producer가 2번 전송 가능 • 메세지 순서 변경 가능 • 한번에 여러 번의 request가 nw에서 대기중 인 경우, • Fail된 request 다음 메세지가 먼저 전송되는 경우 발생 • max.in.flight.requests.per.connection = 1로 설정 (한번에 1개 요청)
  • 39.
    39 Durability 보장 방안– Consumer (1/2) 읽어온 메세지의 위치를 정확하게 기록 (중복 읽기 없도록) https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • 중복 읽기 가능한 상황 • Consumer가 데이터를 읽어오고, • broker에 읽어온 offset 위치를 commit • Consumer에서 읽어온 message를 처리할때 에러 발생(처리 못함) • 해결방안 (auto.commit.enable) • Default(true)로 consumer가 poll() 호출을 하는 시점에, • Offset은 자동으로 commit • False로 변경 • Poll()이후 commitSync() or commitAsync() 호출 후에 • Broker가 Offset을 commit
  • 40.
    40 Durability 보장 방안– SUMMARY 메세지 유실을 최소화 하기 위한 설정 가이드 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • 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.
    41 Availability 보장 방안– Broker (1/2) 장애로 부터 가능한 빠르게 복구하는데 중점 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • 너무 많은 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.
    42 Availability 보장 방안– Broker(2/2) 장애로 부터 가능한 빠르게 복구하는데 중점 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • num.recovery.threads.per.data.dir • Broker가 시작/중지 할 때, 다른 broker와 sync를 맞추기 위해 • log data file을 스캔하는 thread를 실행한다 • 이때 data directory 별로 할당되는 Thread 수 • 값이 크면 à 한번에 여러 log file을 동시처리 가능 (RAID 구성인 경우) • 즉 Broker가 빠르게 구동됨
  • 43.
    43 Availability 보장 방안– Consumer Consumer 장애를 감지하여, 남은 consumer로 partition 재배치 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • session.timeout.ms • Consumer가 비정상적으로 종료되었을 경우, • Broker가 장애로 인지하는 최소시간 • 장애 유형 • Hard failure : SIGKILL (강제 종료) • Soft failure : session time out (대부분의 경우 해당) • Poll()호출 후, consumer에서 처리시간이 오래 걸리는 경우 • JVM GC로 인한 멈춤현상 • 값이 적으면 à 더 빠르게 장애를 감지 (복구 빠름) • 장애가 더 자주 나타남. (조금만 지연되어도, failure 판단) • 가능한 낮은 값을 설정하여, Hard failure를 빠르게 감지하도록 설정 • 고려사항 • 너무 낮게 설정하면, Soft failure까지 감지하여 너무 잦은 에러처리
  • 44.
    44 Availability 보장 방안– SUMMARY Consumer 장애를 감지하여, 남은 consumer로 partition 재배치 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • 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
  • 45.
    성능 테스트 수행시 고려사항
  • 46.
    46 Benchmark Test 고려사항 Benchmarktest 고려사항 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • Benchmark test결과에 따라 • 환경에 맞는 partition 수, cluster size, producer/consumer 수 결정 • Kafka 기본 설정으로 테스트 시작 • Kafka의 default설정에 익숙해 지는 것이 좋다 • Producer 성능에 영향을 주는 종속성 제거 • 외부에서 생성되는 데이터를 사용하지 말고, • 자체 Data generator를 통해 데이터 생성속도 향상 • 1개 서버에 1개 producer 실행 및 JMX Metrics 측정 • Producer를 증가하며 측정 계속 à 적절한 producer 수 결정 • Consumer도 동일하게 측정
  • 47.
    47 Benchmark Test 고려사항 Benchmarktest 고려사항 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • 특정 설정이 성능에 미치는 영향을 확인하라 • 4가지 유형에 따른 설정값 중심 • 각각의 설정값이 측정결과에 미치는 영향을 꼭 확인하고, 다른 값을 변경 • Confluence Control Center 활용 고려 (상용) • http://docs.confluent.io/current/control-center/docs/index.html
  • 48.
  • 49.
    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.
    50 Topics/Partitions 수를 어떻게선택할까? More Partitions Requires More Open File Handles https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/ • 각 Partition은 broker의 특정 directory(log)에 저장됨 • Log segment당 2개의 파일 생성(index , data) • Kafka는 모든 log segment의 index와 data file handler를 오픈 • Partition이 많아지면, OS의 file handler 관련 설정 변경
  • 51.
    51 Topics/Partitions 수를 어떻게선택할까? More Partitions May Increase Unavailability https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/ • 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.
    52 Topics/Partitions 수를 어떻게선택할까? More Partitions May Increase End-to-end Latency https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/ • 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.
    53 Topics/Partitions 수를 어떻게선택할까? More Partitions May Require More Memory In the Client https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/ • 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.
    54 Topics/Partitions 수를 어떻게선택할까? 요약해 보면.. https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/ 많은 partition은 처리량을 높여주지만, 이후에 latency & availability에 잠재적인 문제를 유발할 수 있다. 운영관점에서 지속적인 모니터링 필요