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
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
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
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.
Automate Your Kafka Cluster with Kubernetes Custom Resources confluent
(Sam Obeid, Shopify) Kafka Summit SF 2018
At Shopify we manage multiple Apache Kafka clusters in multiple locations in Google’s cloud platform. We deploy our Kafka clusters as Kubernetes StatefulSets, and we use other K8s workloads to implement different tasks. Automating critical and repetitive operational tasks is one of our top priorities.
In this talk we’ll discuss how we leveraged Kubernetes Custom Resources and Controllers to automate some of the key cluster operational tasks, to detect clusters configuration changes and react to these changes with required actions. We will go through actual examples we implemented at Shopify, how we solved the problem of cluster discovery and how we automated topics creation across different clusters with zero human intervention and safety controls.
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
고승범(peter.ko) / kakao corp.(인프라2팀)
---
카카오에서는 빅데이터 분석, 처리부터 모든 개발 플랫폼을 이어주는 솔루션으로 급부상한 카프카(kafka)를 전사 공용 서비스로 운영하고 있습니다. 전사 공용 카프카를 직접 운영하면서 경험한 트러블슈팅과 운영 노하우 등을 공유하고자 합니다. 특히 카프카를 처음 접하시는 분들이나 이미 사용 중이신 분들이 많이 궁금해하는 프로듀서와 컨슈머 사용 시의 주의점 등에 대해서도 설명합니다.
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
황민호(robin.hwang) / kakao corp. DSP개발파트
---
최근 Spring Cloud와 Netflix OSS로 MSA를 구성하는 시스템 기반의 서비스들이 많아지는 추세입니다.
카카오에서도 작년에 오픈한 광고 플랫폼 모먼트에 Spring Cloud 기반의 MSA환경을 구성하여, API Gateway도 적용하였는데 1년 반 정도 운영한 경험을 공유할 예정입니다. 더불어 MSA 환경에서는 API Gateway를 통해 인증을 어떻게 처리하는지 알아보고 OAuth2 기반의 JWT Token을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
source : http://www.opennaru.com/opensource/kubernetes/
Kubernetes는 컨테이너화된 애플리케이션(Containerized Application)의 배포, 확장 그리고 관리를 할 수 있는 오픈 소스 컨테이너 오케스트레이션 시스템입니다.
쿠버네티스는 구글 엔지니어들이 개발하고 설계한 플랫폼으로서 사내에서 이용하던 컨테이너 클러스터 관리 도구인 “Borg”의 아이디어를 바탕으로 만들어진 오픈소스 소프트웨어입니다.
구글은 쿠버네티스의 원천이 되는 Borg를 수년 동안 개발하고 운영하면서 축적된 경험을 바탕으로 쿠버네티스를 오픈소스 프로젝트로 만들어 었습니다.
인프라 모니터링을 위한 시스템을 구축하고 운영하는 데 있어, 다이내믹한 인프라 변화는 어려움으로 다가오고 있습니다.
본 세션에서는 인프라를 운영하는 팀 혹은 운영자 관점에서 바라본 미래 지향적 인프라 모니터링 시스템의 방향성과 이를 구현하기 위해 필요한 구성들을 공유하고자 합니다.
목차
1. NHN 모니터링의 현재
2. 모니터링의 변화
3. 모니터링 방법론
4. 모니터링 절차
5. NHN 모니터링의 미래
대상
- 인프라를 운영하는 시스템 엔지니어
- 인프라 모니터링 시스템에 관심이 있는 분
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.
Kafka as an Event Store - is it Good Enough?Guido Schmutz
Event Sourcing and CQRS are two popular patterns for implementing a Microservices architectures. With Event Sourcing we do not store the state of an object, but instead store all the events impacting its state. Then to retrieve an object state, we have to read the different events related to a certain object and apply them one by one. CQRS (Command Query Responsibility Segregation) on the other hand is a way to dissociate writes (Command) and reads (Query). Event Sourcing and CQRS are frequently grouped and used together to form something bigger. While it is possible to implement CQRS without Event Sourcing, the opposite is not necessarily correct. In order to implement Event Sourcing, an efficient Event Store is needed. But is that also true when combining Event Sourcing and CQRS? And what is an event store in the first place and what features should it implement? This presentation will first discuss what functionalities an event store should offer and then present how Apache Kafka can be used to implement an event store. But is Kafka good enough or do specific event store solutions such as AxonDB or Event Store provide a better solution?
Netflix changed its data pipeline architecture recently to use Kafka as the gateway for data collection for all applications which processes hundreds of billions of messages daily. This session will discuss the motivation of moving to Kafka, the architecture and improvements we have added to make Kafka work in AWS. We will also share the lessons learned and future plans.
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.
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
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.
Automate Your Kafka Cluster with Kubernetes Custom Resources confluent
(Sam Obeid, Shopify) Kafka Summit SF 2018
At Shopify we manage multiple Apache Kafka clusters in multiple locations in Google’s cloud platform. We deploy our Kafka clusters as Kubernetes StatefulSets, and we use other K8s workloads to implement different tasks. Automating critical and repetitive operational tasks is one of our top priorities.
In this talk we’ll discuss how we leveraged Kubernetes Custom Resources and Controllers to automate some of the key cluster operational tasks, to detect clusters configuration changes and react to these changes with required actions. We will go through actual examples we implemented at Shopify, how we solved the problem of cluster discovery and how we automated topics creation across different clusters with zero human intervention and safety controls.
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
고승범(peter.ko) / kakao corp.(인프라2팀)
---
카카오에서는 빅데이터 분석, 처리부터 모든 개발 플랫폼을 이어주는 솔루션으로 급부상한 카프카(kafka)를 전사 공용 서비스로 운영하고 있습니다. 전사 공용 카프카를 직접 운영하면서 경험한 트러블슈팅과 운영 노하우 등을 공유하고자 합니다. 특히 카프카를 처음 접하시는 분들이나 이미 사용 중이신 분들이 많이 궁금해하는 프로듀서와 컨슈머 사용 시의 주의점 등에 대해서도 설명합니다.
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
황민호(robin.hwang) / kakao corp. DSP개발파트
---
최근 Spring Cloud와 Netflix OSS로 MSA를 구성하는 시스템 기반의 서비스들이 많아지는 추세입니다.
카카오에서도 작년에 오픈한 광고 플랫폼 모먼트에 Spring Cloud 기반의 MSA환경을 구성하여, API Gateway도 적용하였는데 1년 반 정도 운영한 경험을 공유할 예정입니다. 더불어 MSA 환경에서는 API Gateway를 통해 인증을 어떻게 처리하는지 알아보고 OAuth2 기반의 JWT Token을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
source : http://www.opennaru.com/opensource/kubernetes/
Kubernetes는 컨테이너화된 애플리케이션(Containerized Application)의 배포, 확장 그리고 관리를 할 수 있는 오픈 소스 컨테이너 오케스트레이션 시스템입니다.
쿠버네티스는 구글 엔지니어들이 개발하고 설계한 플랫폼으로서 사내에서 이용하던 컨테이너 클러스터 관리 도구인 “Borg”의 아이디어를 바탕으로 만들어진 오픈소스 소프트웨어입니다.
구글은 쿠버네티스의 원천이 되는 Borg를 수년 동안 개발하고 운영하면서 축적된 경험을 바탕으로 쿠버네티스를 오픈소스 프로젝트로 만들어 었습니다.
인프라 모니터링을 위한 시스템을 구축하고 운영하는 데 있어, 다이내믹한 인프라 변화는 어려움으로 다가오고 있습니다.
본 세션에서는 인프라를 운영하는 팀 혹은 운영자 관점에서 바라본 미래 지향적 인프라 모니터링 시스템의 방향성과 이를 구현하기 위해 필요한 구성들을 공유하고자 합니다.
목차
1. NHN 모니터링의 현재
2. 모니터링의 변화
3. 모니터링 방법론
4. 모니터링 절차
5. NHN 모니터링의 미래
대상
- 인프라를 운영하는 시스템 엔지니어
- 인프라 모니터링 시스템에 관심이 있는 분
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.
Kafka as an Event Store - is it Good Enough?Guido Schmutz
Event Sourcing and CQRS are two popular patterns for implementing a Microservices architectures. With Event Sourcing we do not store the state of an object, but instead store all the events impacting its state. Then to retrieve an object state, we have to read the different events related to a certain object and apply them one by one. CQRS (Command Query Responsibility Segregation) on the other hand is a way to dissociate writes (Command) and reads (Query). Event Sourcing and CQRS are frequently grouped and used together to form something bigger. While it is possible to implement CQRS without Event Sourcing, the opposite is not necessarily correct. In order to implement Event Sourcing, an efficient Event Store is needed. But is that also true when combining Event Sourcing and CQRS? And what is an event store in the first place and what features should it implement? This presentation will first discuss what functionalities an event store should offer and then present how Apache Kafka can be used to implement an event store. But is Kafka good enough or do specific event store solutions such as AxonDB or Event Store provide a better solution?
Netflix changed its data pipeline architecture recently to use Kafka as the gateway for data collection for all applications which processes hundreds of billions of messages daily. This session will discuss the motivation of moving to Kafka, the architecture and improvements we have added to make Kafka work in AWS. We will also share the lessons learned and future plans.
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.
2019년 8월 22일 버티카 웨비나 진행 자료
주제: Vertica New Features - 8.1에서 9.2까지
버티카 8.1 버전부터 9.2 버전까지의 신기능에 대한 소개를 다루고 있는 웨비나입니다. 특정 기능의 Deep-dive 또는 상세 내용과 관련하여서는 댓글로 문의주시길 바랍니다.
웨비나 녹화 링크: https://www.youtube.com/watch?v=ExdrBBpGjDw
제 17회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [Catch, Traffic!] : 지하철 혼잡도 및 키워드 분석 데이터 파이프라인 구축BOAZ Bigdata
데이터 엔지니어링 프로젝트를 진행한 Catch, Traffic! 팀에서는 아래와 같은 프로젝트를 진행했습니다.
수도권 교통의 혼잡성을 해결하기 위한 방안을 찾는 데이터 파이프라인 구축
18기 김인섭 숭실대학교 산업정보시스템공학과
18기 김재민 국민대학교 AI빅데이터융합경영학과
18기 서은유 동덕여자대학교 정보통계학과
18기 윤정원 숙명여자대학교 소프트웨어융합전공
18기 이현진 서울과학기술대학교 산업정보시스템전공
18기 조은학 명지대학교 융합소프트웨어학부
넷플릭스에서는 높은 속도로 데이터를 제공하기 위해서 뿐만 아니라 멀티 리전의 데이터 가용성을 바탕으로한 전체 서비스 가용성 유지를 위해 캐시를 사용하고 있습니다. 이 앞의 세션에서 보았던 마이크로서비스 구조를 염두해 둘때 한가지 가장 간단한 변화는 외부 클라이언트로 부터 유입되는 단 하나의 요청에 대한 응답을 만들기 위해 다수의 내부 서비스들로 부터 데이터를 확보해야 하며, 이는 다수 서비스들에 대한 요청과 응답으로 이루어지게 됩니다. 내부 네트워크 성능, 데이터 저장소의 응답속도등의 복합적인 영향으로 인해 마이크로 서비스는 쉽게 느려질 수 있으며, 이는 보통 '팬아웃 효과'로 알려져 있습니다. 뿐만 아니라 다수 서비스간의 데이터 정합성 유지, 필요에 따라 각 서비스간 데이터의 다운타임 없는 이동, 증가하는 데이터량에 동시에 증가하는 데이터 소스의 부하, 그리고 이런 것들을 모두 감안한 데이터 복제 등을 처리해야 할 필요가 있습니다. 본 세션에서는 넷플릭스에서는 이런 문제를 어떤 방식으로 해결하는지, 그리고 스프링 부트, 스프링 클라우드를 비롯한 피보탈의 기술을 사용해서 어떻게 빠르고 쉽게 사용할 수 있는지에 대해 알아봅니다.
http://www.ubuntu-kr.org/viewtopic.php?f=2&t=17429
내용 :
-----------------------------------------------------------------
전반 세미나 진행 : 뻔뻔강사 님 (유명환)
우분투 한국사용자모임 대표 인사말 : 강분도 님 (강분도)
GNOME 3 이야기 : jincreator 님 (이진규)
전력선 통신(PLC) 이야기 : 포닉스 님 (이형준)
-----------------------------------------------------------------
.......... Coffee & Smoking Time (잠시 쉬어보아요!) ..........
-----------------------------------------------------------------
후반 세미나 진행 : abron 님 (김성윤)
유닉스 프로그래밍 책(4월 정기세미나 이벤트 상품) 독후감 발표 : sople1 님
오픈 소스 기반 클라우드 컴퓨팅 솔루션 OpenStack 이야기 : KT 안재석 님
임베디드 SW 와 오픈 소스의 궁합 이야기 : 뻔뻔강사 님 (유명환)
NetApp AI Control Plane for Kubernetes and Kubeflow
NetApp AI Data Control Plane for Kubernetes and Kubeflow
NetApp Trident and Python REST API for Kubernetes and Kubeflow
BespinGlobal 컨설팅 본부
최정식 위원(js.choi@bespinglobal.com)
데이터 마이그레이션 세미나 - 데이터로 날자
Helping You Adopt Cloud | 가트너 선정 아시아 No.1 클라우드 MSP, 성공적인 클라우드 도입을 위한 전략, 구축, 운영 및 관리 서비스 제공
1일 수천대의 서버에서 발생하는 30~50억건의 Log와 Metric을 처리하는 Planet Mon 을 지탱하는 기술인 Collection(Collectd, NXlog), Transport(Kakfa, Logstash), Log Stream Analytics, Storage(Elasticsearch), Visualization을 구성하는 Architecture에 대해 설명드리고 제가 개발한 Log Stream Analytics 서버들의 구현 기술에 대해 좀더 상세히 설명합니다.
3. 데이터 파이프라인이란?
▶ 서로 다른 여러 시스템 간의 데이터 이동과 흐름을 말함
▶ 어느 한 단계의 출력이 다음 단계의 입력으로 이어지는 연결된 구조로서 수집과 정제, 집계 등을
동시에 병렬로 수행해 전체 시스템의 효율성을 추구
Ⅰ. 카프카를 이용한 데이터 파이프라인 구축
데이터 파이프라인 구축 시 고려사항
▶ 적시성 : 시간 단위의 배치부터 실시간 처리까지 데이터 흐름의 다양한 적시성 요구사항을 만족
▶ 신뢰성 : 단일 장애점을 없애고 신속하고 자동화된 복구가 가능
‘최소 한번’(at-least-once), ‘정확히 한번’(exactly-once) 등 다양한 방식의 데이터 전달 보장
▶ 처리량 : 매우 높은 처리량을 갖도록 수시로 확장과 조정이 가능해야 함
▶ 데이터 형식 : 다양한 형식의 데이터를 지원하고 제약이 없어야 함
▶ 보안 : 파이프라인을 거치는 데이터의 암호화 기능
파이프라인에 데이터를 읽거나 쓸 때의 인증 기능 제공
▶ 변환 : ETL(추출-변환-적재) or ELT(추출-적재-변환)
▶ 장애처리 : 잘못된 데이터의 유입방지, 분석할 수 없는 데이터의 복구, 결함있는 데이터의 정정 등
▶ 결합방지 : 데이터를 제공하는 소스와 데이터를 받아 사용하는 대상의 결합방지 필요
4. NiFi, ElasticSearch, Spark, Hbase, Hive, Hue, etc…
Ⅰ. 카프카를 이용한 데이터 파이프라인 구축
▶ NiFi
- 분산 환경에서 대량의 데이터를 수집 및 처리할 수 있는 어플리케이션
- 웹 기반에 직관적인 인터페이스를 가지고 있어 접근성이 좋고 DataFlow를 쉽게 개발 가능
- 실시간 처리에 적합하고 데이터 추적이 쉬우며 NiFi 시스템 간 데이터 교환 가능
▶ ElasticSearch
- 아파치 루씬 기반의 분선형 RESTful 검색/분석 엔진
- 정형, 비정형, 위치정보, 메트릭 등 다양한 유형의 데이터를 원하는 방식으로 검색 및 결합 가능
- NoSQL 데이터베이스처럼 사용이 가능 및 내용 전체 색인해 특정 단어가 들어간 문서 검색 가능
▶ Spark
- 빅데이터 처리를 위한 오픈소스 병렬분산처리 플랫폼
- 인메모리 기반으로 고속 데이터 처리 가능하며, 일괄처리 작업 및 온라인 분석 처리에 유용
▶ Hbase
- 구글의 빅테이블을 모델로 개발된 column-based NoSQL DB
- 하둡의 HDS에서 동작하며 대량의 데이터를 안정적으로 다루는데 효과적임
▶ Hue
- 데이터를 탐색, 쿼리 및 시각화하기 위한 오픈소스 웹 기반 사용자 인터페이스
- 하둡과 하둡 에코시스템의 모니터링과 지원을 위한 인터페이스를 제공
▶ Hive
- 하둡을 기반으로 대용량 데이터를 질의하고 그 결과를 생성하는 SQL Query 엔진
- HiveQL 이라는 SQL 같은 언어를 제공하며 맵리듀스의 모든 기능을 제공함
7. Netfilx
Ⅰ. 카프카를 이용한 데이터 파이프라인 구축
▶ 실시간 모니터링 과 이벤트 처리를 위한 데이터 파이프라인의 백본 역할
▶ 초당 150만건 이상 생서외는 이용자의 로그 데이터를 카프카에 적재한 후 실시간 스트리밍 분석용
인프라를 이용해 이용자 반응에 실시간 대응
8. Uber
Ⅰ. 카프카를 이용한 데이터 파이프라인 구축
▶ 카프카를 이용해 분당 수백 번의 승차 관련 정보를 로그 데이터로 저장한 후 아마존 S3에 대량
로드하거나 하둡에 담아 스트리밍 처리
9. 스포티파이
Ⅰ. 카프카를 이용한 데이터 파이프라인 구축
▶ 카프카를 데이터 허브로 이용해 사용자의 각종 로그 정보를 수집하고 분석해 플레이리스트
자동 제공 서비스 등을 제공
10. 카프카 스트림즈
Ⅱ. 카프카 스트림즈
▶ 카프카에 저장된 데이터를 처리하고 분석하기 위해 개발된 클라이언트 라이브러리
▶ 레코드별 스트림 처리를 milliseconds latency로 지원
▶ 자바나 스칼라 어플리케이션 안에서 카프카 스트림즈 API를 호출해 사용
▶ 손쉽게 스트림 프로세싱 프로그램을 만들 수 있도록 고수준의 스트림 DSL 지원
▶ DSL로 구혀한 프로세서들이 스트림 처리를 위해 서로 연결된 토폴로지를 만들어 처리
▶ 간단하고 가벼우며 시스템이나 카프카에 대한 의존성이 없음
▶ 카프카 브로커나 클라언트에 장애가 생겨도 스트림에 대해 1번만 처리되도록 보장
▶ 한 번에 한 레코드만 처리하며 이중화된 로컬 상태 저장소를 지원
11. 카프카 스트림즈
▶ Kafka Stream DSL
- 스트림과 테이블에 대한 추상화 제공( Kstream, Ktable, GlobalKTable)
- 함수형 스타일의 다양한 transformation 제공(map, filter aggregation, join ,windowing)
- DSL을 사용해서 토폴로지를 구성할 수 있음
▶ DSL을 이용해 토폴로지를 구성하는 순서
1. 카프카 토픽으로부터 데이터를 읽어 들이는 input 스트림을 지정
- input topic -> Kstream : Kstream은 분할된 레코드 스트림을 나타낸다.
Input 토픽의 모든 파티션 데이터의 집합
- input topic -> Ktable : 키값의 중복여부에 따라 insert/update/delete로 해석됨
interactive queries를 지원 시 테이블 이름을 지정하지 않으면 사용불가
2. input 스트림의 Transformation 구성
- transformation operation 들은 하나 이상의 프로세서로 변형 및 체이닝되어 복잡한 토폴로지 구성
- KStream관련 Operation : 하나 이상의 KStream 이나 KTable을 생성
- KTable 관련 Operation : KTable 만 생성
3. output 스트림을 카프카 토픽에 기록
Ⅱ. 카프카 스트림즈
12. 카프카 스트림즈
▶ Transformation
1. stateless transformation : 처리를 위해 상태를 저장할 필요가 없음(State Store 불필요)
- Branch : 조건에 따라 하나 이상의 Kstream으로 분리
- Filter : 특정 조건을 만족하면 output stream으로 전달
- FlatMap : 하나의 레코드로 0개 이상의 레코드를 생성할 때 사용
레코드의 Key, Value, Type을 바꿀 수 있음
- GroupByKey : 키를 이용해 레코드들을 그룹화. 테이블을 aggregation하기 위한 전제조건이며
후속 operation 들을 위해 레코드들이 Key로 적절히 분할되도록 함
- Map : 하나의 레코드를 다른 레코드로 만듬. Key, Value, Type을 수정할 수 있음
- MapValues : 하나의 레코드를 다른 레코드로 만듬. 이때 Key는 변하지 않고 Value만 변경
2. Stateful transformation : input 레코드를 처리하기 위해서 상태값에 의존(State Store 필요)
- Aggragating : 레코드들의 groupBy, groupByKey로 그룹화 되면 KGroupedStream 혹은
KGroupedTable로 표현됨.
또한 reduce, adder, subtractor 같은 연산을 통해 집계될 수 있음
- Joining : Stream과 Table의 조인, 데이터베이스의 변경된 데이터를 카프카로 보냄.
Stream API를 이용해 로컬 조인을 수행해서 원격 데이터베이스의 부하와 latency를
크게 줄일 수 있음
- Windowing : Windowing을 사용하면 aggregation이나 join같은 Stateful 연산을 할 때 같은
Key를 가지는 레코드들을 windows라고 불리는 그룹으로 그룹화할 수 있음.
Ⅱ. 카프카 스트림즈
13. 카프카 SQL(KSQL)
▶ 카프카용 스트리밍 SQL 엔진
▶ 자바나 파이썬 같은 프로그래밍 언어로 코드를 만들 필요없이 간단한 유사 SQL문을 사용가능
▶ 필터링, 변환, 집계, 조인, 윈도우, 세션화 등의 강력한 기능을 사용할 수 있음
▶ 카프카 스트림즈 API와 마찬가지로 스트림과 테이블이라는 핵심적인 데이터 추상화 방법을 제공
▶ 자바나 스칼라에 익숙하지 않은 개발자나 데이터엔지니어, 아키텍트 등의 담당자에게 유용
▶ 현재는 KsqlDB라는 이름으로 변경되어 발전 중
Ⅲ. 카프카 SQL(KSQL)
14. 카프카 SQL(KSQL)
▶ KSQL 아키텍처
- KSQL 엔진 : KSQL 쿼리가 실행되는 곳. KSQL 쿼리를 작성하고 실행하면 KSQL 서버 안에서
application을 빌드하고 실행함. 각 KSQL 서버는 KSQL 엔진을 인스턴트로 실행
- REST 인터페이스 : KSQL 엔진에 클라이언트로 접근할 수 있는 인터페이스
REST 서버는 KSQL 엔진과 통신하면서 어플리케이션과 REST 통신 시 사용
- KSQL CLI : 콘솔화면에서 Mysql이나 PostgresSQL의 CLI와 유사한 사용법으로 KSQL 엔진에
접근할 수 있도록 함
- KSQL UI : Confluent Control Center를 사용해 KSQL을 접근가능하게 도와줌
▶ KSQL 주요 용어
- STREAM : 구조화된 데이터의 연속된 흐름. 추가는 가능하지만 변경되거나 삭제되지 않음
스트림 데이터는 카프카 토픽이나 이미 존재하는 다른 스트림으로부터 파생하여 만듬
- TABLE : 전통적인 데이터베이스의 테이블과 거의 동일하며 스트림 혹은 windowing을 통해 더
효과적인 데이터를 얻을 수 있음. 업데이트/삭제할 수 있으며 카프카토픽이나 이미 존재하는
스트림 또는 테이블로부터 파생하여 만들 수 있음
- STRUCT : KSQL 5.0 보다 높은 버전을 사용하면 Avro 또는 JSON 형식의 데이터를 STRUCT 타입으로
stream 또는 table을 생성할 수 있음.
Ⅲ. 카프카 SQL(KSQL)
15. 카프카 SQL(KSQL)
▶ KSQL 커스텀 function(UDF, UDAF)
- KSQL API를 사용해 커스텀 function들을 개발하여 추가할 수 있음
- Stateless scalar function(UDF)
-> User Defiend Function으로 불리는 scalar function은 1개의 row를 받으면 1개의 데이터를
output으로 리턴
Ⅲ. 카프카 SQL(KSQL)