Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
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
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
고승범(peter.ko) / kakao corp.(인프라2팀)
---
카카오에서는 빅데이터 분석, 처리부터 모든 개발 플랫폼을 이어주는 솔루션으로 급부상한 카프카(kafka)를 전사 공용 서비스로 운영하고 있습니다. 전사 공용 카프카를 직접 운영하면서 경험한 트러블슈팅과 운영 노하우 등을 공유하고자 합니다. 특히 카프카를 처음 접하시는 분들이나 이미 사용 중이신 분들이 많이 궁금해하는 프로듀서와 컨슈머 사용 시의 주의점 등에 대해서도 설명합니다.
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.
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
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.
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
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
고승범(peter.ko) / kakao corp.(인프라2팀)
---
카카오에서는 빅데이터 분석, 처리부터 모든 개발 플랫폼을 이어주는 솔루션으로 급부상한 카프카(kafka)를 전사 공용 서비스로 운영하고 있습니다. 전사 공용 카프카를 직접 운영하면서 경험한 트러블슈팅과 운영 노하우 등을 공유하고자 합니다. 특히 카프카를 처음 접하시는 분들이나 이미 사용 중이신 분들이 많이 궁금해하는 프로듀서와 컨슈머 사용 시의 주의점 등에 대해서도 설명합니다.
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.
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
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.
Understanding of Apache kafka metrics for monitoring SANG WON PARK
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
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.
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.
Capacity Planning Your Kafka Cluster | Jason Bell, DigitalisHostedbyConfluent
"There's little talk about capacity planning Kafka clusters, it's very much learn as you go, every cluster is different. In this talk Kafka DevOps Engineer Jason Bell takes you through the things that will help you, from broker capacity, thinking about topics and how the other Confluent components can affect throughput and performance. With a number of production deployments under his watchful gaze for over six years Jason has plenty of experience, stories and useful information that will help you.
By the end of the talk you'll have a good understanding of designing the cluster for various scenarios, where the points of latency are to watch and monitor. And also how to prevent teams breaking the cluster behind your back.
This talk is designed for everyone, anyone who is just starting to those who are operating Kafka on a daily basis."
Full recorded presentation at https://www.youtube.com/watch?v=2UfAgCSKPZo for Tetrate Tech Talks on 2022/05/13.
Envoy's support for Kafka protocol, in form of broker-filter and mesh-filter.
Contents:
- overview of Kafka (usecases, partitioning, producer/consumer, protocol);
- proxying Kafka (non-Envoy specific);
- proxying Kafka with Envoy;
- handling Kafka protocol in Envoy;
- Kafka-broker-filter for per-connection proxying;
- Kafka-mesh-filter to provide front proxy for multiple Kafka clusters.
References:
- https://adam-kotwasinski.medium.com/deploying-envoy-and-kafka-8aa7513ec0a0
- https://adam-kotwasinski.medium.com/kafka-mesh-filter-in-envoy-a70b3aefcdef
A brief introduction to Apache Kafka and describe its usage as a platform for streaming data. It will introduce some of the newer components of Kafka that will help make this possible, including Kafka Connect, a framework for capturing continuous data streams, and Kafka Streams, a lightweight stream processing library.
Kafka Streams is a new stream processing library natively integrated with Kafka. It has a very low barrier to entry, easy operationalization, and a natural DSL for writing stream processing applications. As such it is the most convenient yet scalable option to analyze, transform, or otherwise process data that is backed by Kafka. We will provide the audience with an overview of Kafka Streams including its design and API, typical use cases, code examples, and an outlook of its upcoming roadmap. We will also compare Kafka Streams' light-weight library approach with heavier, framework-based tools such as Spark Streaming or Storm, which require you to understand and operate a whole different infrastructure for processing real-time data in Kafka.
Apache Kafka 0.8 basic training - VerisignMichael Noll
Apache Kafka 0.8 basic training (120 slides) covering:
1. Introducing Kafka: history, Kafka at LinkedIn, Kafka adoption in the industry, why Kafka
2. Kafka core concepts: topics, partitions, replicas, producers, consumers, brokers
3. Operating Kafka: architecture, hardware specs, deploying, monitoring, P&S tuning
4. Developing Kafka apps: writing to Kafka, reading from Kafka, testing, serialization, compression, example apps
5. Playing with Kafka using Wirbelsturm
Audience: developers, operations, architects
Created by Michael G. Noll, Data Architect, Verisign, https://www.verisigninc.com/
Verisign is a global leader in domain names and internet security.
Tools mentioned:
- Wirbelsturm (https://github.com/miguno/wirbelsturm)
- kafka-storm-starter (https://github.com/miguno/kafka-storm-starter)
Blog post at:
http://www.michael-noll.com/blog/2014/08/18/apache-kafka-training-deck-and-tutorial/
Many thanks to the LinkedIn Engineering team (the creators of Kafka) and the Apache Kafka open source community!
Journey of The Connected Enterprise - Knowledge Graphs - Smart DataBenjamin Nussbaum
We live in an era where the world is more connected than ever before and the trajectory is such that data relationships will only continue to increase with no signs of slowing down.
Connected data is the key to your business succeeding and growing in today’s connected world.
Leading enterprises will be the ones that utilize relationship-centric technologies to leverage connections from their internal operations and supply chain to their customer and user interactions. This ability to utilize connected data to understand all the nuanced relationships within their organization will propel them forward as they act on more holistic insights.
Every organization needs a knowledge graph because connected data is an essential foundation to advancing business. Knowledge graphs provide:
- Increased visibility between internal groups
- Efficiency gains
- Cross-functional data collaboration
- Core complete and reliable business insights
- Better customer engagement
The live presentation and discussion can be found here: https://www.youtube.com/watch?v=RQGdw82rAes
Additional reading on why connected data is beneficial: https://www.graphgrid.com/why-connected-data-is-more-useful/
Connected data solutions available by Benjamin and his team via GraphGrid and AtomRain: https://www.graphgrid.com and https://www.atomrain.com
Understanding of Apache kafka metrics for monitoring SANG WON PARK
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
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.
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.
Capacity Planning Your Kafka Cluster | Jason Bell, DigitalisHostedbyConfluent
"There's little talk about capacity planning Kafka clusters, it's very much learn as you go, every cluster is different. In this talk Kafka DevOps Engineer Jason Bell takes you through the things that will help you, from broker capacity, thinking about topics and how the other Confluent components can affect throughput and performance. With a number of production deployments under his watchful gaze for over six years Jason has plenty of experience, stories and useful information that will help you.
By the end of the talk you'll have a good understanding of designing the cluster for various scenarios, where the points of latency are to watch and monitor. And also how to prevent teams breaking the cluster behind your back.
This talk is designed for everyone, anyone who is just starting to those who are operating Kafka on a daily basis."
Full recorded presentation at https://www.youtube.com/watch?v=2UfAgCSKPZo for Tetrate Tech Talks on 2022/05/13.
Envoy's support for Kafka protocol, in form of broker-filter and mesh-filter.
Contents:
- overview of Kafka (usecases, partitioning, producer/consumer, protocol);
- proxying Kafka (non-Envoy specific);
- proxying Kafka with Envoy;
- handling Kafka protocol in Envoy;
- Kafka-broker-filter for per-connection proxying;
- Kafka-mesh-filter to provide front proxy for multiple Kafka clusters.
References:
- https://adam-kotwasinski.medium.com/deploying-envoy-and-kafka-8aa7513ec0a0
- https://adam-kotwasinski.medium.com/kafka-mesh-filter-in-envoy-a70b3aefcdef
A brief introduction to Apache Kafka and describe its usage as a platform for streaming data. It will introduce some of the newer components of Kafka that will help make this possible, including Kafka Connect, a framework for capturing continuous data streams, and Kafka Streams, a lightweight stream processing library.
Kafka Streams is a new stream processing library natively integrated with Kafka. It has a very low barrier to entry, easy operationalization, and a natural DSL for writing stream processing applications. As such it is the most convenient yet scalable option to analyze, transform, or otherwise process data that is backed by Kafka. We will provide the audience with an overview of Kafka Streams including its design and API, typical use cases, code examples, and an outlook of its upcoming roadmap. We will also compare Kafka Streams' light-weight library approach with heavier, framework-based tools such as Spark Streaming or Storm, which require you to understand and operate a whole different infrastructure for processing real-time data in Kafka.
Apache Kafka 0.8 basic training - VerisignMichael Noll
Apache Kafka 0.8 basic training (120 slides) covering:
1. Introducing Kafka: history, Kafka at LinkedIn, Kafka adoption in the industry, why Kafka
2. Kafka core concepts: topics, partitions, replicas, producers, consumers, brokers
3. Operating Kafka: architecture, hardware specs, deploying, monitoring, P&S tuning
4. Developing Kafka apps: writing to Kafka, reading from Kafka, testing, serialization, compression, example apps
5. Playing with Kafka using Wirbelsturm
Audience: developers, operations, architects
Created by Michael G. Noll, Data Architect, Verisign, https://www.verisigninc.com/
Verisign is a global leader in domain names and internet security.
Tools mentioned:
- Wirbelsturm (https://github.com/miguno/wirbelsturm)
- kafka-storm-starter (https://github.com/miguno/kafka-storm-starter)
Blog post at:
http://www.michael-noll.com/blog/2014/08/18/apache-kafka-training-deck-and-tutorial/
Many thanks to the LinkedIn Engineering team (the creators of Kafka) and the Apache Kafka open source community!
Journey of The Connected Enterprise - Knowledge Graphs - Smart DataBenjamin Nussbaum
We live in an era where the world is more connected than ever before and the trajectory is such that data relationships will only continue to increase with no signs of slowing down.
Connected data is the key to your business succeeding and growing in today’s connected world.
Leading enterprises will be the ones that utilize relationship-centric technologies to leverage connections from their internal operations and supply chain to their customer and user interactions. This ability to utilize connected data to understand all the nuanced relationships within their organization will propel them forward as they act on more holistic insights.
Every organization needs a knowledge graph because connected data is an essential foundation to advancing business. Knowledge graphs provide:
- Increased visibility between internal groups
- Efficiency gains
- Cross-functional data collaboration
- Core complete and reliable business insights
- Better customer engagement
The live presentation and discussion can be found here: https://www.youtube.com/watch?v=RQGdw82rAes
Additional reading on why connected data is beneficial: https://www.graphgrid.com/why-connected-data-is-more-useful/
Connected data solutions available by Benjamin and his team via GraphGrid and AtomRain: https://www.graphgrid.com and https://www.atomrain.com
Teaching for Peace, Renewing the Spirit - TESOL 2014Cheryl Woelk
Educators can be re-energized through innovating new meaning and purpose by working with a team to integrate research in peacebuilding and English language teaching. This presentation describes a small group of Christian language educators who were renewed through collective reflective practice and research on infusing peacebuilding theory and practice into their teaching. A conceptual framework and practical suggestions for encouraging educators interested in integrating peacebuilding into their work as language teachers will be provided.
Slides I presented at Docker Palo Alto Meetup 2/17/2016. They cover: (1) what is Swarm?, (2) how to set up Swarm, (3) an example microservice app based on Swarm.
Java Garbage Collectors – Moving to Java7 Garbage First (G1) CollectorGurpreet Sachdeva
One of the key strengths of JVM is automatic memory management (Garbage Collection). Its understanding can help in writing better applications. This becomes all the more important as enterprise server applications have large amount of live heap data and significant parallel threads. Until recently, main collectors were parallel collector and concurrent-mark-sweep (CMS) collector. This presentation introduces the various Garbage Collectors and compares the CMS collector against its replacement, a new implementation in Java7 i.e. G1. It is characterized by a single contiguous heap which is split into same-sized regions. In fact if your application is still running on the 1.5 or 1.6 JVM, a compelling argument to upgrade to Java 7 is to leverage G1.
Continuous deployment in LeanIX @ Bonn AgileLeanIX GmbH
LeanIX ist ein Startup aus Bonn, dass eine Software-as-a-Service Lösung anbieter, mit der Unternehmen wie z.B. Zalando, Axel Springer, RWE oder Helvetia Versicherung ihre IT Landschaft dokumentieren. Dank eines modernen Green-Blue Deployments können Releases und Hotfixes im laufenden Betrieb ausgerollt werden, ohne dass die Nutzer des Systems davon beeinträchtigt werden. In diesem Talk beim Bonn Agile Meetup gibt Co-CEO André Einblick in die Konzepte und zugrundeliegenden Technologien wie Docker, Ansible und Jenkins.
===
LeanIX offers an innovative software-as-a-service solution for Enterprise Architecture Management (EAM), based either in a public cloud or the client’s data center.
Companies like Adidas, Axel Springer, Helvetia, RWE, Trusted Shops and Zalando use LeanIX Enterprise Architecture Management tool.
Free Trial: http://bit.ly/LeanIXFreeTrial
SpringIO 2016 - Spring Cloud MicroServices, a journey inside a financial entityjordigilnieto
The presentation explains the journey from a monolithic architecture to Spring Cloud Microservices for application development inside a financial entity, along with the transition to DevOps strategies… a journey that has just begun…
TrendsByte (http://trendsbyte.com) is a Data as a Service (DaaS) platform, which provides comprehensive, relevant and actionable insights on global trends and opportunities, across industries. We use machine learning and Natural Language Processing (NLP) to aggregate relevant data, analyze strategies of key players, and extract meaningful insights from it.
Our insights help consultants and CXOs cut through the noise, and access the right information without wasting their resources. We have tested our prototype and validated product-market-fit through sales and traction. We are now in the process of building scalable platform, which will provide data analytics and API access to our customers. The platform will have flexible search capabilities, for customers to create customized charts, dashboards, and shareable reports.
Acts 6:1-7 ~ Organic Growth of the Early Church (pt. 1)Laura Zielke
This week we started a new section of Acts where Luke turns our attention away what was going on in the Temple courts to the inevitable challenges of exponential growth and diversity.
We evaluated internal evidence that Luke was possibly using a new source(s) for this section including the introduction of previously unused terms which are common in his Gospel and throughout the rest of Acts.
As the group of Christ followers experienced exponential growth, it was only a matter of time before logistical issues arose which could potentially derail the unity they were experiencing.
We discussed the difference between "Hebrews" and "Hellenists" in this passage, comparing various translations to the original Greek, and we discussed how this distinction is evidence of a new source for our historian author.
The Complete Transformation from Offline to Online Magento Implementation of a B2B Platform – a Case Study. This case study shows how we managed to reach 100.000.000 EUR of online revenue, within only 3 quarters last year.
Everyone wants their little application to grow up to be a strong, well-rounded, and useful set of code. We organize, we unit test, we market research, and then we push to production. All is good in the world until now you need two web servers, and multiple back-end servers, and more DB servers than you have fingers. Your code starts to act weird, there are errors in some places but not others. Fires, floods, and locusts all start to appear, and how do you manage it? Let's look at some real-life examples, along with some tools and tips, for managing those fires as your application grows.
Presented at the Chicago Riak Meetup, 20 Oct 2015. Slides walk through a demo of automating the building of a full stack Riak KV cluster from scratch, and then populating it with 250,000,000 time series data points.
Docker is quickly becoming an invaluable development and deployment tool for many organizations. Come and spend the day learning about what Docker is, how to use it, how to integrate it into your workflow, and build an environment that works for you and the rest of your team. This hands-on tutorial will give you the kick-start needed to start using Docker effectively.
People who confine themselves to few things shall lack knowledge on all the other things. They will not show youthe common way to get knowledge on everyone and everything. There exists a common way to get knowledge on everyone and everything.People who identify and make use of the common way become more versatile and get knowledge on a wide range of things.
Everyone and everything has parts, uniqueness, connections, influences, stability, uses, and substitutes as specific properties. Nothing lacks these properties. You too have these properties. You might not have seen them. You are not the only one to have these properties. But, everyone and everything has these properties. There is a direct connection between these properties and your knowledge. You will haveno knowledge if nothing has these properties.To know yourself, you must see your own properties.To know everyone and everything, you must see the specific properties of everyone and everything. Accordingly, this document entitled ‘the common protocol’ provides a common directiveto people who want to get knowledge on a wide range of things and become more versatile.
The same single common directive has been explicitly repeated again and again in this document in order to illustrateits connection to our knowledgeon everyone and everything. Only such repetitions shall make people to ‘re-view’the commonness of knowledge contributed by teachers, books, scientists, philosophers, specialists, researchers, explorers, thinkers, experts, and leaders. I explicitly repeated it in the same way; but, everyone else repeats itimplicitlyin different ways. People are yet to devise a new protocol to get knowledge on everyone and everything.The same common protocol is endlessly repeated by people in different ways. People would stop repeating it only if you show them a new way to get knowledge.Are you ready to devise a new way to get knowledge on everyone and everything? If yes, go ahead! I had triedand miserably failed to find a new way. I find myself repeating the same traditional common protocol to get knowledge on everyone and everything.My intelligence is no better to yours. Your intelligence might be better than mine. Give a try.
The common protocolgives you versatility by directing you in a step by step manner to the knowledge on almost everything.
The easy to follow common protocol is not an arbitrary protocol.No sane human can deny the existence and use of the common protocol to get knowledge on everyone and everything.To get knowledge on any specific thing, you can use the common directive as a guideline.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
본 세션에서는 Amazon의 관리형 데이터베이스 서비스(RDS) 중 기존 상용데이터베이스의 5배 성능 및 1/10 가격으로도 확장성을 보장하는 Aurora에 대한 소개 및 사용법 그리고 기존의 DB에서의 마이그레이션 방법에 대해 소개해드립니다. 10월 리인벤트를 통해 동경 리전에 Aurora를 사용가능하게 되었습니다.
Similar to Apache kafka performance(throughput) - without data loss and guaranteeing data order (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
2. 2
우리가 원하는 Apache Kafka의 역할은?
데이터 전송순서를 유지하면서, 절대로 데이터를 유실하면 안된다!
데이터 전송순서를 유지하려면? 데이터 유실을 방지하려면?
• 반드시 전송이 성공 한 후에 다음 데이터 전송 à sync 방식
• Topic을 분산하면 안됨 à partition 1개
• Topic 당 1개의 Producer만 할당
• 복사본을 최대한 증가 à replica 3개
• 모든 복사본까지 저장된 후 다음 메시지 처리 à acks = -1
Throughput 최대화 Durability 보장
3. 3
요구하는 환경을 위한 Apache Kafka 설정은?
순서보장을 위한 producer 설정과, 유실방지를 위한 broker 설정 변경
Producer 설정 Apache Kafka 설정
• 데이터 전송 순서 보장
• Sync 방식 전송 (thread 1개)
• 데이터 유실 방지
• Acks : -1 (모든 복제본 저장 후, 다음 메시지 전송)
• Retris : 최대한 많은 재시도 (메시지 유실 없도록)
• 처리량 향상
• Compression : 압축알고리즘 최적화 (gzip, lz4, snappy)
• batch_size : 1회 전송에 보내는 size
• Topic 생성시 설정
• replication-factor : 3 (원본 포함 3개)
• partitions : 1 (데이터가 분산되지 않도록 설정, 순서보장)
• Kafka Broker 설정
• min.insync.replicas : 2
• 최소 2개의 복사본 있어야, 서비스 가능
• 가용성을 높이려면 1로 설정
• 데이터 유실을 최소화 하려면 높게 설정
4. 4
테스트 환경을 구성하자
Kafka Cluster로 데이터를 전송 및 수신하고, 성능지표를 수집하여 모니터링
• Topic은 partition 1로 구성하여 2번 Broker만 생성하도록 설정
• 나머지 broker는 replication을 위한 용도로 활용
• 3대 서버
• CPU : Dual Intel Xeon E5-2650 v4 (24 Cores, 2.20 GHz)
• MEM : 64 GB
• DISK : 2 TB, MegaRAID SAS 9361-8i, 12Gb/s
• Node 1
• Kafka Broker1, Zookeeper1
• Producer
• ELK Stack (logstash, kibana, elasticsearch)
• Node 2 (Topic 생성)
• Kafka Broker2, Zookeeper2
• Node 3
• Kafka Broker3, Zookeeper3
• Consumer
Producer
(filebeat)
테스트 환경 구성 테스트 서버 스펙
Kafka Cluster
Consumer
(logstash)
Monitoring
(ELK Stack)
JMX Metric 수집
Broker 1
Broker 2
Broker 3
• Message Size : 3 KB (3,000 byte)
• Apache Kafka 0.11.0
5. 5
[성능비교 1] 1개 Producer로 전송 (acks=1 vs acks=-1)
원본만 저장하는 방식이 1,000건 빠른걸 보면, 복제본에 많은 시간이 소요되지 않음
원본만 저장후 처리하는 방식(acks 1) vs 모든 복제본 저장후 처리 방식(acks -1)
(100만건 데이터를 전송후 평균처리속도 계산)
측정 항목 측정 값
(acks = -1)
측정 값
(acks = 1)
비고
처리 건수 4,600 건 / sec 5,600 건 / sec - 평균 초당 처리 건수
처리 용량 90 KB / sec 100 KB / sec - 기본 압축 (gzip) 적용
전송 파일 비교(건수) 동일 동일 - Consumer에서 수신한 파일과 동일
전송 파일 비교(순서) 동일 동일
- Consumer에서 수신한 파일과 동일
- Diff Command 로 확인
자원 사용량 (CPU) 평균 1 core 평균 1 core
자원 사용량 (Memory) 200 ~ 700 MB 200 ~ 700 MB - Heap Memory 2G 이하로 설정
6. 6
[성능비교 2] Producer 개수를 증가 (4, 10 개)
Producer를 증가시키면 처리성능도 함께 증가함 (4,600 à 29,000건)
(100만건 데이터를 전송 후 평균처리속도 계산)
측정 항목 측정 값
(acks = -1, producer = 4)
측정 값
(acks = -1, producer = 10)
비고
처리 건수 38,000 건 / sec 58,000 건 / sec - 평균 초당 처리 건수
처리 용량 280 KB / sec 370 KB / sec - gzip 알고리즘 적용
전송 파일 비교(건수) 동일 동일 - Consumer에서 수신한 파일과 동일
전송 파일 비교(순서) 동일 동일
- Consumer에서 수신한 파일과 동일
- Diff Command 로 확인
자원 사용량 (CPU) 평균 3 core 평균 3 core
자원 사용량 (Memory) 200 ~ 700 MB 200 ~ 700 MB
- CPU 사용률이 증가하는 것을 볼 때, Kafka Broker가 더 많은 메시지를 처리가능
- 즉, Producer가 모든 복제본이 완료되기까지 대기하는 시간으로 인하여, 많은 데이터를 전송하지 못함.
7. 7
[성능비교 3] 압축 알고리즘 변경 (gzip, snappy, lz4)
압축성능 및 처리성능 관점에서 lz4가 가장 효과적임
(100만건 데이터를 전송 후 평균처리속도 계산)
- 처리 성능만을 고려한다면, lz4 또는 snappy 알고리즘을 선택해야 하지만,
- Snappy 알고리즘은 압축률이 좋지 않아, lz4를 사용하는 것이 효과적
측정 항목 측정 값
(compression = lz4)
측정 값
(compression = snappy)
측정 값
(compression = gzip)
측정 값
(compression = none)
비고
처리 건수 88,000 건 / sec 90,000 건 / sec 57,000 건 / sec 33,000 건 / sec - 처리량은 lz4, snappy 가 높음
처리 용량 1,790 KB / sec 12,432 KB / sec 622 KB / sec 96,593 KB / sec - 압축률은 gzip이 가장 높음
전송 파일 비교(건수) 동일 동일 동일 동일
전송 파일 비교(순서) 동일 동일 동일 동일
자원 사용량 (CPU) 평균 0.7 core 평균 1.2 core 평균 1 core 평균 1.3 core
- Lz4가 cpu 사용률이 가장 낮음
- 압축을 하지 않은 경우, 더 많은
cpu time을 소요함.
자원 사용량 (Memory) 200 ~ 700 MB 200 ~ 700 MB 200 ~ 700 MB 200 ~ 700 MB
8. 8
[성능비교 3] 압축 알고리즘 변경 (gzip, snappy, lz4)
처리성능이 높으면서 CPU 사용량이 가장 적은 것이 lz4 압축
LZ4 snappy gzip 압축없음
[초당 처리 건수]
LZ4 snappy gzip 압축없음
[초당 데이터 처리량]
[CPU 사용량]
snappy gzip 압축없음LZ4
9. 9
테스트에서 사용한 Apache kafka 설정
구분 설정 파라미터 (Default) 내용 비고
Broker
replication.factor
(1)
- Topic 의 유실 방지를 위해 원본을 포함한 복제본 개수 (1 이상)
- 많은 경우 유실방지
- 적은 경우 성능향상
min.insync.replicas
(1)
- Broker 서버의 장애를 허용하는 최소 서버 개수
- 2인 경우 2대 까지는 서비스 가능 (1대만 남은 경수 서비스 불가)
- 많은 경우 데이터 유실방지
- 적은 경우 가용성 향상
message.max.bytes
(1,000,000)
- 한번의 요청 batch에서 전송 가능한 최대 bytes
- Message가 큰 경우(이미지 binary 등)
값을 증가
unclean.leader.election.enable
(false)
- 정상적으로 원본을 복제하지 못한 broker가 서비스를 할 수 있는지 여부
- True : 가능 (유실 가능)
- False : 불가(가용성 저하)
Producer
acks
(1)
- 0 : 원본 저장 확인 없이 응답
- 1 : 원본 저장 확인 후 응답
- -1 : 복제본 저장 완료 후 응답(가장 느림)
- 데이터 유실방지를 위해 -1 옵션 사용
max_retries
(3)
- 데이터 전송 실패시 재전송 회수
- 네트워크 및 시스템이 불안전한
환경에서는 높게 설정
batch.size
(16,384)
- 한번에 전송할 데이터의 크기 (byte)
- 테스트를 위해 사용한 Filebeat에서는 bulk_max_size를 이용하여 한번에 전송할 메시지 건수로 지정
- 많은 경우 전송효율 높음
- 적을 경우 전송효율 낮음
compression.type
(Gzip)
- 전송할 데이터를 압출할 알고리즘 지정 (gzip, lz4, snappy, none) - Lz4 알고리즘이 효율적
Consumer
enable_auto_commit
(true)
- 데이터를 수신한 뒤 자동으로 Commit할 것인지 지정
- 유실방지 위해 False로 설정하고, Biz
로직 동작후 직접 commit
auto_commit_interval_ms
(5,000)
- Auto commit이 true인 경우, commit할 주기를 지정
- 많은 경우 처리 성능 높음
- 적은 경우 처리성능 낮음
max.partition.fetch.bytes
(1,000,000)
- Broker의 message.max.bytes 설정이 변경될 경우, 최대 batch size를 가져올 수 있도록 함께 변경
10. 10
Apache Kafka 성능 개선을 위한 하드웨어 고려사항
고려사항 주요 설명
CPU CORE
• 처리량이 CPU에 많은 영향을 받지는 않지만, multi core를 권장
• 병행처리를 위해서는 빠른 core보다는 많은 core를 권장
Memory
• CPU보다는 MEMORY가 성능에 미치는 영향이 더 크다.
• 왜냐하면, 많은 데이터가 서버로 유입되고 관리되면서 발생하는 데이터를 page cache를 이용
하여 처리하기 위함.
DISK
• DISK의 처리성능이 중요함. (SATA 7200 rpm 기준)
• 병렬 Disk I/O를 위해 Disk의 개수가 많은 것이 좋음
• http://docs.confluent.io/1.0.1/kafka/deployment.html
OS 설정
• file descriptors 의 개수를 사전에 충분히 증가시켜야 함 (Topic의 수가 많아지고,
connection하는 producer, consumer가 증가할 경우)
• socket buffer size를 최대화 하여, 한번에 처리할 수 있는 처리량을 증가시킨다.
• OS 최적화 : https://kafka.apache.org/documentation.html#hwandos 참고
11. 11
테스트 결과 정리
초당 처리 건수는 Topic당 최대 90,00건을 처리하며, 유실없이 데이터 순서보장
초당 90,000 건 이상
(1개 Topic, 10개 producer 동시전송)
데이터 유실없이, 전송순서 보장
[ 고려사항 ]
• 전체 처리량 = 90,000건 * TOPIC 수
• Producer용 서버의 자원을 추가하면, 더 많은 데이터
처리 가능
• 압축 알고리즘 선택에 따라서 성능 및 전송효율 향상 가
능 (lz4 권장)
[ 고려사항 ]
• Network 장애로 인하여 특정 상황에서 데이터 중복 가
능 (유실 없음)
• 중복 제거를 위하여, Producer/Consumer API 활용하여
로직구현 필요