급증하는 온라인 사용자 증가, 부하테스트가 필요하지 않으신가요?
요즘 인터넷 뉴스에는 홈페이지 접속자 폭증으로 인한 서버 다운, xx은행 모바일 앱 접속 에러, 인터넷 뱅킹 장애 등 온라인 시장과 모바일 시장이 급격하게 성장함에 따라 이에 따른 장애 소식이 끊이지 않고 전해지고 있습니다.
그렇다면, 우리는 이런 장애들을 어떻게 대비할 수 있을까요?
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 안은 웹∙앱 부하테스트(성능 진단 테스트) 진행 과정과 이를 기반으로 어떻게 컨설팅을 진행하고 있는지 소개하고, 나아가 관련 장애들을 대비할 수 있는 방법에 대해 설명합니다.
(공유드리는 파일은 slideshare에 업로드되었던 웹∙앱 부하테스트 성능 진단 및 컨설팅 안을 업데이트한 최신 본입니다.)
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 자료는 아래와 같이 구성되어있습니다.
• 웹∙앱 성능을 진단하고 문제에 대한 원인 분석 및 개선방향을 제시합니다.
• 컨설팅 안에는 여러 실 성능 진단을 예시로 들고 이에 대한 원인 분석 및 개선방향을 도
출한 내용이 포함되어 있습니다.
1. 앱 성능 진단
• 앱 진단 절차
• 앱 진단 상세 내용
2. 웹 서버 성능 진단
• 웹 진단 절차
• 웹 진단 방향
3. 부하 테스트
• 현 테스트 시나리오 분석
• 테스트 시나리오 보완 방법
• 부하 테스트 진행 방안
• 부하 테스트 전략
• 클라우드 기반 테스트 방안
모바일 성능 모니터링, 웹 서버 성능 진단 및 부하테스트 컨설팅에 관심이 있으신 분은 아래 연락처로 연락해주시면, 전문 컨설턴트가 안내해드리겠습니다.
hhjung@onycom.com l 02-6395-7722
카카오 광고 플랫폼 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을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
급증하는 온라인 사용자 증가, 부하테스트가 필요하지 않으신가요?
요즘 인터넷 뉴스에는 홈페이지 접속자 폭증으로 인한 서버 다운, xx은행 모바일 앱 접속 에러, 인터넷 뱅킹 장애 등 온라인 시장과 모바일 시장이 급격하게 성장함에 따라 이에 따른 장애 소식이 끊이지 않고 전해지고 있습니다.
그렇다면, 우리는 이런 장애들을 어떻게 대비할 수 있을까요?
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 안은 웹∙앱 부하테스트(성능 진단 테스트) 진행 과정과 이를 기반으로 어떻게 컨설팅을 진행하고 있는지 소개하고, 나아가 관련 장애들을 대비할 수 있는 방법에 대해 설명합니다.
(공유드리는 파일은 slideshare에 업로드되었던 웹∙앱 부하테스트 성능 진단 및 컨설팅 안을 업데이트한 최신 본입니다.)
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 자료는 아래와 같이 구성되어있습니다.
• 웹∙앱 성능을 진단하고 문제에 대한 원인 분석 및 개선방향을 제시합니다.
• 컨설팅 안에는 여러 실 성능 진단을 예시로 들고 이에 대한 원인 분석 및 개선방향을 도
출한 내용이 포함되어 있습니다.
1. 앱 성능 진단
• 앱 진단 절차
• 앱 진단 상세 내용
2. 웹 서버 성능 진단
• 웹 진단 절차
• 웹 진단 방향
3. 부하 테스트
• 현 테스트 시나리오 분석
• 테스트 시나리오 보완 방법
• 부하 테스트 진행 방안
• 부하 테스트 전략
• 클라우드 기반 테스트 방안
모바일 성능 모니터링, 웹 서버 성능 진단 및 부하테스트 컨설팅에 관심이 있으신 분은 아래 연락처로 연락해주시면, 전문 컨설턴트가 안내해드리겠습니다.
hhjung@onycom.com l 02-6395-7722
카카오 광고 플랫폼 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을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
오토스케일링(Auto-scaling)은 AWS 클라우드를 통해 고확장성 서비스와 아키텍처를 구성하는 데 필요한 가장 중요한 요소 중 하나입니다. 이 강연에서는 효과적인 클라우드 인프라 구축을 위해 오토 스케일링을 활용하는 다양한 방법에 대해 자세히 소개해 드립니다.
오토 스케일링 그룹의 구성과 확장 계획에 따른 설정 방법, 오토 스케일링 라이프 사이클과 CloudWatch 및 알림을 이용한 관리 방법, 각종 오토스케일링 모범사례 등을 알아보실 수 있습니다.
운영하는 서비스의 전체 또는 일부분을 클라우드의 이점을 100% 얻으며 옮겨가기 위해 서버리스는 가장 좋은 선택입니다. 서버리스 환경은 개발자가 애플리케이션을 개발하고 배포하는 방식을 바꾸고 있습니다. 본 세션에서는 서버리스 개발자가 애플리케이션 수명주기 관리, CI/CD, 모니터링 및 진단에 사용할 수 있는 모범 사례를 살펴 봅니다. AWS CodePipeline, AWS CodeBuild 및 AWS CloudFormation을 사용하여 서버리스 애플리케이션을 자동으로 구축, 테스트 및 배포하는 CI/CD 파이프 라인을 구축하는 방법에 대해 설명합니다. 또한 기능 및 API의 여러 버전, 단계 및 환경을 만들기 위해 Lambda 및 API Gateway의 기본 제공 기능에 대해 설명합니다. 마지막으로, Amazon CloudWatch 및 AWS X-Ray로 람다 기능의 모니터링 및 진단에 대해 소개합니다.
- 동영상 보기: https://www.youtube.com/watch?v=Rq4I57eqIp4
Amazon RDS 프록시는 Amazon Relational Database Service (RDS)를 위한 완전 관리형 고가용성 데이터베이스 프록시로, 애플리케이션의 확장 성, 데이터베이스 장애에 대한 탄력성 및 보안 성을 향상시킬 수 있습니다. (2020년 6월 서울 리전 출시)
성능 진단 및 컨설팅 제안서입니다.
모바일 성능 모니터링, 모바일 자동화 테스트, 웹 서버 성능 테스트를 합리적인 가격에 컨설팅 해 드립니다.
⁍ 업데이트된 최신본 성능 진단 및 컨설팅 제안서 확인해 보세요!
https://www.slideshare.net/IMQAGroup/imqa-performance-consulting
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
오토스케일링(Auto-scaling)은 AWS 클라우드를 통해 고확장성 서비스와 아키텍처를 구성하는 데 필요한 가장 중요한 요소 중 하나입니다. 이 강연에서는 효과적인 클라우드 인프라 구축을 위해 오토 스케일링을 활용하는 다양한 방법에 대해 자세히 소개해 드립니다.
오토 스케일링 그룹의 구성과 확장 계획에 따른 설정 방법, 오토 스케일링 라이프 사이클과 CloudWatch 및 알림을 이용한 관리 방법, 각종 오토스케일링 모범사례 등을 알아보실 수 있습니다.
운영하는 서비스의 전체 또는 일부분을 클라우드의 이점을 100% 얻으며 옮겨가기 위해 서버리스는 가장 좋은 선택입니다. 서버리스 환경은 개발자가 애플리케이션을 개발하고 배포하는 방식을 바꾸고 있습니다. 본 세션에서는 서버리스 개발자가 애플리케이션 수명주기 관리, CI/CD, 모니터링 및 진단에 사용할 수 있는 모범 사례를 살펴 봅니다. AWS CodePipeline, AWS CodeBuild 및 AWS CloudFormation을 사용하여 서버리스 애플리케이션을 자동으로 구축, 테스트 및 배포하는 CI/CD 파이프 라인을 구축하는 방법에 대해 설명합니다. 또한 기능 및 API의 여러 버전, 단계 및 환경을 만들기 위해 Lambda 및 API Gateway의 기본 제공 기능에 대해 설명합니다. 마지막으로, Amazon CloudWatch 및 AWS X-Ray로 람다 기능의 모니터링 및 진단에 대해 소개합니다.
- 동영상 보기: https://www.youtube.com/watch?v=Rq4I57eqIp4
Amazon RDS 프록시는 Amazon Relational Database Service (RDS)를 위한 완전 관리형 고가용성 데이터베이스 프록시로, 애플리케이션의 확장 성, 데이터베이스 장애에 대한 탄력성 및 보안 성을 향상시킬 수 있습니다. (2020년 6월 서울 리전 출시)
성능 진단 및 컨설팅 제안서입니다.
모바일 성능 모니터링, 모바일 자동화 테스트, 웹 서버 성능 테스트를 합리적인 가격에 컨설팅 해 드립니다.
⁍ 업데이트된 최신본 성능 진단 및 컨설팅 제안서 확인해 보세요!
https://www.slideshare.net/IMQAGroup/imqa-performance-consulting
AgitarOne은 Java로 개발중인 Eclipse 프로젝트에 자동화된 단위 테스트의 환경을 제공하여 테스트 시간을 대폭 단축 시켜 개발 비용을 절감하게 하며, 작성된 소스 코드들이 실질적으로 수행되는지 명확히 파악할 수 있도록 하여 소스 코드의 품질을 향상시켜 줄 수 있는 Java 개발자의 단위 테스트 자동화 솔루션 입니다.
한대희 Web proxy_개발_2006년11월_pas_ktfDaehee Han
스마트폰이 대중화되기 직전까지 KT이동통신(KTF)의 모든 단말기가 인터넷 콘텐트 접속시에 거쳐가는 Web Proxy (PAS라 불림)를 바닥부터 새로 개발한 개발 기록. multi thread 기반으로 동작. 한 thread에서 여러 단말(client)처리. Multi-connection per thread. ACE framework사용. Reactor패턴 사용. 부하(동시접속 단말 개수)에 따라 reactor thread 개수를 동적으로 자동 조절하는 pool 방식 구현. 설계를 다시하고 밑바닥부터 새로 만듦. 200TPS 의 기존 성능을 1,000 TPS 로 올림. 5~6번의 deploy 작업 끝에 memory leak 문제 등 모든 문제 해결하고, 30일 넘게 운영해도 죽지 않는 서버로 구현함. 2006년.
[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?IMQA
웹 성능을 개선하기 위해 알아야 할 세 가지 지표 LCP(Largest Contentful Paint), FID(First Input Delay), CLS(Cumulative Layout Shift)에 대해 자세히 소개하고, Lighthouse로 개선하는 방법에 대해 살펴봅니다.
1. 웹 성능 개선은 무엇을 의미할까요?
2. 웹 성능 알아보기
3. Core Web Vitals
4. Lighthouse란?
5. Lighthouse로 개선하기
모바일 성능 모니터링, 웹 서버 성능 진단 및 부하테스트 컨설팅에 관심이 있으신 분은 아래 연락처로 연락해주시면, 전문 컨설턴트가 안내해드리겠습니다.
- 홈페이지: https://imqa.io
- 메일: support@imqa.io
- 전화: 02-6395-7730
- 채팅: https://imqa.channel.io/
2022년 11월 18일 코엑스에서 개최한 공공솔루션마켓에서 발표한 강연 자료입니다.
디지털 전환이 가속화됨에 따라 더욱 중요해진 디지털 경험 모니터링과 장애 및 병목 등 성능을 개선한 실 사례를 공유드립니다.
생생한 강연 영상으로 확인해 보세요!
https://youtu.be/_Cdms2TxO3M
2022년 11월 30일 코엑스에서 개최한 베스트콘2022(Better Software Testing Conference 2022)에서 발표한 강연 자료입니다.
대규모 장애를 막기 위해 소프트웨어/품질 엔지니어가 알아야 할 내결함성의 개념과 설계 기법을 공유드립니다.
생생한 강연 영상으로 확인해 보세요!
https://youtu.be/OLsv7oG0VPo
MDTF (Maryladn Test Facility)는 출입국이 빈번하게 일어나는 공항/항구 환경에 최적화된 생체 테스트로, DHS S&T MDTF 생체 인식 기술 대회에 대한 내용을 조사한 문서를 공유드립니다.
AI 테스팅 및 데이터 확보 방법에 관심이 있는 분은 mkbaek@onycom.com연락 부탁드립니다.
BeSTCon 2021에 발표한 AI 파이프라인과 실전 테스트 발표 자료입니다.
어니컴은 안면인식/이상행동 식별 사업, 불법복제 판독 식별, AI 스피커 성능 테스팅에 참여하면서, AI 테스팅에 풍부한 경험이 쌓여있는 기업입니다.
본 자료에서는 실제 AI 테스팅시 알아야할 기초적인 개념과 유의할 사항 그리고 성능 지표 / 평가 데이터 구축에 대한 전반에 대한 것들을 소개하고자 합니다.
-AI 파이프라인의 이해
-품질 검증을 위해 품질 업체가 참여해야 하는 영역
-AI 모델에서 사용하는 주요 성능 평가 지표 설명
-안면인식 /이상행동 사례
-평가 데이터 선정
-편향성, 공정성에 대한 고민들
-학습/평가 데이터 정제와 고민해야 하는 것들
-성능 리포트 작성시 고려해야 하는 사안들
NIST(미국 국립표준기술연구소)가 주관하는 안면인식 공급업체 테스트(Face Recognition Vendor Test, 이하 FRVT) 는 안면 정보를 이용하여 출입국 심사, 여권 불법 복제 탐지, 미성년자 이용 범죄 피해자 식별 등 민간, 사법, 보안 영역에서 활용하는 자동화된 얼굴 인식 기술의 성능을 측정하는 대회로 본 문서에서는 주요 4가지 평가 유형 및 특징에 대해 설명합니다.
안면인식 테스트 (이미지, 영상)과 이상행동 식별에 대한 테스트가 필요한 경우는mkbaek@onycom.com으로 연락 부탁드립니다.
1. 실전 서버 부하 테스트 노하우
손영수, 차용빈
ysson@onycom.com
어니컴 성능솔루션 사업부
2. 발표에 앞서
어니컴은
마사회, 대기업 입사 지원 시스템, 글로벌 제약회사, ERP등
다양한 업체의 부하 성능 테스트및 컨설팅을 한 경험을 가진 회사입니다.
이 자료는 부하 테스트 / 성능 측정 노하우를 공유하는 자료입니다.
(https://www.facebook.com/imqa.io 에서 자료 공개 예정)
모든 저작권은 어니컴에 있음을 알려 드리며,
원본 출처를 공개하는 조건에서 재 배포를 허락합니다.
4. 웹 어플리케이션은 어떻게 동작하나
User
Transaction
SQL SQL
Http
File
Resource
`
5. 부하 테스트 솔루션은 어떻게 동작하냐?
컨트
롤러
스크
립트
에이전트
에이전트
프로세스
프로세스
쓰레드 1
쓰레드 2
쓰레드 3
쓰레드 4
쓰레드 5
쓰레드 6
USER
USER
USER
USER
USER
USER
프로세스
프로세스
6. 부하 테스트 하기
자원을 사용트랜잭션 처리부하발생기
Transaction
SQL SQL
Http
File
Resource
`
컨트롤러
가상 유저
7. 부하 테스트시 실수 하는 것?
• 부하만 정말 열심히 준다.
• 자 서버 죽었어요?
• 개발자 : 원인이 무엇인가요…
• 병목 지점을 판단해서 코드 레벨로 말해주기를 원한다.
• 성능 테스터 : 전 개발자가 아닌데요…
• 고객 : 병목지점을 꼭 찍어서 알려 주셔야죠
• 결론 : 개발자만큼 알아야 한다 (Java, Node, Python등..)
8. 진짜 우리가 해야 할 것은?
Transaction
SQL SQL
Http
File
Resource
`
인프라 모니터링어플리케이션 모니터링
부하발생기
부하발생기 가상 유저
9. 부하 주기 뿐만 아니라 + @를 잘해야 한다.
• 부하는 어떻게 발생시키는 가? (Jmeter 잘 쓰기)
• 발생된 트랜잭션을 잘 처리하는가? 병목 찾기 (APM 사용하기)
• 서버의 자원은 충분한가? (서버 모니터링 - 성능 지표 읽기)
• 고급 주제
• 테스트를 현실적으로 잘 할려면 어떻게 해야 하는가? (테스트 계획안)
• 테스트에 필요한 요청사항들은? (어떠한 데이터를 수집해야 하나?)
• 클라우드 사용시 주의해야 할 것들은? (클라우드의 함정)
11. 성능 테스트 정의
• 정의 :
특정 부하에서 응답성 및 안정성 측면에서, 시스템이 어떻게 동작
하는지, 측정하기 위한 비 기능 테스트입니다.
• 얻을 수 있는 것들 :
확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성
을 조사, 측정, 검증 또는 검증 할 수 있습니다
12. 성능 테스트의 종류
부하 / 용량 산정 테스팅
Load/Capacity Testing
스트레스 테스팅
Stress Testing
내구성 테스트
Endurance/Soak Testing
최고점 부하 테스트
Spike Testing
16. 주요 논의 사항
• 현 테스트 시나리오 분석
• 테스트 시나리오 보완 방법
• 부하 테스트 진행방안
• 부하 테스트 전략 협의
• 클라우드 기반의 테스트 방안
16
17. 0. 부하테스트 목적
• 단위 서버(STG 서버) 기준, 최대 동시접속자 수 산정
• 실제 서버 기준, 사용자 시나리오(1) 기반으로 한 테스트
• 실제 서버 기준, 트랜잭션 단위 테스트의 스트레스 테스트(2)
• 실제 서버 기준, 부하 테스트(3)를 통한 임계값(Saturation Point) 산정
• 실제 서버 기준, 동시접속자 수, TPS, 응답시간 산정
17
(1)사용자 시나리오 : 실제 마사회 마이카드를 사용하는 사용자의 사용 흐름을 분석하여 테스트 시나리오를 작성함.
(2)스트레스(Stress) 테스트 : 시스템이 과부하 상태에서 어떻게 작동하는지를 검사하는 테스트.
(3)부하(Load) 테스트 : 서버 자원의 한계에 도달할 때까지 시스템에 부하를 꾸준히 증가시키며 진행하는 테스트.
18. • Wrk : 간단하게 서버 부하 테스트를 하고 싶을 때
• Vegeta : 초당 몇 개의 부하를 버티는지 테스트 하고 싶을 때
• Gatling : 높은 성능, 시나리오 작성, html 보고서 (코드 작성 필요)
• JMeter : 다양한 기능이나 플러그인이 강점 / 빠른 시나리오 작성 가능
• nGrinder : 시나리오, 시나리오 가중치 테스트 불가 , 개별 트랜잭션 TPS 측정에
중점 , Thread 기반으로 구현되어 있어 성능과 동시성에 대해 제한이 있음.
18
1. 부하 관련 툴 선정 (장단점.)
19. 2안. JMETER
ü기존 시스템 인터페이스 이용및 변경 적음
üTPS 기반의 단순 테스트에는 유리함
X시나리오 기반 테스트 및 가중치 테스트 불가
X빈약한 리포트
JMETER
ü다양한 결과 리포트 쉽게 얻을수 있음
üTPS / 시나리오 기반 /가중치 기반 테스트 가능
ü빠른 부하 스크립트 개발이 가능 (1~3일)
ü풍부한 플러그인 제공 (상용, 무료 많음)
X진입점 (잘 정리된 자료가 없다)
X빈약한 리포트
1. 부하 관련 툴 선정 (부하 발생기)
Agent
1안. nGrinder
Agent Agent …Agent
nGrinder
Controller
API API API
고객
서비스
고객
서비스
21. • 1안) 사용 상황에 맞는 시나리오 수립 후 테스트 (배포전)
• 가입 / 수강 / 결재 시나리오
• 딜 종료 후, 결과 확인 시나리오
• 딜 정보 확인 및 배당률 확인 시나리오
• 2안) 사용자로 부터 HTTP(S) 요청을 추출해서 시나리오 산정 (APM 사용)
• 내부 APM 연동 후 데이터 수집. (상용, 오픈소스, 유료 15일)
• 가능하다면 베타 그룹, 크라우드 테스트를 통해 데이터 수집 할 것을 추천
21
2. 테스트 시나리오 보완 방법 논의
22. • 고객별 시나리오 도출
• 예)
• 경우1_ 5분전에 구매를 완료하는 사용자 비율
• 선 구매 이후 > 반복되는 실시간 배당율 확인
• 경우2_ 30~10 초 전에 구매를 완료하는 사용자 비율
• 실시간 배당율 확인 및 실시간 배팅 정보구매
22
1안) 실제 사용 상황에 맞는 시나리오에 대한 테스트
25. 25
2안) APM의 결과를 추출해서 시나리오 산정
경기 시간 기준, 주요 트랜잭션 분포를 통한 시나리오 산정
26. • 주요 시나리오 테스트 (Warm-Up 테스트)
• 주요 시나리오 선정 후 (가입 , 강좌 수강등) 시나리오별로 얼마나 견디는지 테스트
•
• 트랜잭션별 단위 테스트 (Warm-Up 테스트)
• Top 20에 대한 트랜잭션에 대해서 얼마나 견디는지 테스트
• 주요 시나리오 가중치 테스트 (시나리오 별 가중치 테스트, Warm-Up 테스트)
• 위 선정된 주요 시나리오에 가중치를 부여 하여 테스트
• 예 ) A 시나리오 30%, B 시나리오 20%, C 시나리오 50%
26
3. 부하 테스트 진행 방향
29. 시나리오 테스트 예시
합격자 발표 시나리오, 1만명씩 늘려서 테스트
부하테스트 1만명 진행
합격자 발표 시나리오는 1만명 이전까지는 큰 문제가 발생하지 않았다.
다만, 1만명이 넘어가는 순간 다량의 쿼리를 사용하는 서비스인 getRecruitList 에서 문제가 발생하는 것을 확인 할 수 있었다.
평균적으로 3초에서 4초대의 응답시간을 보였으며, 3만명에서는 8초 정도의 응답시간을 보이기도 했다.
2만명 이상 테스트를 할 경우에는 중간중간 에러가 많이 발생 하였으며, 해당 에러는 Timeout wating for idle object로 확인이 되었다.
대부분 느린 쿼리로 인해 발생 한 문제로 추측이 된다.
부하테스트 2만명 진행 부하테스트 3만명 진행
A사 부하테스트 예시
29
30. Connection Pool 수치는 현재로서는 적당한 수치로 보인다.
다만, 테스트 당일 기준으로 첫 페이지에서 다량의 쿼리로 인해 서비스 전체가 느려진 것을 확인 할 수 있었다.
최대 3만명까지는 대부분은 문제가 없었으나, 일부 사용자들이 4초 이상 응답 속도를 보였다.
4초 이상 걸리는 대부분의 응답 서비스는 메인 페이지에서 오래 걸린 것으로 확인이 된다.
2만명 이상의 사용자가 방문 했을 경우 에러가 많이 잡혔으며, 이는 느린 쿼리의 문제로 추측이 된다.
/ 호출과 /getRecruitList의 성능 저하가 대부분이었으며, / 호출에서는 4초 이상 걸리는 단일 쿼리가 많이 잡혔다.
메인 페이지 호출 빈도를 줄이거나 메인페이지의 데이터를 Caching하는 방법으로 호출 빈도를 줄이는 것도 한 방법으로 보
인다.
또는 쿼리 튜닝이나 합격자 발표를 위한 별도의 페이지를 만드는 것도 한 방법으로 보인다.
합격자 발표 자체에서의 큰 문제는 발생하지 않았다. (대부분 3초 이내의 응답속도)
3. 테스트 결과
이때 문제가 되는 트랜잭션들을 선정해 트랜잭션 단위 테스트 진행
시나리오 테스트 분석 후 - 테스트 결과 공유
30
A사 부하테스트 예시
31. 부하테스트 2만명
TC 02 - 01 에 비해서 역시 좋은 성능을 보여주고 있다.
대부분 3초 이내로 응답하였으며, 1초 이내의 데이터에서 진한색으로 표시된 것으로 보아 대부분은 안정적으로
데이터 응답을 하는 것으로 보인다.
부하테스트 3만명 진행
개선 후 시나리오 테스트 Before / After 비교
A사 부하테스트 예시
31
부하테스트 3만명
32. 3. 테스트 결과
합격자 발표 시나리오를
비교했을 경우 80% 이상의 성능 향상을 보여주고 있다.
3차 테스트에서는 합격자 발표 부하테스트의 최대 수용 가능한 사용자 수를 측
정하고 산출하여도 큰 이상이 없는 성능을 보여주고 있다.
응답시간이 늦은 서비스가 보였으며 해당 부분은 Join문을 사용하고 있어 어쩔
수 없이 저하가 발생 할 수 밖에 없는 부분으로 보인다.
사용자 3만명부터 늦은 응답시간을 보인 비중은 1200히트 정도이며 이는 전
체에 1%에 해당되는 수치이다.
시나리오 부하테스트 후, 해석 결과 전달
A사 부하테스트 예시
32
33. 1) 현 서비스 최소 단위 구성하기
• 현 서비스의 최소 단위 WAS, DB등의 세트를 구성해서 테스트
• 섹션 3에서 언급한 시나리오별, 트랜잭션별, 시나리오 가중치 별 테스트
• 최소 단위 세트에서 부하 분석후 컨설팅 리포트 제공
• 주요 트랜잭션 테스트의 성능 고도화에 집중
33
4. 부하 테스트 단계별 전략
34. 2) 최소 셋트에서 문제점 도출및 안정화 진행
• PRETEST (사전 테스트) : 관련 스크립트및 환경 구성 체크 (방화벽, 네트워크 대역폭, 클러스터링)
• MAINTEST (계통 테스트) : 관련 에러 및 문제점 도출 (평균 1,2주)
• CONFORMATION TEST (확인 테스트/재 테스트) : 결함이 해결되었는지 검증하는 테스트
• REGRESSIO TEST (회귀테스트) : 변화에 대한 영향 검증
34
4. 부하 테스트 단계별 전략
35. 3) 실 서비스 대용량 부하 테스트
• 섹션 3에서 언급한 시나리오 별, 트랜잭션 별, 시나리오 가중치 별 테스트
• 클라우드 기반의 100대 인스턴스로 테스트 (100대면 가상 유저 4000명 정도는 가능)
• 주요 성능 리포트 제공
35
4. 부하 테스트 단계별 전략
36. 솔루션 개요 주요 기능
제니퍼 소프트
업계 1위의 APM
APM의 시초
강력한 지원
∙ 실시간 트래픽 수집의 최강자
다양한 파트너와 연동 (모바일 , DB 모니터링 연동)
실 사례및 문제 발생 시 도와줄 파트너가 많다
리포트및 분석 기능이 강력함, 타사 제품과 연동성 강력, 업계 1위의 안정성
Elastic APM
다양한 언어를 지원하
는 APM
• 다양한 언어를 지원 (java,node,python, ruby 등)
• 오픈소스 로 누구나 사용 가능함.
• 실시간 장애 인지보다는 장애 후 원인 분석 가능
Java 이외의 언어도 , 무상으로 쓸수 있는 APM (Java, .NET, Ruby, Python, Node. Go 등)
36
5. 관련 툴 선정 (APM)
37. 솔루션 개요 주요 기능
와탭
SaaS형 APM으로
큰 설치없이 서버 용
량 걱정없이 무료로
사용가능
(15일 제한)
∙ 막대한 트래픽의 모니터링을 클라우드 상에서 다 수집이 가능
(15일후 데이터 자동 파기)
∙ 트랜잭션에서 걸리는 스택까지 수집이 가능 (강점- 타 APM 없는 기능)
∙ 정확한 동시 접속자 수 산정 가능 (실 유저로 수집이 가능함)
리포트및 분석 기능이 강력함, 15일간 모든 기능을 사용 가능
Pinpoint
End 2 End 트랜잭션
분석이 가능함
( 네이버 개발 )
• 제니퍼와 유사한 기능을지고 있음
• End2End Transaction을 모니터링 하는데 초점이 있음
내부 솔루션 설치의 어려움 / 적절한 용량 논의후 구성
가능한 고객이 사용하는 APM으로 데이터 해석이 필요함.
유료 제품인 경우 APM은 라이센스 문제로 최소 셋트 테스트에만 적용
37
5. 관련 툴 선정 (APM)
38. 38
5. 왜 Jmeter를 사용해야 하나? 클라우드 연동
구글 클라우드를 활용한 부하 분산 테스트의 경우에는 JMeter 2.9를 이용합니다.
JMeter 4 버전 이후에는 SSL 관련 옵션 등 많은 변경부분 때문에, 2.9를 사용합니다.
참
고
X
권장 OS : OS X, Linux
39. 부하 분산 테스트 환경 구축
39
jmeter controller
jmeter server
42. 통신 포트 설정 변경
42
jmeter-server 설정
server_port=2099
server.rmi.localport=4000
jmeter controller 설정
remote_hosts=10.0.0.2:2099
client.rmi.localport=4001
44. 44
Jmeter + Google Cloud 관련 프로젝트 링크 - https://bit.ly/2AVq0pk
X
권장 OS : OS X, Linux
단 바로 작동하지 않음.
요즘 Google Cloud 관련 API를 변경 및 추가 후 사용할 수 있음.
중급 기준 : 1달 정도 추가 개발 필요.
58. 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
59. 어려운 방법보다 USE 메소드를 이용.
Saturation
Utilization
X
Errors
Utilization : 얼만큼 자원을 썼는지?
Saturation : 얼마나 많은 부하(extra works)가 들어왔는지.
Error : 발생한 에러는?
60. 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
62. 주의할 점 MemFree vs MemoryAvailable.
cat /proc/meminfo
MemFree보다
MemAvailable을 이용하세요.
Ubuntu 14.04이상 (커널 3.14)
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
71. 클라우드 환경에서 수집해야 되는 대표적인 지표 몇개.
§ IOPS
§ Disk Queue Length (win) / iowait (linux)
§ CPU Steal Time 등..
§ http://bencane.com/2012/08/06/troub
leshooting-high-io-wait-in-linux/
72. 클라우드 에서의 성능 측정이 어려운 이유..
첫째, 일부 부분은 우리가 통제할 수 없다.
우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만
어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다.
우리가 모든 환경을 통제할 수 없으니 정확하게 느려지거나
단절 되는 이유를 알아내기 매우 힘들다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
83. 83
A. 수직선 (Vertical Lining)
하나의 서버에서만 또는 여러 대의 서버에서 동일하게 이러한 상황이 발생
했는지 파악을 해야합니다.
하나의 서버에서만 이러한 현상을 보인다면, 메소드 락(Java Synchronized)
이나 그 애플리케이션 서버만의 문제지만, 여러 대의 애플리케이션 서버에
서 동일하게 이러한 수직 선이 생기면, 외부의 문제로 보셔야 합니다.
대부분 데이터베이스와 연관된 문제로 DB Lock, Connection Pool, 또는 공
유하고 있는 자원의 부족 문제를 의심해 보셔야 합니다.
또는 특정 외부 http call이 제한된 user만 받거나, 제한된 자원을 쓰고 있는
경우에 호출할 때마다 느려지는 경우 이러한 현상을 볼 수 있습니다.
84. 84
B. 수평선 (Horizontal Lining)
특정 시간 만큼 공백을 이루면서 가로로 선이 계속 발생하는 현상 이 그림은 20
시 2분경, 응답시간 12초 정도 쯤에서 에러들이 가로로 일직선을 이루는 모습을
보실 수 있습니다.
이런 현상이 서비스 운영 시 발생한다면 다음과 같은 상황을 의심
1) 자원을 획득하기 위해 반복적으로 재시도 할 때 동일 트랜잭션(URL)인 경우
자주 발생합니다. 특정 자원을 획득하지 못 해 주기적으로 재시도를 하는 로직을
넣은 경우입니다.
2) 30, 60, 90초 라인이 형성되는 경우 DB Timeout을 의심해 봐야 합니다.
30초의 타임 아웃이 풀려, 일제히 찍히는 경우가 발생합니다.
85. 85
C. 초기화에 의한 일시적인 병목현상
위의 그림은 특정시간에 시스템이 오픈 되고, 다수의 사용자가 대기 상태에 있다
가 동시에 접속을 시도하면서 발생하는 현상입니다. 약 5분 동안 병목 현상을 보
이다가, 서비스가 정상화 되었습니다.
이러한 현상은 수강신청이나 마사회와 같은 특정 시간에 티켓 발급 시 종종 발생
합니다. 사용자의 일순간 급격한 증가가 원인이라면 지속적으로 서비스가 느려
져야 하는데, 몇 분 후 다시 응답이 정상상태로 돌아온 것으로 보아, 초기화 과정
에서 발생한 일시적인 병목이라고 보는 것이 맞습니다.
일반적으로 Java-Web의 초기화 과정 중 주요한 부하 원인들은 다음과 같습니다.
- JSP 컴파일
- Class Loading
- 메뉴/권한 정보 초기화
- DB, 외부 연동 POOL 초기화
88. 8
8
메모리 자원 부족으로 인한 Thread (FilterChain) 대기 현상 발생
8000계좌를 초과해서 들어오게 되면,
Thread가 Stuck되는 현상이 발생하여, 전체 유저가 늦어지는 것보다는
적절한 Threadshold를 주어 기존 유저들이라도 쾌적하게 대응하는 것들이 필요함
89. 8
9
원인
메모리 자원의 부족으로 - Thread (FilterChain) 대기 현상 발생
Apache는 동시 접속이 늘어날수록 메모리를 많이 사용하게 되며, 응답시간도 느려지는 Thread Per Connection 구조를 가짐
마사회는 3G Heap Memory의 한계점에 도달하면 Thread가 Stuck 되는 현상이 발생함. (2~3G를 넘으면 FullGC 시 불리)
그리하여, Apache의 메모리를 늘리기 보다,
물리적 /VM 서버 메모리 스펙을 늘리고, Tomcat Instance를 늘리기를 추천 클러스터링/로드발랜서로 묶어서 제공하면 이 현상이 줄어들 수 있음.
참조 글 - https://bcho.tistory.com/788