AWS EMR을 사용하면서 비용을 최적화하기 위해 필요한 다양한 관점의 방안을 검토하여 정리한 자료.
비용 최적화 대상은 zeppelin/jupyter notebook과 apache spark를 활용하는 서비스를 대상으로 하였으며, 해당 작업이 aws emr에서 어떻게 동작하는지 내부 구조을 파악하여 확인함.
- AWS EMR이란?
- AWS EMR의 과금 방식은?
- 어떻게 비용을 최적화 할 것인가?
- 최적의 EMR 클러스터 구성 방안
- 가성비 높은 Instance 선정 방안
- Apache Spark 성능 개선 방안
가장 중요한 것은 실행할 job의 자원사용량/성능을 모니터링하고, 이에 맞게 자원을 최적화하는 것이 필요함.
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
Just Model It 이벤트에서 사용할 Backend.AI 에 관한 소개입니다. Backend.AI의 개괄, 주요 기능 및 사용예들을 다룹니다. 또한 Backend.AI 를 이용한 End-to-end ML model 개발 시나리오도 소개합니다.
An Introduction to Backend.AI to use in Just Model It event. It covers the overview of Backend.AI, its main features and examples. It also introduces the scenario of developing end-to-end ML model using Backend.AI.
AWS EMR을 사용하면서 비용을 최적화하기 위해 필요한 다양한 관점의 방안을 검토하여 정리한 자료.
비용 최적화 대상은 zeppelin/jupyter notebook과 apache spark를 활용하는 서비스를 대상으로 하였으며, 해당 작업이 aws emr에서 어떻게 동작하는지 내부 구조을 파악하여 확인함.
- AWS EMR이란?
- AWS EMR의 과금 방식은?
- 어떻게 비용을 최적화 할 것인가?
- 최적의 EMR 클러스터 구성 방안
- 가성비 높은 Instance 선정 방안
- Apache Spark 성능 개선 방안
가장 중요한 것은 실행할 job의 자원사용량/성능을 모니터링하고, 이에 맞게 자원을 최적화하는 것이 필요함.
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
Just Model It 이벤트에서 사용할 Backend.AI 에 관한 소개입니다. Backend.AI의 개괄, 주요 기능 및 사용예들을 다룹니다. 또한 Backend.AI 를 이용한 End-to-end ML model 개발 시나리오도 소개합니다.
An Introduction to Backend.AI to use in Just Model It event. It covers the overview of Backend.AI, its main features and examples. It also introduces the scenario of developing end-to-end ML model using Backend.AI.
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
[ 2018 컨테이너 기술의 모든 것 ] NBP 박기은 CTO 세션에서 소개된 네이버 클라우드 플랫폼의 컨테이너 기술 관련 서비스 및 향후 로드맵을 공유합니다.
[ 2018 All About Container ] Presentation about container technology & service roadmap of NAVER CLOUD PLATFORM by NBP cloud solution CTO "Park Ki Eun"
Lablup Conf 1st (Keynote/Core)
"The good, the bad, the weird: Future of Backend.AI" - 신정규
발표내용
- Road to Backend.AI. Current and the future.
영상보러가기
- https://youtu.be/5askMmSumP4
네이버 클라우드 플랫폼의 Kubernetes Service(NKS)에서 Pod들의 오토스케일을 적용하는 방법에 대해서 소개합니다 | Introduce how to apply autoscale of Pods in the Kubernets Service (NKS) of Naver Cloud Platform
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
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
[ 2018 컨테이너 기술의 모든 것 ] NBP 박기은 CTO 세션에서 소개된 네이버 클라우드 플랫폼의 컨테이너 기술 관련 서비스 및 향후 로드맵을 공유합니다.
[ 2018 All About Container ] Presentation about container technology & service roadmap of NAVER CLOUD PLATFORM by NBP cloud solution CTO "Park Ki Eun"
Lablup Conf 1st (Keynote/Core)
"The good, the bad, the weird: Future of Backend.AI" - 신정규
발표내용
- Road to Backend.AI. Current and the future.
영상보러가기
- https://youtu.be/5askMmSumP4
네이버 클라우드 플랫폼의 Kubernetes Service(NKS)에서 Pod들의 오토스케일을 적용하는 방법에 대해서 소개합니다 | Introduce how to apply autoscale of Pods in the Kubernets Service (NKS) of Naver Cloud Platform
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
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 개발 추진 방향
source : http://www.opennaru.com/opensource/kubernetes/
Kubernetes는 컨테이너화된 애플리케이션(Containerized Application)의 배포, 확장 그리고 관리를 할 수 있는 오픈 소스 컨테이너 오케스트레이션 시스템입니다.
쿠버네티스는 구글 엔지니어들이 개발하고 설계한 플랫폼으로서 사내에서 이용하던 컨테이너 클러스터 관리 도구인 “Borg”의 아이디어를 바탕으로 만들어진 오픈소스 소프트웨어입니다.
구글은 쿠버네티스의 원천이 되는 Borg를 수년 동안 개발하고 운영하면서 축적된 경험을 바탕으로 쿠버네티스를 오픈소스 프로젝트로 만들어 었습니다.
클라우드에서 인프라 구축 시 고려해야 할 사항들을 살펴보고, 네이버 클라우드 플랫폼을 활용하여 고가용성을 유지하는 방안에 대해 소개합니다. | Explore the considerations of building infrastructure in the cloud and introduce ways to maintain high availability by leveraging the Naver cloud platform.
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
8. Horizontal Pod Autoscaler(HPA)
• Pod replica의 갯수를 변경하여 scaling.
• CPU와 memory의 metrics를 base로 하여 scaling을 trigger.
• Multiple metrics, Custom metrics, external metrics를 base로
사용하는 것도 가능.
10. HPA에 대해서 알아둘 것들
• 기본 HPA sync 주기는 30초.
→ controller manager의 --horizontal-pod-autoscaler-sync-period flag로 변경 가능.
• HPA는 metrics가 안정되도록 HPA event 후에 3분을 기다린 후에 scale-up event를 발생시킨다.
→ kube-controller-manage의 --horizontal-pod-autoscaler-upscale-delay flag로 변경 가능.
• HPA는 replica의 개수가 요동치는 변동을 겪지 않도록 HPA event 후에 5분을 기다린 후에 scale-
down event를 발생 시킨다.
→ kube-controller-manage의 --horizontal-pod-autoscaler-downscale-delay flag로 변경 가능.
• HPA는 Deployment object에서 최적으로 동작한다. HPA에서 target으로 설정된 Deployment의
replica를 직접적으로 수정하는 것은 바람직 하지 않다.
11. Custom Metrics를 사용하는 HPA
• autoscaling/v2alpha1 API object를 사용.
• 별도의 configuration 과정이 다수 필요.
• GKE에서는 Stackdriver adapter를 정식으로 지원.
• 이외의 환경에서는 Prometheus adapter를 사용해야 하지만 개발 상태는 초기 상
태.
• application에서 Prometheus format으로 custom metrics를 expose 해야 한다.
13. Vertical Pod Autoscaler(VPA)
• Pod의 CPU와 memory를 변경하여 할당.
• Pod의 restart되어 resource 변경.
• OOM(Out Of Memory) event에 반응.
• Pod에 할당할 수 있는 Min/Max resource를 설정 가능.
• 현재 alpha 개발 상태.
15. VPA에 대해서 알아둘 것들
• VPA의 metrics check 간격은 10초.
• VPA의 변경으로 인해 모든 Pod들이 restart되는 것을 방지하기 위해 Pods Distribution Budget(PDB)
가 반영.
• Pod를 restart하지 않고 resource를 변경할 수 없음.
→ Pod는 stop된 후에 새로 할당된 resource들을 기반으로 rescheduling된다.
• VPA와 HPA는 아직 서로 호환되지 않으며 동일한 pod에서 동작되지 않는다.
→ cluster 내에서 이 둘을 사용하기 위해서는 구성할 때 사용범위를 확실하게 분리해야 한다.
• VPA는 resource request만 조정하고 limit은 설정하지 않으므로 오동작하는 application이 resource
를 잠식할 수 있음에 주의.
22. 실질적인 동작
• CA에서 node를 join 시키는데는 시간이 발생.
→ AWS + kops 환경에서는 5분 정도의 시간이 발생.
• Node resource가 여유가 있다면 HPA, VPA의 scaling은 수십초 내에 완료.
Solution?
Priority and Preemption
• Kubernetes 1.8에서 alpha feature로 소개.
• 1.11에서 beta로 변경, 기본적으로 enable.