Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

4.608 Aufrufe

Veröffentlicht am

Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.

[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …

[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임

[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

  1. 1. Apache Kafka 성능 최적화 (Metrics & Configuration Tunning) 2018.11 freepsw 성능 모니터링을 위한 Metric 이해 및 Configuration 튜닝 방안
  2. 2. 2 어떤 성능 목표를 설정할 것인가? 서비스의 특징에 따른 성능목표를 정한 후 파라미터 튜닝 필요 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ 보통 아래 4가지를 목표로 설정하며, 각 항목은 상호 trade-off 관계 모든 목표를 동시에 모두 최적화 할 수 없다.
  3. 3. 3 4가지 목표에 따른 특징 각 특징에 따른 요건 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • Kafka 특성상 많은 데이터를 빠르게 쓰는것은 문제가 없음Throughput • 하나의 메세지를 가능한 빠르게 전달 (실시간 채팅 서비스) • (producer à broker à consumer) Latency • 메세지의 유실을 최소화 • Event 기반 microservice 또는 데이터 수집 파이프라인 Durability • Kafka 서버의 다운타임 최소화 • 장애시 가장 빠르게 복구 해야 하는 서비스 Availability
  4. 4. Kafka 모니터링에 필요한 Metric 이해 (System, Broker, Producer, Consumer)
  5. 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. 6 Kafka Monitoring – System Metrics Kafka server에서 사용하고 있는 자원 현황 및 이상치 감지 https://blog.serverdensity.com/how-to-monitor-kafka/ • Open File Handles, CPU, Network I/O
  7. 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. 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. 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. 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. 11. 요청의 유형 1. Producer • 데이터를 전송하는 요청 2. Fetch-consumer • Consumer가 데이터를 가져오는 요청 3. Fetch-follower • Follower가 새로운 데이터를 복제하기 위한 요청 TotalTimeMs의 구성 - Queue : 요청 큐에 대기한 시간 - Local : leader에 의해 처리된 시간 (원본) - Remote : follower에 의해 처리된 시간(복제) - Response : 응답을 보낸 시간 요청을 처리에 소요된 전체 시간으로, 3가지 요청으로 구분 TotalTimeMs 이해
  12. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. Apache Kafka 성능 최적화 방안 (Throughtput, Latency, Durability, Avalibility)
  22. 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. 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. 24 Consumer 관련 설정들 최적화를 위한 옵션들 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • fetch.min.bytes • auto.commit.enable • session.timeout.ms
  25. 25. 25 Throughput 최대화 방안 – Producer 설정 (1/3) Partition 수를 증가 https://www.confluent.io/blog/optimizing-apache-kafka-deployment/ • Partition 수를 증가 à 분산효과 (partition 수는 어떻게 결정?)
  26. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 45. 성능 테스트 수행 시 고려사항
  46. 46. 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. 47. 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
  48. 48. Topics/Partitions 수를 어떻게 선택할까?
  49. 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. 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. 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. 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. 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. 54 Topics/Partitions 수를 어떻게 선택할까? 요약해 보면.. https://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/ 많은 partition은 처리량을 높여주지만, 이후에 latency & availability에 잠재적인 문제를 유발할 수 있다. 운영관점에서 지속적인 모니터링 필요

×