2019 kafka conference seould에서 발표한 "Apache Kafka 모니터링을 위한 Metrics 이해" 슬라이드 자료
기존 2018년 자료에서 모니터링 관점에서 중요한 metrcis를 중심으로 정리하였고, 2019년 기준으로 추가/변경된 metrics를 반영하였다.
주용 내용은
- 업무에 최적화된 apache kafka 모니터링을 하려면?
- 어떤 정보를 모니터링 해야 할까?
- 적시성 관점의 모니터링 지표 (TotalTimeMs에 대한 세부 구조 이해)
- 안정성 관점의 모니터링 지표 (데이터 유실이 없이 중단없는 서비스)
- 언제 apache kafka 클러스터를 확장해야 할까? (어떤 지표를 봐야 할까?)
위 모든 지표는 producer/broker/consumer 3가지 측면에서 검토하였다.
컨퍼런스 영상 링크 : https://www.youtube.com/watch?v=p2RGsTOCHAg
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
Apache kafka performance(latency)_benchmark_v0.3SANG WON PARK
Apache Kafka를 이용하여 이미지 데이터를 얼마나 빠르게(with low latency) 전달 가능한지 성능 테스트.
최종 목적은 AI(ML/DL) 모델의 입력으로 대량의 실시간 영상/이미지 데이터를 전달하는 메세지 큐로 사용하기 위하여, Drone/제조공정 등의 장비에서 전송된 이미지를 얼마나 빨리 AI Model로 전달 할 수 있는지 확인하기 위함.
그래서 Kafka에서 이미지를 전송하는 간단한 테스트를 진행하였고,
이 과정에서 latency를 얼마나 줄여주는지를 확인해 보았다.(HTTP 프로토콜/Socket과 비교하여)
[현재 까지 결론]
- Apache Kafka는 대량의 요청 처리를 위한 throughtput에 최적화 된 솔루션임.
- 현재는 producer의 몇가지 옵션만 조정하여 테스트한 결과이므로,
- 잠정적인 결과이지만, kafka의 latency를 향상을 위해서는 많은 시도가 필요할 것 같음.
- 즉, 단일 요청의 latency는 확실히 느리지만,
- 대량의 처리를 기준으로 평균 latency를 비교하면 평균적인 latency는 많이 낮아짐.
Test Code : https://github.com/freepsw/kafka-latency-test
고승범(peter.ko) / kakao corp.(인프라2팀)
---
카카오에서는 빅데이터 분석, 처리부터 모든 개발 플랫폼을 이어주는 솔루션으로 급부상한 카프카(kafka)를 전사 공용 서비스로 운영하고 있습니다. 전사 공용 카프카를 직접 운영하면서 경험한 트러블슈팅과 운영 노하우 등을 공유하고자 합니다. 특히 카프카를 처음 접하시는 분들이나 이미 사용 중이신 분들이 많이 궁금해하는 프로듀서와 컨슈머 사용 시의 주의점 등에 대해서도 설명합니다.
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
Apache kafka performance(throughput) - without data loss and guaranteeing dat...SANG WON PARK
Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
Presentation at Strata Data Conference 2018, New York
The controller is the brain of Apache Kafka. A big part of what the controller does is to maintain the consistency of the replicas and determine which replica can be used to serve the clients, especially during individual broker failure.
Jun Rao outlines the main data flow in the controller—in particular, when a broker fails, how the controller automatically promotes another replica as the leader to serve the clients, and when a broker is started, how the controller resumes the replication pipeline in the restarted broker.
Jun then describes recent improvements to the controller that allow it to handle certain edge cases correctly and increase its performance, which allows for more partitions in a Kafka cluster.
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
Apache kafka performance(latency)_benchmark_v0.3SANG WON PARK
Apache Kafka를 이용하여 이미지 데이터를 얼마나 빠르게(with low latency) 전달 가능한지 성능 테스트.
최종 목적은 AI(ML/DL) 모델의 입력으로 대량의 실시간 영상/이미지 데이터를 전달하는 메세지 큐로 사용하기 위하여, Drone/제조공정 등의 장비에서 전송된 이미지를 얼마나 빨리 AI Model로 전달 할 수 있는지 확인하기 위함.
그래서 Kafka에서 이미지를 전송하는 간단한 테스트를 진행하였고,
이 과정에서 latency를 얼마나 줄여주는지를 확인해 보았다.(HTTP 프로토콜/Socket과 비교하여)
[현재 까지 결론]
- Apache Kafka는 대량의 요청 처리를 위한 throughtput에 최적화 된 솔루션임.
- 현재는 producer의 몇가지 옵션만 조정하여 테스트한 결과이므로,
- 잠정적인 결과이지만, kafka의 latency를 향상을 위해서는 많은 시도가 필요할 것 같음.
- 즉, 단일 요청의 latency는 확실히 느리지만,
- 대량의 처리를 기준으로 평균 latency를 비교하면 평균적인 latency는 많이 낮아짐.
Test Code : https://github.com/freepsw/kafka-latency-test
고승범(peter.ko) / kakao corp.(인프라2팀)
---
카카오에서는 빅데이터 분석, 처리부터 모든 개발 플랫폼을 이어주는 솔루션으로 급부상한 카프카(kafka)를 전사 공용 서비스로 운영하고 있습니다. 전사 공용 카프카를 직접 운영하면서 경험한 트러블슈팅과 운영 노하우 등을 공유하고자 합니다. 특히 카프카를 처음 접하시는 분들이나 이미 사용 중이신 분들이 많이 궁금해하는 프로듀서와 컨슈머 사용 시의 주의점 등에 대해서도 설명합니다.
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
Apache kafka performance(throughput) - without data loss and guaranteeing dat...SANG WON PARK
Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
Presentation at Strata Data Conference 2018, New York
The controller is the brain of Apache Kafka. A big part of what the controller does is to maintain the consistency of the replicas and determine which replica can be used to serve the clients, especially during individual broker failure.
Jun Rao outlines the main data flow in the controller—in particular, when a broker fails, how the controller automatically promotes another replica as the leader to serve the clients, and when a broker is started, how the controller resumes the replication pipeline in the restarted broker.
Jun then describes recent improvements to the controller that allow it to handle certain edge cases correctly and increase its performance, which allows for more partitions in a Kafka cluster.
Producer Performance Tuning for Apache KafkaJiangjie Qin
Kafka is well known for high throughput ingestion. However, to get the best latency characteristics without compromising on throughput and durability, we need to tune Kafka. In this talk, we share our experiences to achieve the optimal combination of latency, throughput and durability for different scenarios.
Apache Kafka becoming the message bus to transfer huge volumes of data from various sources into Hadoop.
It's also enabling many real-time system frameworks and use cases.
Managing and building clients around Apache Kafka can be challenging. In this talk, we will go through the best practices in deploying Apache Kafka
in production. How to Secure a Kafka Cluster, How to pick topic-partitions and upgrading to newer versions. Migrating to new Kafka Producer and Consumer API.
Also talk about the best practices involved in running a producer/consumer.
In Kafka 0.9 release, we’ve added SSL wire encryption, SASL/Kerberos for user authentication, and pluggable authorization. Now Kafka allows authentication of users, access control on who can read and write to a Kafka topic. Apache Ranger also uses pluggable authorization mechanism to centralize security for Kafka and other Hadoop ecosystem projects.
We will showcase open sourced Kafka REST API and an Admin UI that will help users in creating topics, re-assign partitions, Issuing
Kafka ACLs and monitoring Consumer offsets.
This talk covers Kafka cluster sizing, instance type selections, scaling operations, replication throttling and more. Don’t forget to check out the Kafka-Kit repository.
https://www.youtube.com/watch?time_continue=2613&v=7uN-Vlf7W5E
Performance Tuning RocksDB for Kafka Streams' State Stores (Dhruba Borthakur,...confluent
RocksDB is the default state store for Kafka Streams. In this talk, we will discuss how to improve single node performance of the state store by tuning RocksDB and how to efficiently identify issues in the setup. We start with a short description of the RocksDB architecture. We discuss how Kafka Streams restores the state stores from Kafka by leveraging RocksDB features for bulk loading of data. We give examples of hand-tuning the RocksDB state stores based on Kafka Streams metrics and RocksDB’s metrics. At the end, we dive into a few RocksDB command line utilities that allow you to debug your setup and dump data from a state store. We illustrate the usage of the utilities with a few real-life use cases. The key takeaway from the session is the ability to understand the internal details of the default state store in Kafka Streams so that engineers can fine-tune their performance for different varieties of workloads and operate the state stores in a more robust manner.
Troubleshooting Kafka's socket server: from incident to resolutionJoel Koshy
LinkedIn’s Kafka deployment is nearing 1300 brokers that move close to 1.3 trillion messages a day. While operating Kafka smoothly even at this scale is testament to both Kafka’s scalability and the operational expertise of LinkedIn SREs we occasionally run into some very interesting bugs at this scale. In this talk I will dive into a production issue that we recently encountered as an example of how even a subtle bug can suddenly manifest at scale and cause a near meltdown of the cluster. We will go over how we detected and responded to the situation, investigated it after the fact and summarize some lessons learned and best-practices from this incident.
KSQL Performance Tuning for Fun and Profit ( Nick Dearden, Confluent) Kafka S...confluent
Ever wondered just how many CPU cores of KSQL Server you need to provision to handle your planned stream processing workload ? Or how many GBits of aggregate network bandwidth, spread across some number of processing threads, you'll need to deal with combined peak throughput of multiple queries ? In this talk we'll first explore the basic drivers of KSQL throughput and hardware requirements, building up to more advanced query plan analysis and capacity-planning techniques, and review some real-world testing results along the way. Finally we will recap how and what to monitor to know you got it right!
Common issues with Apache Kafka® Producerconfluent
Badai Aqrandista, Confluent, Senior Technical Support Engineer
This session will be about a common issue in the Kafka Producer: producer batch expiry. We will be discussing the Kafka Producer internals, its common causes, such as a slow network or small batching, and how to overcome them. We will also be sharing some examples along the way!
https://www.meetup.com/apache-kafka-sydney/events/279651982/
What is the State of my Kafka Streams Application? Unleashing Metrics. | Neil...HostedbyConfluent
"Just as the Apache Kafka Brokers provide JMX metrics to monitor your cluster's health, Kafka Streams provides a rich set of metrics for monitoring your application's health and performance. The metrics to observe for a given use-case of Kafka Streams will vary significantly from application to application. Learning how to build and customize monitoring of those applications will help you maintain a healthy Kafka Streams ecosystem.
Takeaways
* An analysis and overview of the provided metrics, including the new end-to-end metrics of Kafka Streams 2.7.
* See how to extract metrics from your application using existing JMX tooling.
* Walkthrough how to build a dashboard for observing those metrics.
* Explore options of how to add additional JMX resources and Kafka Stream metrics to your application.
* How to verify you built your dashboard correctly by creating a data control set to validate your dashboard.
* Go beyond what you can collect from the Kafka Stream metrics."
Jay Kreps is a Principal Staff Engineer at LinkedIn where he is the lead architect for online data infrastructure. He is among the original authors of several open source projects including a distributed key-value store called Project Voldemort, a messaging system called Kafka, and a stream processing system called Samza. This talk gives an introduction to Apache Kafka, a distributed messaging system. It will cover both how Kafka works, as well as how it is used at LinkedIn for log aggregation, messaging, ETL, and real-time stream processing.
Kafka is a high-throughput, fault-tolerant, scalable platform for building high-volume near-real-time data pipelines. This presentation is about tuning Kafka pipelines for high-performance.
Select configuration parameters and deployment topologies essential to achieve higher throughput and low latency across the pipeline are discussed. Lessons learned in troubleshooting and optimizing a truly global data pipeline that replicates 100GB data under 25 minutes is discussed.
How We Reduced Performance Tuning Time by Orders of Magnitude with Database O...ScyllaDB
Doing performance tuning on a massively distributed database is never an easy task. This is especially true for TiDB, an open-source, cloud-native NewSQL database for elastic scale and real-time analytics, because it consists of multiple components and each component has plenty of metrics.
Like many distributed systems, TiDB uses Prometheus to store the monitoring and performance metrics and Grafana to visualize these metrics. Thanks to these two open source projects, it is easy for TiDB developers to add monitoring and performance metrics. However, as the metrics increase, the learning curve becomes steeper for TiDB users to gain performance insights. In this talk, we will share how we measure latency in a distributed system using a top-down (holistic) approach, and why we introduced "tuning by database time" and "tuning by color" into TiDB. The new methodologies and Grafana dashboard help reduce the time and the requirement of expertise in performance tuning by orders of magnitude.
Cruise Control: Effortless management of Kafka clustersPrateek Maheshwari
Kafka has become the de facto standard for streaming data with high-throughput, low-latency, and fault-tolerance. However, its rising adoption raises new challenges. In particular, the growing cluster sizes, increasing volume and diversity of user traffic, and aging network and server components induce an overhead in managing the system. This overhead makes it infeasible for human operators to constantly monitor, identify, and mitigate issues. The resulting utilization imbalance across brokers leads to unpredictable client performance due to the high variation in their throughput and latency. Finally, properly expanding, shrinking, or upgrading clusters also incurs a management overhead. Hence, adopting a principled approach to manage Kafka clusters is integral to the sustainability of the infrastructure.
This talk will describe how LinkedIn alleviates the management overhead of large-scale Kafka clusters using Cruise Control. To this end, first, we will discuss the reactive and proactive techniques that Cruise Control uses to support admin operations for cluster maintenance, enable anomaly detection with self-healing, and provide real-time monitoring for Kafka clusters. Next, we will examine how Cruise Control performs in production. Finally, we will conclude with questions and further discussion.
RabbitMQ/ActiveMQ 와 같은 비동기 메시징 미들웨어를 이용하여 다량의 서버를 orchestration(command & control) 할 수 있는 mcollective에 대한 한글 ppt 자료입니다. 상세한 내용은 http://wiki.tunelinux.pe.kr/x/LQAy 를 참고하시면 됩니다.
Producer Performance Tuning for Apache KafkaJiangjie Qin
Kafka is well known for high throughput ingestion. However, to get the best latency characteristics without compromising on throughput and durability, we need to tune Kafka. In this talk, we share our experiences to achieve the optimal combination of latency, throughput and durability for different scenarios.
Apache Kafka becoming the message bus to transfer huge volumes of data from various sources into Hadoop.
It's also enabling many real-time system frameworks and use cases.
Managing and building clients around Apache Kafka can be challenging. In this talk, we will go through the best practices in deploying Apache Kafka
in production. How to Secure a Kafka Cluster, How to pick topic-partitions and upgrading to newer versions. Migrating to new Kafka Producer and Consumer API.
Also talk about the best practices involved in running a producer/consumer.
In Kafka 0.9 release, we’ve added SSL wire encryption, SASL/Kerberos for user authentication, and pluggable authorization. Now Kafka allows authentication of users, access control on who can read and write to a Kafka topic. Apache Ranger also uses pluggable authorization mechanism to centralize security for Kafka and other Hadoop ecosystem projects.
We will showcase open sourced Kafka REST API and an Admin UI that will help users in creating topics, re-assign partitions, Issuing
Kafka ACLs and monitoring Consumer offsets.
This talk covers Kafka cluster sizing, instance type selections, scaling operations, replication throttling and more. Don’t forget to check out the Kafka-Kit repository.
https://www.youtube.com/watch?time_continue=2613&v=7uN-Vlf7W5E
Performance Tuning RocksDB for Kafka Streams' State Stores (Dhruba Borthakur,...confluent
RocksDB is the default state store for Kafka Streams. In this talk, we will discuss how to improve single node performance of the state store by tuning RocksDB and how to efficiently identify issues in the setup. We start with a short description of the RocksDB architecture. We discuss how Kafka Streams restores the state stores from Kafka by leveraging RocksDB features for bulk loading of data. We give examples of hand-tuning the RocksDB state stores based on Kafka Streams metrics and RocksDB’s metrics. At the end, we dive into a few RocksDB command line utilities that allow you to debug your setup and dump data from a state store. We illustrate the usage of the utilities with a few real-life use cases. The key takeaway from the session is the ability to understand the internal details of the default state store in Kafka Streams so that engineers can fine-tune their performance for different varieties of workloads and operate the state stores in a more robust manner.
Troubleshooting Kafka's socket server: from incident to resolutionJoel Koshy
LinkedIn’s Kafka deployment is nearing 1300 brokers that move close to 1.3 trillion messages a day. While operating Kafka smoothly even at this scale is testament to both Kafka’s scalability and the operational expertise of LinkedIn SREs we occasionally run into some very interesting bugs at this scale. In this talk I will dive into a production issue that we recently encountered as an example of how even a subtle bug can suddenly manifest at scale and cause a near meltdown of the cluster. We will go over how we detected and responded to the situation, investigated it after the fact and summarize some lessons learned and best-practices from this incident.
KSQL Performance Tuning for Fun and Profit ( Nick Dearden, Confluent) Kafka S...confluent
Ever wondered just how many CPU cores of KSQL Server you need to provision to handle your planned stream processing workload ? Or how many GBits of aggregate network bandwidth, spread across some number of processing threads, you'll need to deal with combined peak throughput of multiple queries ? In this talk we'll first explore the basic drivers of KSQL throughput and hardware requirements, building up to more advanced query plan analysis and capacity-planning techniques, and review some real-world testing results along the way. Finally we will recap how and what to monitor to know you got it right!
Common issues with Apache Kafka® Producerconfluent
Badai Aqrandista, Confluent, Senior Technical Support Engineer
This session will be about a common issue in the Kafka Producer: producer batch expiry. We will be discussing the Kafka Producer internals, its common causes, such as a slow network or small batching, and how to overcome them. We will also be sharing some examples along the way!
https://www.meetup.com/apache-kafka-sydney/events/279651982/
What is the State of my Kafka Streams Application? Unleashing Metrics. | Neil...HostedbyConfluent
"Just as the Apache Kafka Brokers provide JMX metrics to monitor your cluster's health, Kafka Streams provides a rich set of metrics for monitoring your application's health and performance. The metrics to observe for a given use-case of Kafka Streams will vary significantly from application to application. Learning how to build and customize monitoring of those applications will help you maintain a healthy Kafka Streams ecosystem.
Takeaways
* An analysis and overview of the provided metrics, including the new end-to-end metrics of Kafka Streams 2.7.
* See how to extract metrics from your application using existing JMX tooling.
* Walkthrough how to build a dashboard for observing those metrics.
* Explore options of how to add additional JMX resources and Kafka Stream metrics to your application.
* How to verify you built your dashboard correctly by creating a data control set to validate your dashboard.
* Go beyond what you can collect from the Kafka Stream metrics."
Jay Kreps is a Principal Staff Engineer at LinkedIn where he is the lead architect for online data infrastructure. He is among the original authors of several open source projects including a distributed key-value store called Project Voldemort, a messaging system called Kafka, and a stream processing system called Samza. This talk gives an introduction to Apache Kafka, a distributed messaging system. It will cover both how Kafka works, as well as how it is used at LinkedIn for log aggregation, messaging, ETL, and real-time stream processing.
Kafka is a high-throughput, fault-tolerant, scalable platform for building high-volume near-real-time data pipelines. This presentation is about tuning Kafka pipelines for high-performance.
Select configuration parameters and deployment topologies essential to achieve higher throughput and low latency across the pipeline are discussed. Lessons learned in troubleshooting and optimizing a truly global data pipeline that replicates 100GB data under 25 minutes is discussed.
How We Reduced Performance Tuning Time by Orders of Magnitude with Database O...ScyllaDB
Doing performance tuning on a massively distributed database is never an easy task. This is especially true for TiDB, an open-source, cloud-native NewSQL database for elastic scale and real-time analytics, because it consists of multiple components and each component has plenty of metrics.
Like many distributed systems, TiDB uses Prometheus to store the monitoring and performance metrics and Grafana to visualize these metrics. Thanks to these two open source projects, it is easy for TiDB developers to add monitoring and performance metrics. However, as the metrics increase, the learning curve becomes steeper for TiDB users to gain performance insights. In this talk, we will share how we measure latency in a distributed system using a top-down (holistic) approach, and why we introduced "tuning by database time" and "tuning by color" into TiDB. The new methodologies and Grafana dashboard help reduce the time and the requirement of expertise in performance tuning by orders of magnitude.
Cruise Control: Effortless management of Kafka clustersPrateek Maheshwari
Kafka has become the de facto standard for streaming data with high-throughput, low-latency, and fault-tolerance. However, its rising adoption raises new challenges. In particular, the growing cluster sizes, increasing volume and diversity of user traffic, and aging network and server components induce an overhead in managing the system. This overhead makes it infeasible for human operators to constantly monitor, identify, and mitigate issues. The resulting utilization imbalance across brokers leads to unpredictable client performance due to the high variation in their throughput and latency. Finally, properly expanding, shrinking, or upgrading clusters also incurs a management overhead. Hence, adopting a principled approach to manage Kafka clusters is integral to the sustainability of the infrastructure.
This talk will describe how LinkedIn alleviates the management overhead of large-scale Kafka clusters using Cruise Control. To this end, first, we will discuss the reactive and proactive techniques that Cruise Control uses to support admin operations for cluster maintenance, enable anomaly detection with self-healing, and provide real-time monitoring for Kafka clusters. Next, we will examine how Cruise Control performs in production. Finally, we will conclude with questions and further discussion.
RabbitMQ/ActiveMQ 와 같은 비동기 메시징 미들웨어를 이용하여 다량의 서버를 orchestration(command & control) 할 수 있는 mcollective에 대한 한글 ppt 자료입니다. 상세한 내용은 http://wiki.tunelinux.pe.kr/x/LQAy 를 참고하시면 됩니다.
Cloud-Barista 제1차 오픈세미나 : CB-Dragonfly-멀티 클라우드 통합 모니터링 프레임워크(1st Open Seminar...Cloud-Barista Community
멀티 클라우드 서비스 공통 프레임워크 기술(Multi-Cloud Service Common Framework)
- 커뮤니티 사이트(Community Site) : https://github.com/cloud-barista
주요 내용 : 멀티 클라우드 통합 모니터링 기술(CB-Dragonfly)
- CB-Dragonfly 개요 및 차별성
- CB-Dragonfly 주요 기능 및 모듈
- CB-Dragonfly 개발 추진 방향
1일 수천대의 서버에서 발생하는 30~50억건의 Log와 Metric을 처리하는 Planet Mon 을 지탱하는 기술인 Collection(Collectd, NXlog), Transport(Kakfa, Logstash), Log Stream Analytics, Storage(Elasticsearch), Visualization을 구성하는 Architecture에 대해 설명드리고 제가 개발한 Log Stream Analytics 서버들의 구현 기술에 대해 좀더 상세히 설명합니다.
Similar to Understanding of Apache kafka metrics for monitoring (20)
데이터를 둘러싼 정책과, 기업과 기술의 진화는 빠르게 변화하고 있으며, 모든 지향점은 기업들이 다양한 데이터를 활용하여 경쟁력을 확보하고 이를 통해 AI기반의 혁신을 하고자 하는데 있다.
이 과정에서 수 많은 기업의 업무 전무가, 데이터 사이언티스트 등이 다양한 기업의 혁신을 지원할 수 있는 AI 모델을 검증하는 과정을 거치게 됩니다.
하지만, 이렇게 수 많은 AI 모델이 실제 비즈니스에 적용되기 위해서는 인프라, 및 서비스 관점의 기술이 반드시 필요하게 됩니다.
MLOps는 기업에 필요한 혁신적인 아이디어(AI Model)을 적시에 비즈니스 환경에 적용할 수 있도록 지원하는 기술 및 트렌드 입니다.
주요 내용은
- 데이터를 둘러싼 환경의 변화
- 기업의 AI Model 적용시 마주하는 현실
- MLOps가 해결 가능한 문제들
- MLOps의 영역별 주요 기술들
- MLOps 도입 시 기업의 AI 환경은 어떻게 변할까?
- AI 모델을 비즈니스 환경에 적용(배포)한다는 것은?
2021년 12월 코리아 데이터 비즈니스 트렌드(데이터산업진흥원 주최)에서 발표한 내용을 공유 가능한 부분만 정리함.
발표 영상 참고 : https://www.youtube.com/watch?v=lL-QtEzJ3WY
Cloud DW technology trends and considerations for enterprises to apply snowflakeSANG WON PARK
올해 처음 오프라인으로 진행된 "한국 데이터 엔니지어 모임"에서 발표한 cloud dw와 snowflake라는 주제로 발표한 내용을 정리하여 공유함. (2022.07)
[ 발표 주제 ]
Cloud DW 기술 트렌드와 Snowflake 적용
- Modern Data Stack에서 Cloud DW의 역할
- 기존 Data Lake + DW와 무엇이 다른가?
- Data Engineer 관점에서 어떻게 사용하면 좋을까? (기능/성능/비용 측면의 장점/단점)
[ 주요 내용 ]
- 최근 많은 Data Engineer가 기존 기술 스택(Hadoop, Spark, DW 등)의 기술적/운영적 한계를 극복하기 위한 고민중.
- 특히 Cloud의 장점과 운영 및 성능을 고려한 Cloud DW(AWS Redshift, GCP BigQuery, DataBricks, Snowflake)를 고려
- 이 중 Snowflake를 실제 프로젝트에 적용한 경험과 기술적인 특징/장점/단점을 공유하고자 함.
작년부터 정부의 데이터 정책 변화와 Cloud 기반의 기술 변화 가속화로 기업의 데이터 환경에도 많은 변화가 발생하고 있고, 기업들은 이에 적응하기 위한 다양한 시도를 하고 있다.
그 중심에 cloud dw (또는 Lake house)가 위치하고 있으며, 이를 기반으로 통합 데이터 플랫폼으로의 아키텍처로 변화하고 있다. 하지만, 아직까지 기존 DW 제품과 주요 CSP(AWS, GCP, Azure)의 제품군을 다양하게 시도하고 있으나, 기대와 다르게 생각보나 낮은 성능 또는 비싼 사용료, 운영의 복잡성으로 인한 많은 시행착오를 거치고 있다.
이 상황에서 작년에 처음 검토한 snowflake의 다양한 기능들이 기업들의 고민과 문제를 상당부분 손쉽게 해결할 수 있다는 것을 확인할 수 있었고, 이를 이용하여 실제 많은 기업들에게 적용하기 위한 POC를 수행하거나, 실제 적용하는 프로젝트를 수행하게 되었다.
본 발표 내용은 이러한 경험을 기반으로 기업(그리고 실제 업무를 수행할 Data Engineer) 관점에서 snowflake가 어떻게 문제를 해결할 수 있는지 cloud dw를 도입/활용/확장 하는 단계별로 문제와 해결 방안을 중심으로 설명하였다.
https://blog.naver.com/freepsw?Redirect=Update&logNo=222815591918
The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)SANG WON PARK
2020년 데이터산업진흥원에서 발표한 자료를 일부 편집하여 공유함.
2020년 당시에 Data Platform에서 AI lifecycle를 효율적으로 지원하는 platform을 적극적으로 검토 및 설계하는 작업을 진행하였고, 이 때 검토 및 활용했던 기술들을 기업 관점에서 필요한 내용을 기준으로 정리하였다.
기업들은 전통적인 방식으로의 혁신에 한계를 체감하고 있으며, 최근 AI기반으로 성공적인 혁신(비즈니스 강화, 새로운 비즈니스로 전환 등)에 성공한 기업들을 빠르게 벤치마크 하고 있다.
이렇게 AI 기반으로 기업을 혁신하는 것은 고도화된 AI 모델의 도입으로 해결되지 않으며, 수많은 기술들의 최적화된 조합 및 활용이 필요하다.
이 자료에서는 그 중 AI모델에 핵심적인 데이터를 적시에, 고품질의 형태로, 빠르고 안정적으로 제공할 수 기술 트렌드를 소개한다.
전체 내용은
- AI기반 혁신이란?
- 혁신을 위해서는 어떤 점이 어려운가?
- 고품질 데이터 확보 기술
- 빠르게 AI 모델을 학습하는 기술
- 적시에 다양한 AI 모델을 비즈니스에 적용하는 기술
2020년 기준으로 작성된 자료라, 일부 기술 트렌드가 반영되지 않을 수 있으나 아직까지 많은 기업들이 고민하고 해결하고자 하는 영역이라 참고할 수 있을 것 같다.
이 내용을 기준으로 발표한 영상 링크 : https://www.youtube.com/watch?v=OVm4-uk59ZA
Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )SANG WON PARK
몇년 전부터 Data Architecture의 변화가 빠르게 진행되고 있고,
그 중 Cloud DW는 기존 Data Lake(Hadoop 기반)의 한계(성능, 비용, 운영 등)에 대한 대안으로 주목받으며,
많은 기업들이 이미 도입했거나, 도입을 검토하고 있다.
본 자료는 이러한 Cloud DW에 대해서 개념적으로 이해하고,
시장에 존재하는 다양한 Cloud DW 중에서 기업의 환경에 맞는 제품이 어떤 것인지 성능/비용 관점으로 비교했다.
- 왜기업들은 CloudDW에주목하는가?
- 시장에는어떤 제품들이 있는가?
- 우리Biz환경에서는 어떤 제품을 도입해야 하는가?
- CloudDW솔루션의 성능은?
- 기존DataLake(EMR)대비 성능은?
- 유사CloudDW(snowflake vs redshift) 대비성능은?
앞으로도 Data를 둘러싼 시장은 Cloud DW를 기반으로 ELT, Mata Mesh, Reverse ETL등 새로운 생테계가 급속하게 발전할 것이고,
이를 위한 데이터 엔지니어/데이터 아키텍트 관점의 기술적 검토와 고민이 필요할 것 같다.
https://blog.naver.com/freepsw/222654809552
AWS EMR을 사용하면서 비용을 최적화하기 위해 필요한 다양한 관점의 방안을 검토하여 정리한 자료.
비용 최적화 대상은 zeppelin/jupyter notebook과 apache spark를 활용하는 서비스를 대상으로 하였으며, 해당 작업이 aws emr에서 어떻게 동작하는지 내부 구조을 파악하여 확인함.
- AWS EMR이란?
- AWS EMR의 과금 방식은?
- 어떻게 비용을 최적화 할 것인가?
- 최적의 EMR 클러스터 구성 방안
- 가성비 높은 Instance 선정 방안
- Apache Spark 성능 개선 방안
가장 중요한 것은 실행할 job의 자원사용량/성능을 모니터링하고, 이에 맞게 자원을 최적화하는 것이 필요함.
xgboost를 이해하기 위해서 찾아보다가 내가 궁금한 내용을 따로 정리하였으나, 역시 구체적인 수식은 아직 모르겠다.
요즘 Kaggle에서 유명한 Xgboost가 뭘까?
Ensemble중 하나인 Boosting기법?
Ensemble 유형인 Bagging과 Boosting 차이는?
왜 Ensemble이 low bias, high variance 모델인가?
Bias 와 Variance 관계는?
Boosting 기법은 어떤게 있나?
Xgboost에서 사용하는 CART 알고리즘은?
Machine Learning Foundations (a case study approach) 강의 정리SANG WON PARK
실제 비즈니스에서 많이 활용되는 사례를 중심으로 어떻게 기존 데이터를 이용하여 알고리즘을 선택하고, 학습하여, 예측모델을 구축 하는지 jupyter notebook을 이용하여 실제 코드를 이용하여 실습할 수 있다.
강의 초반에 강조하는 것 처럼, 머신러닝 알고리즘은 나중에 자세히 설명하는 과정이 따로 있고, 이번 강의는 실제 어떻게 활용하는지에 완전히 초점이 맞추어져 있어서, 알고리즘은 아주 간략한 수준으로 설명해 준다. (좀 더 구체적인 내용은 심화과정이 따로 있음)
http://blog.naver.com/freepsw/221113685916 참고
https://github.com/freepsw/coursera/tree/master/ML_Foundations/A_Case_Study 코드 샘플
Coursera Machine Learning (by Andrew Ng)_강의정리SANG WON PARK
단순히 공식으로 설명하지 않고, 실제 코드 및 샘플데이터를 이용하여 수식의 결과가 어떻게 적용되는지 자세하게 설명하고 있다.
처음 week1 ~ week4 까지는 김성훈 교수님의 "모두를 위한 딥러닝"에서 한번 이해했던 내용이라 좀 쉽게 진행했고, 나머지는 기초가 부족한 상황이라 다른 자료를 꽤 많이 참고하면서 학습해야 했다.
여러 도서나 강의를 이용하여 머신러닝을 학습하려고 했었는데, 이 강의만큼 나에게 맞는것은 없었던거 같다. 특히 Octave code를 이용한 실습자료는 나중에도 언제든 활용가능할 것 같다.
Week1
Linear Regression with One Variable
Linear Algebra - review
Week2
Linear Regression with Multiple Variables
Octave[incomplete]
Week3
Logistic Regression
Regularization
Week4
Neural Networks - Representation
Week5
Neural Networks - Learning
Week6
Advice for applying machine learning techniques
Machine Learning System Design
Week7
Support Vector Machines
Week8
Unsupervised Learning(Clustering)
Dimensionality Reduction
Week9
Anomaly Detection
Recommender Systems
Week10
Large Scale Machine Learning
Week11
Application Example - Photo OCR
Coursera Machine Learning by Andrew NG 강의를 들으면서, 궁금했던 내용을 중심으로 정리.
내가 궁금했던건, 데이터를 분류하는 Decision boundary를 만들때...
- 왜 가중치(W)와 decision boundary가 직교해야 하는지?
- margin은 어떻게 계산하는지?
- margin은 어떻게 최대화 할 수 있는지?
- 실제로 margin을 최대화 하는 과정의 수식은 어떤지?
- 비선형 decision boundary를 찾기 위해서 어떻게 kernel을 이용하는지?...
http://blog.naver.com/freepsw/221032379891
코드로 이해하는 Back_propagation(cs231n)SANG WON PARK
여러 샘플들을 참고하다 보니, tensorflow를 사용하지 않는 경우에는 직접 gradient를 계산하여 back propagation을 하도록 구현한 코드가 많다. 내가 직접 구현할 필요는 없더라도, 좀 더 명확하게 이해할 필요는 있을 것 같아서 cn231n note에서 제공하는 코드와 설명을 정리.
http://blog.naver.com/freepsw/220928184473
http://cs231n.github.io/neural-networks-case-study/ 참고
데이터를 작게 생성하여, 직접 코드와 생성된 데이터를 확인하면서 좀 더 직관적으로 이해하는 과정으로 정리하다보니, 코드보다 설명이 더 많다... 아직도 명확하지는 않지만 나름대로 정리는 되었다.
모두를 위한 Deep Reinforcement Learning 강의를 요약정리
http://hunkim.github.io/ml/
실습에 사용된 코드
https://github.com/freepsw/tensorflow_examples/tree/master/20.RL_by_SungKim
12. 12
Producer Consumer
Broker
Broker
Broker
ü 얼마나 빨리/많이 보내고 있는가?
ü Producer에서 Consumer까지 얼마나 빨리/많이 전달되는지 확인 필요
ü 얼마나 빨리/많이 수신하고 있는가?
ü Producer와 Consumer 양쪽의 요청을 얼마나 빨리/많이 처리하고 있는가?
적시성을 위해 확인해야 할 Metrics 유형은?
13. 13
Producer Metrics (Kafka 0.8.2 이후)
Metric Comments Alert
request-rate • 초당 요청(to broker) 건수
response-rate • 초당 응답(from broker) 건수
요청과 응답 비율이
유사해야 함.
outgoing-byte-rate • 초당 Broker로 전송한 bytes 처리량 개선 확인
io-ratio • I/O 작업을 위해 I/O thread가 사용한 시간 비율
io-wait-ratio • I/O thread가 waiting에 소요한 시간 비율
https://www.confluent.io/blog/optimizing-apache-kafka-deployment/
14. 14
https://blog.serverdensity.com/how-to-monitor-kafka/
Metric Comments Alert
records-lag-max
• 최신의 메세지 offset값과, consumer가 읽어간 offset값의 최대 차이
• 값이 증가한다면, consumer group이 데이터를 빠르게 가져가지 못함
MaxLag > (자체 기준)
fetch-rate
• Broker에 초당 요청(request call)하는 회수
• 만약 consumer가 중지되었다면, 0으로 낮아질 것이다.
fetch-rate < 0.5.
records-consumed-rate • 초당 읽은 메세지(record) 개수
bytes-consumed-rate • 초당 읽은 byte size
commit-rate • Consumer가 kafka에 offset을 commit한 비율 (초당 commit수)
Consumer Metrics (Kafka 0.9.0.0 이후)
전체 Consumer, Consumer Group, Topic 별 구분하여 모니터링 가능
15. 15
https://blog.serverdensity.com/how-to-monitor-kafka/
Metric Comments Alert
MessagesInPerSec
• 초당 유입되는 메세지 count (많을 수록 처리성능이 높음)
• (kafka.server: type=BrokerTopicMetrics)
BytesInPerSec / BytesOutPerSec
• 초당 유입 & 유출 되는 byte (많을 수록 처리성능이 높음)
• (kafka.server: type=BrokerTopicMetrics)
RequestsPerSec
• 초당 요청 건수 {Produce|FetchConsumer|FetchFollower}
• (kafka.network: type=RequestMetrics)
TotalTimeMs
• 하나의 요청을 처리하는데 소요된 전체 시간
{Produce|FetchConsumer|FetchFollower}
• 구간별로 분할하여 시간 측정 가능
• (kafka.network: type=RequestMetrics)
Broker Metrics
Cluster, Broker, Topic 단위로 구분하여 모니터링 가능
16. 요청을 처리에 소요된 전체 시간으로, 3가지 요청으로 구분
TotalTimeMs 란?
Producer
Broker
Producer 관점 Queue
Time
Local
Time
Broker
Remote
Time
Follower
Local Time
Response
Time
Consumer 관점 Consumer
Queue
Time
Response
Time
Local
Time
Follower 관점
17. 17
TotalTimeMs이 너무 오래 걸리면, Bottleneck이 어디서 발생하는지 상세 metrics 확인
Metric Comments
RequestQueueTimeMs
• 요청 큐에서 기다리는 시간을 producer, consumer fetch, follower fetch별로 측정
• 높은 값(대기 시간이 길어지는 현상)은 I/O thread가 부족하거나, CPU 부하 예상
• (kafka.network:type=RequestMetrics)
LocalTimeMs
• 전달된 요청을 leader에서 처리하는 시간. (leader가 local data 처리)
• 높은 값은 disk i/o가 낮음을 의미
• (kafka.network:type=RequestMetrics)
RemoteTimeMs
• 요청이 Folllower를 기다리는 시간
• 높은 값은 NW 연결이 늦어짐을 의미
• Fetch 요청에서 이 값이 높은 것은, 가져올 데이터가 많지 않음을 의미할 수 있음
• (kafka.network:type=RequestMetrics)
ResponseQueueTimeMs
• 요청이 응답 큐에서 대기하는 시간.
• 높은 값은 NW thread가 부족함을 의미.
• (kafka.network:type=RequestMetrics)
ResponseSendTimeMs
• Client의 요청에 응답한 시간.
• 높은 값은 NW thread 또는 CPU가 부족하거나, NW부하가 높음을 의미
• (kafka.network:type=RequestMetrics)
TotalTimeMs 란? (세부 Metrics 확인)
19. 19
Broker
(Active Controrller)
ü 데이터 처리의 핵심인 Partition이 장애없이 정상적으로 운영되는가?
ü Server의 불필요한 Disk I/O 가 발행하지 않는가?
안정성을 위해 확인해야 할 Metrics 유형은?
Broker
Broker
Partition
(Leader)
Partition
(Follower)
Partition
(Follower)
장애
발생시
20. 20
Kafka Server에서 Swap이 발생하면, Disk I/O가 발생하여 성능에 영향
https://blog.serverdensity.com/how-to-monitor-kafka/
Swap이 발생하는 원인
• Kafka 구동시 설정한 Heap Memory를 초과하는 경우
• 데이터를 swap(Disk) 공간으로 복사하게 됨. (프로그램
이 중지되지 않도록 하는 역할)
• 한번 swap공간으로 이동하면, 다시 메모리로 돌아오게
할 수 없다. à 성능 저하 유발
Swap 발생 조건 변경
• vm.swappiness
• 메모리에서 swap으로 이동을 언제 할지 결정
• vm.swappiness = 10 à 메모리 사용률 90% 이상일 때
• Kafka 성능을 극대화 하려면,
• vm.swappiness = 0 à 메모리에서만 처리하도록 설정
System Metrics (Swap usage)
21. 21
ü 데이터 처리의 핵심인 Partition이 장애없이 정상적으로 운영되는가?
Topic 생성, leader 선출 및
복제가 완료된 상태
Partition의 생성 및 장애 시 상태 변화
Topic 생성시 상태 변화
NewPartition
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Controller+Internals
NewReplica
NewReplica
OnlinePartition
(Leader)
OnlineReplica
(Follower)
OnlineReplica
(Follower)
ISR
ISR
ISR
Broker 장애 시 상태 변화
OfflinePartition
(Leader)
OnlineReplica
(Follower)
OnlineReplica
(Follower)
OSR
ISR
ISR
신규 Leader 선출
OfflinePartition
(follower)
OnlinePartition
(Leader)
OnlineReplica
(Follower)
OSR
ISR
ISR
장애
발생
장애 Broker의 partition은
OfflinePartition으로 표시
신규 leader가 선출되고
정상 서비스 가능
22. 22
Cluster와 Partition이 정상적으로 동작하고 있는지 확인하는 Metrics
https://blog.serverdensity.com/how-to-monitor-kafka/
Metric Comments Alert
ActiveControllerCount
• 클러스터의 Active Controller 개수 (클러스터 당 1개만 존재)
• (kafka.controller: type=KafkaController)
1개가 아닌 경우
IsrShrinksPerSec
IsrExpandsPerSec
• Broker가 다운되었을때, 일부 partition의 ISR이 줄어든다.
• Broker가 정상으로 회복하면, OSR상태에서 ISR로 복귀되는 비율
• (kafka.server: type=ReplicaManager)
!= 0
OfflinePartitionsCount
• 쓰기가 불가능한 leader partition의 개수 (partiton의 장애)
• (kafka.controller: type=KafkaController)
> 0
UnderReplicatedPartitions
• 데이터 복제가 완료되지 못한 partition의 개수
• 즉, 전체 partition수에서 ISR을 제외한 수
• (kafka.server: type=ReplicaManager )
> 0
UncleanLeaderElectionsPerSec
• Leader election이 진행중인 비율
• 진행중이라면 그 동안 leader가 정상동작을 못하므로, 0이 되어야 함.
• (kafka.controller: type=ControllerStats)
!= 0
Broker Metrics
23. 23
23
In-Sync Replica 상태가 아닌 복제본(OSR)도 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
- 모든 replica가 ISR 상태
- B2 broker가 중지된 상태에서 B1에 새로운 메세지 입력
- B1 broker까지 다운되어 leader선출 불가
- B2의 replica는 OSR(Out of-Sync Replica) 상태
- 설정값에 따라서 leader가 될수 있으나, B1에 입력된 데이터는 유실됨
B1 B2
100 100
B1 B2
100 100
101
B1 B2
100 100
101
B1 B2
100 100
101
1
2
3
4
unclean.leader.election.enable 동작 방식
24. 24
처리 성능에 영향을 주는 Metrics
Metric Comments Alert
PurgatorySize
• Broker에서 요청을 처리하지 않고, 격리시킨 요청(request)의 건수
• 어떤 경우에 이렇게 요청을 격리하나?
• Produce (Producer 관점)
• Request.required.acks = -1(all) 일 때,
• 모든 복제가 완료되기 전까지, producer의 request는 대기(격리)
• Fetch (consumer 관점)
• Fetch.wait.max.ms 시간 또는
• fetch.min.bytes만큼의 데이터가 없는 경우
• (kafka.server:type=DelayedOperationPurgatory)
운영자의
설정에 따라
판단
NetworkProcessorAvgIdlePercent
• 네트워크 프로세서가 유휴상태인 비율
• 낮을 수록 thread가 많은 작업을 하고 있음을 의미
• (kafka.network: type=SocketServer)
< 0.3.
RequestHandlerAvgIdlePercent
• Request handler thread가 유휴상태인 시간의 평균
• 이 수치가 낮으면 일을 안한다는 의미.
• (kafka.server: type=KafkaRequestHandlerPool)
< 0.3.
Broker Metrics
25. 25
https://blog.serverdensity.com/how-to-monitor-kafka/
Metric Comments Alert
fetch-throttle-time-avg
• Conusumer의 요청으로 Broker의 과도한 자원(cpu,network 등)을 사용하
는 경우, Broker가 임의로 Consumer 요청을 제한한 시간
지속 증가 시
Broker 추가 고려
join-rate • Consumer 장애로 인하여, partition이 다른 consume로 할당되는 비율
증가 시 Consumer
안정성 개선 필요
assigned-partitions • 현재 Consumer가 가지고 있는 partition의 갯수
Consumer Metrics (Kafka 0.9.0.0 이후)
Consumer 관점에서 Broker의 부하를 확인하는 Metrics
26. Consumer와 Broker(Coordinator)간의 주기적 신호를 통해 장애 판단
Consumer 장애를 판단하는 기준은?
Consumer의 신호 확인 (session.timeout.ms, max.poll.interval.ms )
• Consumer가 주기적 신호를 Coordinator로 전송하여 장애 여부 판단
• Session Time, Poll(데이터 요청) Time 시간을 확인
Consumer 장애 시 Partition 재할당
• Consumer의 신호가 없으면 장애로 판단하고, partition 재 할당
• JMX Metric의 Join 발생
Broker
(Coordinator)
Partition-1
Consumer-1
Consumer-2
Consumer-3
Broker
Broker
Partition-2
Partition-3
Consumer-Group Broker
(Coordinator)
Partition-1
Consumer-1
Consumer-2
Consumer-3
Broker
Broker
Partition-2
Partition-3
Consumer-Group
Time
Out
29. 29
Broker 서버 자원의 상태를 예측하는 Metrics
https://blog.serverdensity.com/how-to-monitor-kafka/
Metric Comments 대응
RequestsPerSec
• 너무 많은 요청으로 Broker의 네트워크 대역폭을 지속 초과하면,
• Broker를 확장하여 분산 처리 필요
• (kafka.network: type=RequestMetrics)
LogFlushRateAndTimeMs
• Cache에 저장된 데이터를 Log(Disk)로 저장하는 비율
• 비율이 점차 늦어진다면,
• Broker를 추가하여 partition에 쓰는 부하를 분산 필요
• (kafka.log:type=LogFlushStats)
지연 발생시,
데이터 유실 가능성 높음
ErrorsPerSec
• 즉, Network Error가 없는 상태에서 Broker 처리량이 줄어든다면,
• Broker 내부 자원 부족 가능성 높음
• (kafka.network: type=RequestMetrics)
Broker Metrics