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 단위 성능을 기준으로 예측이 가능할 것 같다.
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
클라우드 네이티브로의 전환이 확산되면서 애플리케이션을 상호 독립적인 최소 구성 요소로 쪼개는 마이크로서비스(microservices) 아키텍쳐가 각광받고 있는데요.
MSA는 애플리케이션의 확장이 쉽고 새로운 기능의 출시 기간을 단축시킬 수 있다는 장점이 있지만,
반면에 애플리케이션이 커지고 동일한 서비스의 여러 인스턴스가 동시에 실행되면 MSA간 통신이 복잡해 진다는 단점이 있습니다.
서비스 메쉬(Service Mesh)는 이러한 MSA의 트래픽 문제를 보완하기 위해 탄생한 기술로,
서비스 간의 네트워크 트래픽 관리에 초점을 맞춘 네트워킹 모델입니다.
서로 다른 애플리케이션이 얼마나 원활하게 상호작용하는지를 기록함으로써 커뮤니케이션을 최적화하고 애플리케이션 확장에 따른 다운 타임을 방지할 수 있습니다.
서비스 메쉬의 탄생 배경과 기능, 그리고 현재 오픈소스로 배포되어 있는 서비스 메쉬 솔루션에 대해 소개합니다.
Step1. Cloud Native Trail Map
Step2. Service Proxy, Discover, & Mesh
Step3. Service Mesh 솔루션
Step4. Service Mesh 구현화면 - Istio / linkerd
Step5. Multi-cluster (linkerd)
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 단위 성능을 기준으로 예측이 가능할 것 같다.
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
클라우드 네이티브로의 전환이 확산되면서 애플리케이션을 상호 독립적인 최소 구성 요소로 쪼개는 마이크로서비스(microservices) 아키텍쳐가 각광받고 있는데요.
MSA는 애플리케이션의 확장이 쉽고 새로운 기능의 출시 기간을 단축시킬 수 있다는 장점이 있지만,
반면에 애플리케이션이 커지고 동일한 서비스의 여러 인스턴스가 동시에 실행되면 MSA간 통신이 복잡해 진다는 단점이 있습니다.
서비스 메쉬(Service Mesh)는 이러한 MSA의 트래픽 문제를 보완하기 위해 탄생한 기술로,
서비스 간의 네트워크 트래픽 관리에 초점을 맞춘 네트워킹 모델입니다.
서로 다른 애플리케이션이 얼마나 원활하게 상호작용하는지를 기록함으로써 커뮤니케이션을 최적화하고 애플리케이션 확장에 따른 다운 타임을 방지할 수 있습니다.
서비스 메쉬의 탄생 배경과 기능, 그리고 현재 오픈소스로 배포되어 있는 서비스 메쉬 솔루션에 대해 소개합니다.
Step1. Cloud Native Trail Map
Step2. Service Proxy, Discover, & Mesh
Step3. Service Mesh 솔루션
Step4. Service Mesh 구현화면 - Istio / linkerd
Step5. Multi-cluster (linkerd)
데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...Amazon Web Services Korea
AWS re:Invent에서는 다양한 고객들의 요구에 맞추어 새로운 분석 및 서버리스 서비스가 대거 출시되었습니다. 본 강연에서는 새롭게 출시된 핵심 분석 기능들과 함께, 누구나 손쉽게 사용할 수 있는 AWS의 분석 서버리스와 On-demand 기능들에 대한 심층적인 정보를 확인하실 수 있습니다.
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
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
카카오 광고 플랫폼 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을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...Amazon Web Services Korea
AWS re:Invent에서 소개된 개발에서 운영까지 이어지는 파이프라인 전체에 대한 최신 기술을 통해, 사일로를 분리하고 협업을 향상하는 방법을 소개합니다. 거버넌스 제어를 위한 AWS Control Tower, 코드 수준에서의 위험성 사전 탐지를 위한 Amazon CodeGuru Reviewer, 더 빠르고 풍부한 기능의 앱 제작을 위한 AWS Amplify Studio, IaC를 위한 AWS Cloud Development Kit, 그리고 운영 효율성을 향상 시키는 Amazon CloudWatch의 신규 기능을 알아봅니다.
PUBG: Battlegrounds 라이브 서비스 EKS 전환 사례 공유 [크래프톤 - 레벨 300] - 발표자: 김정헌, PUBG Dev...Amazon Web Services Korea
PUBG: Battlegrounds를 위한 게임 관련 인프라를 EKS 기반 환경으로 모두 전환한 경험에 대해 공유해 드릴 예정입니다. PUBG의 글로벌 서비스를 위한 인프라 구성에 대해 간단히 소개하고, 라이브 서비스 중인 인프라를 EC2 기반에서 EKS 기반으로 점진적으로 전환하면서 겪었던 문제들과 소중한 경험들을 사례를 통해 전달해드립니다.
AWS SAM으로 서버리스 아키텍쳐 운영하기 - 이재면(마이뮤직테이스트) :: AWS Community Day 2020 AWSKRUG - AWS한국사용자모임
AWS SAM을 사용하게 된 계기를 설명드리고, AWS SAM template이 Cloudformation위에서 운영되기 때문에 Cloudformation에서 사용되는 주요 기능들을 설명합니다. 그리고 Infrastructure as code를 위한 Pipeline을 구축할 때 Cloudformation과 함께 사용할 수 있는 Tool들을 설명합니다. API Gateway, Lambda, SQS, SNS, DynamoDB(경우에 따라서는 VPC 설정과 함께 Elasticache와 RDS)로 구성된 비교적 단순한 시스템에 AWS SAM을 사용한 경험을 바탕으로 준비가 되었습니다. 아주 복잡한 시스템에 AWS SAM을 적용한 것이 아니기 때문에 이부분에서는 내용이 한계가 있을 수 있습니다.
AWS Transit Gateway를 통한 Multi-VPC 아키텍처 패턴 - 강동환 솔루션즈 아키텍트, AWS :: AWS Summit ...Amazon Web Services Korea
AWS Transit Gateway를 통한 Multi-VPC 아키텍처 패턴
강동환 솔루션즈 아키텍트, AWS
고객의 조직, 서비스 구조에 따라 함께 늘어나는 VPC를 효과적으로 통합, 관리, 운영하기 위한 서비스와 아키텍처 패턴을 소개합니다. Peering의 한계를 넘어 VPC간 자유로운 연동을 제공하는 Transit Gateway(TGW), 조직내 다양한 Account간의 VPC 공유를 위한 Multi-Account VPC(MAVPC), 그리고 AWS 자원의 안전한 공유를 제공하기 위한 Resource Access Manager(RAM)를 활용하는 다양한 아키텍처 패턴을 살펴봅니다.
AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집Amazon Web Services Korea
* 발표 동영상: https://youtu.be/r84IuPv_4TI
AWS 서비스 환경을 대상으로 하는 각종 보안 위협에 대응하기 위해 인터넷에서 유입되는 트래픽에 대한 안전한 보호와 VPC 내부에서 발생할 수 있는 다양한 네트워크 트래픽을 보다 효율적이고 안전하게 보호할 수 있는 네트워크 보안 구성 방안과 모범 사례에 대해 소개합니다.
기존에 저희 회사에서 사용하던 모니터링은 Zabbix 였습니다.
컨테이너 모니터링 부분으로 옮겨가면서 변화가 필요하였고, 이에 대해서 프로메테우스를 활용한 모니터링 방법을 자연스럽게 고민하게 되었습니다.
이에 이영주님께서 테크세션을 진행하였고, 이에 발표자료를 올립니다.
5개의 부분으로 구성되어 있으며, 세팅 방법에 대한 내용까지 포함합니다.
01. Prometheus?
02. Usage
03. Alertmanager
04. Cluster
05. Performance
데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...Amazon Web Services Korea
AWS re:Invent에서는 다양한 고객들의 요구에 맞추어 새로운 분석 및 서버리스 서비스가 대거 출시되었습니다. 본 강연에서는 새롭게 출시된 핵심 분석 기능들과 함께, 누구나 손쉽게 사용할 수 있는 AWS의 분석 서버리스와 On-demand 기능들에 대한 심층적인 정보를 확인하실 수 있습니다.
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
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
카카오 광고 플랫폼 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을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...Amazon Web Services Korea
AWS re:Invent에서 소개된 개발에서 운영까지 이어지는 파이프라인 전체에 대한 최신 기술을 통해, 사일로를 분리하고 협업을 향상하는 방법을 소개합니다. 거버넌스 제어를 위한 AWS Control Tower, 코드 수준에서의 위험성 사전 탐지를 위한 Amazon CodeGuru Reviewer, 더 빠르고 풍부한 기능의 앱 제작을 위한 AWS Amplify Studio, IaC를 위한 AWS Cloud Development Kit, 그리고 운영 효율성을 향상 시키는 Amazon CloudWatch의 신규 기능을 알아봅니다.
PUBG: Battlegrounds 라이브 서비스 EKS 전환 사례 공유 [크래프톤 - 레벨 300] - 발표자: 김정헌, PUBG Dev...Amazon Web Services Korea
PUBG: Battlegrounds를 위한 게임 관련 인프라를 EKS 기반 환경으로 모두 전환한 경험에 대해 공유해 드릴 예정입니다. PUBG의 글로벌 서비스를 위한 인프라 구성에 대해 간단히 소개하고, 라이브 서비스 중인 인프라를 EC2 기반에서 EKS 기반으로 점진적으로 전환하면서 겪었던 문제들과 소중한 경험들을 사례를 통해 전달해드립니다.
AWS SAM으로 서버리스 아키텍쳐 운영하기 - 이재면(마이뮤직테이스트) :: AWS Community Day 2020 AWSKRUG - AWS한국사용자모임
AWS SAM을 사용하게 된 계기를 설명드리고, AWS SAM template이 Cloudformation위에서 운영되기 때문에 Cloudformation에서 사용되는 주요 기능들을 설명합니다. 그리고 Infrastructure as code를 위한 Pipeline을 구축할 때 Cloudformation과 함께 사용할 수 있는 Tool들을 설명합니다. API Gateway, Lambda, SQS, SNS, DynamoDB(경우에 따라서는 VPC 설정과 함께 Elasticache와 RDS)로 구성된 비교적 단순한 시스템에 AWS SAM을 사용한 경험을 바탕으로 준비가 되었습니다. 아주 복잡한 시스템에 AWS SAM을 적용한 것이 아니기 때문에 이부분에서는 내용이 한계가 있을 수 있습니다.
AWS Transit Gateway를 통한 Multi-VPC 아키텍처 패턴 - 강동환 솔루션즈 아키텍트, AWS :: AWS Summit ...Amazon Web Services Korea
AWS Transit Gateway를 통한 Multi-VPC 아키텍처 패턴
강동환 솔루션즈 아키텍트, AWS
고객의 조직, 서비스 구조에 따라 함께 늘어나는 VPC를 효과적으로 통합, 관리, 운영하기 위한 서비스와 아키텍처 패턴을 소개합니다. Peering의 한계를 넘어 VPC간 자유로운 연동을 제공하는 Transit Gateway(TGW), 조직내 다양한 Account간의 VPC 공유를 위한 Multi-Account VPC(MAVPC), 그리고 AWS 자원의 안전한 공유를 제공하기 위한 Resource Access Manager(RAM)를 활용하는 다양한 아키텍처 패턴을 살펴봅니다.
AWS 네트워크 보안을 위한 계층별 보안 구성 모범 사례 – 조이정, AWS 솔루션즈 아키텍트:: AWS 온라인 이벤트 – 클라우드 보안 특집Amazon Web Services Korea
* 발표 동영상: https://youtu.be/r84IuPv_4TI
AWS 서비스 환경을 대상으로 하는 각종 보안 위협에 대응하기 위해 인터넷에서 유입되는 트래픽에 대한 안전한 보호와 VPC 내부에서 발생할 수 있는 다양한 네트워크 트래픽을 보다 효율적이고 안전하게 보호할 수 있는 네트워크 보안 구성 방안과 모범 사례에 대해 소개합니다.
기존에 저희 회사에서 사용하던 모니터링은 Zabbix 였습니다.
컨테이너 모니터링 부분으로 옮겨가면서 변화가 필요하였고, 이에 대해서 프로메테우스를 활용한 모니터링 방법을 자연스럽게 고민하게 되었습니다.
이에 이영주님께서 테크세션을 진행하였고, 이에 발표자료를 올립니다.
5개의 부분으로 구성되어 있으며, 세팅 방법에 대한 내용까지 포함합니다.
01. Prometheus?
02. Usage
03. Alertmanager
04. Cluster
05. Performance
Cloud-Native Architecture
MSA(Micro Service Architecture)
MDA(Micro Data Architecture)
MIA(MIcro Inference Architecture)
MSA-Service Mesh
MDA-Data Mesh
MIA-AI Inference Mesh
Kubernetes
Container
Kubeflow
Volcano
Apache Ynikorn
ChatGPT
AGI(Artificial General Intelligence)
ASI(Artificial Specialized Intelligence)
초-전환시대
초-연결시대
SQream GPU DBMS
Cloud와 Cloud Native의 목표는.. 왜? 어떻게? 뭐가 좋아지나...
1. (왜) 가속화된 초-전환, 초-연결 IT 환경변화에 대비하기 위해서
2. (어떻게-H/W) IT H/W 부분은 IaaS 서비스화하여
점유된, Over Subscription된 H/W(Server, Network, Storage)들 모아서 Pool화하고, 가상화기술을 통해 Tenant로 자원들을 분리해 서비스화해 제공하고
필요시 적시에 Pool의 가상H/W를 제공하고, 상황에 따라 확장・축소(Scale in/out, up/down)하면서, 축소된 자원을 다른 요청들을 위해 빠르게 재-할당하는 유연성을 제공하고
3. (어떻게-S/W) S/W 부문도
PaaS, SaaS 적극 활용으로 App.개발 시간을 단축하고
App.분야인 기존 MACRO Service Architecture형 Monolith Architecture(Web-WAS-DB)를 작게 쪼개서 변화에 빠르게 적응할 수 있는 MSA(Micro Service Architecture)로 변경하여 Service Mesh형으로 관리하고
Data분야도 Data Warehouse, DataLake(Bigdata), LakeHouse등 기존 MACRO Data Architecture를 MSA형식으로 MDA(Micro Data Architecture)로 전환 후 Data Mesh형태로 관리하고,
AI로 동적프로그램 생성하여 App.개발시간 단축하고, AI분야도 초-거대 AI구현(MACRO)보다는 작은|특화된 Deep Learning Network(Model)들로 작게 쪼개서 MIA(Micro Inference Architecture)로 비지니스 환경에 적용하고 Inference Mesh형태로 관리하는 시스템으로 전환하고
4. (어떻게-조직) 조직구조도 CI/CD형 DevOps환경, 데이타,트랜잭션중심업무중심, 기술중심 문제해결중심, 직능중심조직직무중심조직으로 전환하면
5. (좋아지는 것) 초-전환, 초-연결 환경에 빠르고, 지속적으로 적응할 수 IT as a Product 환경을 구현하는 것
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
모바일 앱 성능 분석 방법 101 (Mobile Application Performance Analysis Methodology 101) YoungSu Son
모바일 앱 성능 분석 방법에 대해서 설명을 드립니다
- 기존 서버 APM과 모바일에서의 성능 기준의 차이
- 모바일 제약사항및 아키텍처
- 안드로이드는 어떻게 발전해 왔나
- Vectorization
- Loop
- Redex / Optimized Layout
- Garbage Collector
- 제조사가 보장해야 되는 성능
- 개발사가 고민해야 되는 영역
- 실사례 설명
- 갤럭시노트 2의 점유율
- Xiaomi 폰의 국내 4위 시장 점유율
- 여러가지 모바일 성능 리포트
14. 클라우드 환경에서 수집해야 되는 대표적인 지표 몇개.
§ IOPS
§ Disk Queue Length (win) / iowait (linux)
§ CPU Steal Time 등..
§ http://bencane.com/2012/08/06/troubleshooting-high-
io-wait-in-linux/
15. 클라우드 모니터링은 인스턴스를 애완동물보다 가축으로 보아야 한다.
(Server , VM vs Cloud Instance)
16. 클라우드 에서의 성능 측정이 어려운 이유..
첫째, 일부 부분은 우리가 통제할 수 없다.
우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만
어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다.
우리가 모든 환경을 통제할 수 없으니 정확하게 느려지거나
단절 되는 이유를 알아내기 매우 힘들다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
17. 클라우드 에서의 성능 측정..
둘째, 일부 성능 측정 도구는
작은 실험실 규모에서만 효과가 측정되어 클라우드 규모에서는 동작하지 않는다.
점점 큰 규모의 시스템에서 배포하는 것이 쉬워지면서,
운영 대시보드와 경보기를 엄청나게 설치하지 않는다면
작은 오버헤드와 이용할 수 있는 성능 정보를 얻는 것은 어려워지고 있다.
많은 수의 서버에서 발생하는 문제를 추적 할 수 있는 능력은 더더욱 중요시 되고 있다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
18. 클라우드 에서의 성능 측정..
셋째,
클라우드 환경은 탄력성(scale in/out, lambda)이 있어서
일부 성능 최적화 기술은 시대의 뒤처지거나 관련 없다.
특정 프로세서, 메모리 크기, 네트워크 설정 또는 특정 클라우드 업체에 얽매어 있을 필
요가 없다.
과거에 사용하던 설정은 다시는 투자 대비 성과 (ROI)를 얻을 수 없다.
다른 설정을 해야 수십 억을 서버에 쓰지 않고 배포를 최적화할 수 있다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
20. 직접 구축시 생각보다 신경쓸게 많다. 하지만 내마음대로 주무를 수 있다.
저장소 , 알럿 시스템 구축, 화면 시각화도 어떻게 할지 고민.
그럼 어떠한 것을 고려해서 구축해야 할까?
21. Server 모니터링
수집부
모든 Server가 모니터링 수집부로 특정 기간마다 데이터를 전송하는 방법.
서버가 데이터가 주기적으로 안 들어오면 다운으로 인지.
Network
단점1. 모든 서버의 Outbound Port를 열어야 한다.
단점2. 네트워크 가용성이 좋지 않으면, 서버도 다운 된 것으로 인지..
#1. 알럿 정책
22. Server 모니터링
서버
대부분의 서버는 Private 영역에 존재한다.
모든 아웃바운드 포트를 열지 말고 Proxy를 통해서 열도록 할것.
Network
단점. 네트워크 가용성이 좋지 않으면, Server도 다운 된 것으로 인지..
Proxy
23. 가용성에 대한 고민이 필요!!
서버 가용성과 네트워크 가용성을 분리해야 한다!
네크워크 가용성은 무시할 것인가? 아니면 받아들일 것인가?
24. 가용성 정책을 분리! (네트워크 가용성 / 서버 다운을 분리)
Server
모니터링 서버
특정시간 동안 Device로 응답이 없으면, 네트워크 가용성의 문제로 인식
특히 모든 디바이스가 동시에 데이터가 안들어오면 네트워크 문제일 확율 90% 이상
Network
Proxy
Network
단절 발생
즉 데이터 없음으로 서버 다운으로 인식하지 마세요!
25. 고객의 Network 존에, 서버 다운을 체크하는 시스템 설치 (push 보다는 pull 모델 지원)
Server
Smart Device
(Proxy)
1. Proxy에서 모든 Device의 데이터가 전송됨
2. 데이터가 오지 않는 Device만 선별적으로 WatchDog이 체크
3. WatchDog이
특정 디바이스에 Ping 또는 Health Message
전송후
응답 없으면 Device Down으로 인지
4. WatchDog이
Device Down 메세지를 모니터링 서버로 전송
모니터링 서버Network
Down
Down
Checker
27. 서버 단에서 봐야하는 자원 병목 포인트
DRAM DRAM
Disk Disk Port Port
CPU
Interconnect
Memory
Bus
CPU
2
Expander Interconnect
Network
Controller
CPU
1
I/O Bus
I/O
Bridge
I/O
Controller
Interface Transports
28. 60초안에 서버 성능 보기.
http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
load averages
kernel errors
overall stats by time
CPU balance
process usage
disk I/O
memory usage
network I/O
TCP stats
check overview
29. 어려운 방법보다 USE 메소드를 이용.
Saturation
Utilization
X
Errors
Utilization : 얼만큼 자원을 썼는지?
Saturation : 얼마나 많은 부하(extra works)가 들어왔는지.
Error : 발생한 에러는?
30. USE 메소드의 예
Resource Type Metric
CPU utilization CPU utilization
CPU saturation run-queue length
Memory utilization Available memory
Memory saturation Paging or swapping
NetworkInterface utilization RX/TX tput / bandwidth
StorageDeviceI/O utilization Device busy percent
StorageDeviceI/O saturation Wait queue length
StorageDeviceI/O errors Device errors
32. 주의할 점 MemFree vs MemoryAvailable.
cat /proc/meminfo
MemFree보다
MemAvailable을 이용하세요.
Ubuntu 14.04이상
MemFree:
The amount of physical RAM, in kilobytes,
left unused by the system.
MemAvailable:
An estimate of how much memory is available
for starting new application
33. 모든 자원 사용의 주체는 프로세스
#3. 프로세스를 모니터링 해라! 가능한 상세히..
34. 프로세스를 그룹별로 모니터링할수 있어야 한다!
프로세스 그룹별 정책
• 프로세스 최소 수, 최대 수
• 프로세스 그룹이 사용하는 CPU 사용량
• 프로세스 그룹이 사용하는 메모리 사용량
36. #5. 운영시 최소한 챙겨야 하는 이벤트 (윈도우)
윈도우 EventID 윈도우 비스타 EventID 이벤트 타입 설명
512, 513, 514, 515, 516,
518, 519, 520
4608, 4609, 4610, 4611, 4
612, 4614, 4615, 4616
System Events Identifies local system processes such as system startup and shutdown and changes to the system time
517 4612 Audit Logs Cleared Identifies all the audit logs clearing events
528, 540 4624 Successful User Logons Identifies all the user logon events
529, 530, 531, 532, 533,
534, 535, 536, 537, 539
4625 Logon Failures Identifies all the failed user logon events
538 4634 Successful User Logoff Identifies all the user logoff events
560, 563, 565, 566
4656, 4658, 4659, 4660, 4
661, 4662, 4663, 4664, 51
47
Object Access
Identifies when a given object (File, Directory, etc.) is accessed, the type of access (e.g. read, write, del
ete) and whether or not access was successful/failed, and who performed the action
612 4719 Audit Policy Changes Identifies all the changes done in the audit policy
624, 625, 626, 627, 628,
629, 630, 642, 644
4720, 4722, 4723, 4724, 4
725, 4726, 4738, 4740
User Account Changes
Identifies all the changes done on an user account like user account creation,deletion, password change
, etc.
(631 to 641) and (643, 6
45 to 666)
4727 to 4737, 4739 to 476
2
User Group Changes
Identifies all the changes done on an user group such as adding or removing a global or local group, ad
ding or removing members from a global or local group, etc.
672, 680 4768, 4776 Successful User Account Validation
Identifies successful user account logon events, which are generated when a domain user account is au
thenticated on a domain controller
675, 681 4771, 4777 Failed User Account Validation
Identifies unsuccessful user account logon events, which are generated when a domain user account is
authenticated on a domain controller
682, 683 4778, 4779 Device Session Status Identifies the session re-connection or disconnection
37. 운영시 최소 한 챙겨야 하는 syslog (리눅스)
/var/log/messages : General message and system related stuff
/var/log/auth.log : Authenication logs
/var/log/kern.log : Kernel logs
/var/log/cron.log : Crond logs (cron job)
/var/log/maillog : Mail server logs
/var/log/qmail/ : Qmail log directory (more files inside this directory)
/var/log/httpd/ : Apache access and error logs directory
/var/log/lighttpd/ : Lighttpd access and error logs directory
/var/log/boot.log : System boot log
/var/log/mysqld.log : MySQL database server log file
/var/log/secure or /var/log/auth.log : Authentication log
/var/log/utmp or /var/log/wtmp : Login records file
/var/log/yum.log : Yum command log file.
추가 정보는 http://bit.ly/2ujaNJm 를 참고
39. Docker에서 자원에 대한 정보를 얻어오면 몇몇 지표는
Docker의 자원 사용량이 아닌, Host OS의 정보를 얻어온다..
40. 결국 Docker는 Linux 입장에서 프로세스.
# PID of the docker daemon
ps aux | grep -E 'docker (-d|daemon)’
root 665 0.0 0.4 1521560 17156 ? Ssl janv.06 5:47 /usr/bin/docker -d -H fd://
# find child processes of the docker daemon pgrep -P 665
4076
4135
4210
# figure out details of a process ps 4076
PID TTY STAT TIME COMMAND
4076 ? Ssl 10:45 /usr/bin/redis-server 0.0.0.0:6379
# repeat for other child processes
41. Docker에서 수집할수 있는 지표들 (제한적.)
v 위 이미지는 A사가 제공하는 지표
v 실제 공식 Docker runtime 매트릭
v https://docs.docker.com/v1.8/engine/articles/runmetrics/
43. #7. 모니터링 수집 DB는 RDBMS가 적합하지 않습니다.
v RDBMS는 태생이 Read가 많은 서비스에 적합. -> 모니터링은 Time Series DB가 적합하다.
v 이에 반해 모니터링은 Write가 압도적으로 많고, 대부분 시간 순서도 데이터를 읽음.
v Memory 비용 비쌈. -> 1G에 월 1만원이 시장가격
44. #8. 데이터 전송 방식은 20초 이내로 짧은 주기로 Stream으로 잘잘잘..
HTTP로 1분마다 뭉쳐서 보내면, 이러한 현상이 발생합니다.
(여러분이 종종 쓰는 오픈소스들은.. 알고보면 시스템 운영자에게는 재앙)
46. #9. 가용성 (가용률에 대한 서비스 불능 시간)
가용률 연간 서비스 불능시간 월간 서비스 불능시간 주간 서비스 불능시간
99.9999% 31.50초 2.59초 0.605초
99.999% 5.26분 24.9초 6.05초
99.99% 52.56분 4.32분 1.01분
99.9% 8.76시간 43.8분 10.1분
99% 3.65일 7.2시간 1.68시간
Public Cloud의 가용성은
99% < Public Cloud <99.9% 보통 20~30시간 내외
51. - 51 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved.
자원은 노는데, 장애가 난다면..
반면, WAS의 CPU, Memory 사용량은 정상
종료되지 않고 지연중인
트랜잭션 500개 이상
트랜잭션 지연트랜잭션 지연
72. 일반적인 해결책은 Static + Dynamic Profiling
User
MEM
CPU
GC
SQL
CONN
CONN
Static Profiling
Static Profiling
Static Profiling
1. 의심되는 메소드 지정
(Dynamic Profiling)
2. 의심되는 메소드 지정
4. 의심되는 메소드 지정
88. 이유..
• Public Cloud의 LB는 두가지 알고리즘 제공
• Round Robin
• Sticky Session
• 별도의 Health Check가 있으나. 서버와의 ping체크로
인스턴스 제어.
• 즉 고객 서비스의 응답시간으로 측정할 방법 없음.
89. 결론.. 직접 위 사항들을 다 고려해서 만드시거나..
아니면 위 고민이 다 반영되어 있은 저희 제품을 구매하시거나..
90. - 90 - Copyright ⓒ 2017 by WhaTap Labs. All rights reserved.
스타트업을 위한 가격
10만원 67% 할인 : Infra 모니터닝 10 VM (1달 = 5만원) + APM (10코어 = 25만원)
20만원 67% 할인 : Infra 모니터닝 20 VM (1달 = 10만원) + APM (20코어 = 50만원)
문의는 salesteam@whatap.io 또는 ysson@whatap.io 로 주세요.
와탭은 제안드립니다.
대분류 가격 모델 1 core 2 core 4 core 이상
VM
&
Dedicated
1 month retention 1,250 2,500 5,000
12 month retention 2,500 5,000 10,000
• 사실상 4 core 이상은 동일 가격이므로, 기존 인스턴스 체계 유지
• 1, 2 core의 경우 할인해주는 방식
저희 가격은 10대를 써도 5만원.
직접 여러분이 만드시는 고생과 노력의 비용 + 4 Core VM 한달 유지비만 8만원..