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

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가지 목표에 따른 특징 각 특징에 따른 요건 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에 잠재적인 문제를 유발할 수 있다. 운영관점에서 지속적인 모니터링 필요

Check these out next

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

Recomendados

Más contenido relacionado

Presentaciones para ti(20)

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

Más de SANG WON PARK(15)

Último(20)

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