[IMQA] performance consulting
1 like3,641 views
급증하는 온라인 사용자 증가, 부하테스트가 필요하지 않으신가요? 요즘 인터넷 뉴스에는 홈페이지 접속자 폭증으로 인한 서버 다운, xx은행 모바일 앱 접속 에러, 인터넷 뱅킹 장애 등 온라인 시장과 모바일 시장이 급격하게 성장함에 따라 이에 따른 장애 소식이 끊이지 않고 전해지고 있습니다. 그렇다면, 우리는 이런 장애들을 어떻게 대비할 수 있을까요? 웹∙앱 부하테스트 (성능 진단) 및 컨설팅 안은 웹∙앱 부하테스트(성능 진단 테스트) 진행 과정과 이를 기반으로 어떻게 컨설팅을 진행하고 있는지 소개하고, 나아가 관련 장애들을 대비할 수 있는 방법에 대해 설명합니다. (공유드리는 파일은 slideshare에 업로드되었던 웹∙앱 부하테스트 성능 진단 및 컨설팅 안을 업데이트한 최신 본입니다.) 웹∙앱 부하테스트 (성능 진단) 및 컨설팅 자료는 아래와 같이 구성되어있습니다. • 웹∙앱 성능을 진단하고 문제에 대한 원인 분석 및 개선방향을 제시합니다. • 컨설팅 안에는 여러 실 성능 진단을 예시로 들고 이에 대한 원인 분석 및 개선방향을 도 출한 내용이 포함되어 있습니다. 1. 앱 성능 진단 • 앱 진단 절차 • 앱 진단 상세 내용 2. 웹 서버 성능 진단 • 웹 진단 절차 • 웹 진단 방향 3. 부하 테스트 • 현 테스트 시나리오 분석 • 테스트 시나리오 보완 방법 • 부하 테스트 진행 방안 • 부하 테스트 전략 • 클라우드 기반 테스트 방안 모바일 성능 모니터링, 웹 서버 성능 진단 및 부하테스트 컨설팅에 관심이 있으신 분은 아래 연락처로 연락해주시면, 전문 컨설턴트가 안내해드리겠습니다. hhjung@onycom.com l 02-6395-7722
[IMQA] performance consulting
- 1. 웹 ∙ 앱 부하 테스트 성능 진단 및 컨설팅 안 본 문서는 어니컴(주)이 발행하는 문서이며 저작권법에 의해 보호를 받는 저작물입니다. 원문 출처를 표기하는 조건 하에 원문 그대로 공유 가능하며, 수정 및 영리 사용은 금지됩니다. Copyright © 2021 by ONYCOM. Inc. All Rights Reserved.
- 2. Content 01 앱 성능 진단 02 웹 서버 성능 진단 03 부하 테스트
- 3. 3 모바일 서비스 진단 개요 직접 개발한 자사 솔루션을 통해, Front End와 Back End로 구분하여 각 영역별로 최적화된 성능 진단 방법과 솔루션을 사용하여 진단 및 분석을 수행 앱 진단 (Front-end) 웹 진단 (Back-end) 솔루션 모바일 애플리케이션 진단 (with IMQA) 단말~서버(네트워크) Performance Test (with J-Meter) 진단 목적 ✓ 앱의 잠재 리스크 파악 ✓ 앱 성능 개선을 위한 문제 파악 ✓ 모바일 서비스 성능 개선 방향 도출 ✓ 앱 ~ 서버 간, 성능 저하 요인 발견 ✓ 현재 서비스 아키텍처 한계 파악 (임계치) ✓ 최대 부하, 최대 트랜잭션 처리 용량 검증 진행 순서 1. 환경 분석 2. 진단 준비 3. 성능 진단 4. 성능 분석 5. 결과 도출 1. 환경 분석 2. 테스트 시나리오 협의 3. 스크립트 개발 4. Warm-up test 5. 실 환경 테스트 IMQA _ 성능 진단 및 컨설팅
- 4. 앱 성능 진단
- 5. 5 앱 (Front-end) 진단 절차 앱 진단은 환경 분석 후, 이에 맞는 진단 준비 하에 성능 진단 및 분석을 진행합니다. 성능 진단 결과를 통해 각 항목별 문제점에 대한 해결 방안을 제시합니다. IMQA _ 성능 진단 및 컨설팅 환경 분석 진단 준비 성능 진단 분석 결과 도출 • 앱 개발 환경 - Android - iOS • 서비스 시나리오 • 테스트 시나리오 • 고객 요구사항 • 앱 환경 - 진단 솔루션: IMQA - 대상: 해당 앱 • 성능 데이터 수집 환경 - 수집 서버: IMQA - 수집 주기: 10초 - VM 환경: 32Core CPU, 64GB Mem, 300GB SDD • 데이터 추출 방식/대상 - 실제 앱 배포 - 덤프 생성 주기: 1분 • 진단 횟수 - 3회 • 진단 도구 - IMQA 성능 진단 툴 활용 • 진단 대상 협의 - 1안: 내부 직원만 배포 - 2안: 30%만 수집 - 3안: 100% 실 유저 수집 • 분석 방법 - 항목별 성능 상세 분석 • 분석 항목 - 화면 로딩 시간 - 네트워크 응답 시간 - 자원 사용량 (CPU, MEM) - 배터리 사용량 - 디바이스 분포 - Native App Profiling - Hybrid App • 성능 분석 리포트 - 성능 지표 내용 - 문제 원인 및 해결 방안 • Lessons & Learn - 장애 및 성능 문제 요소 • To-Be 모델 - 개발 관점 - 운영 관점 - 서비스 관점 진단 환경 구성 진단 결과 정리
- 6. 6 앱 (Front-end) 진단 상세 내용 모바일 앱 진단의 핵심 활동인 성능 분석은 총 7가지의 방법으로 구분되어 단계별로 진행됩니다. IMQA _ 성능 진단 및 컨설팅 3. 자원 사용량 사용자 모바일 기기별 화면 로딩 시간 • 화면 로딩이 늦는 시간 (5초 이상 소요 기준) • 화면 로딩 시간 비교 분석 • 병목 구간 유∙무 및 원인 분석 1. 화면 로딩 시간 2. 네트워크 응답시간 4. 배터리 사용량 • CPU 사용량 전체 중 상위 95%, 하위 5% 분류 • 메모리 사용량 전체 중 상위 95%, 하위 5% 분류 • 배터리 사용량 비교 분석 서버와의 Data 통신 시 요청에 따른 응답시간 • 하위 5% 이하에 해당되는 메소드 분석 • 하루 중 응답시간이 가장 낮은 시간대 • 응답시간 통계 (느린 구간 기준) * 자원 사용량: CPU (운영체제 및 메모리)
- 7. 7 앱 (Front-end) 진단 상세 내용 모바일 앱 진단의 핵심 활동인 성능 분석은 총 7가지의 방법으로 구분되어 단계별로 진행됩니다. IMQA _ 성능 진단 및 컨설팅 7. Hybrid App Profiling 사용자 별 모바일 기기의 종류 구분 • 앱 사용자 디바이스 분류 5. 디바이스 분포 6. Native App Profiling Hybrid 사용 시 각 통신사 별 응답 시간 • Hybrid 화면 로딩 시 병목 구간 분석 Native 화면 로딩 시간 및 스택 Profiling • Native 화면 로딩 시 병목 구간 분석
- 8. 8 1. 화면 로딩 시간 _ 병목 구간 측정 Case #1 화면 로딩 시간 진단을 통해 사용 시 병목 구간의 발생 여부를 확인하고 이에 대한 원인을 분석합니다. IMQA _ 성능 진단 및 컨설팅 병목 구간 발생 ✓ Main Activity에서 일부 병목 구간 발생 → 메인 화면에서 Call하여 그리는 UI 객체가 많음 ➡ 3.0 메인 상대 좌표를 통한 레이아웃 구성 변경 필요 * 결과 리포트 예시
- 9. 9 1. 화면 로딩 시간 _ 병목 구간 측정 Case #2 화면 로딩 시간 진단을 통해 사용 시 병목 구간의 발생 여부를 확인하고 이에 대한 원인을 분석합니다. IMQA _ 성능 진단 및 컨설팅 ✓ LoginActivity가 4초 이상 소요됨에 따라 로그인 응답시간이 1.5초 이상 소요 ➡ 로그인 관련 API의 최적화 필요 (로그인 인증에 특화된 서버 캐시 도입 필요) ㅁ 병목구간 발생 * 결과 리포트 예시
- 10. 10 2. 네트워크 응답 시간 _ Case #1 네트워크 응답 시간을 진단하고, 문제점을 파악하여 개선 방향을 제시합니다. IMQA _ 성능 진단 및 컨설팅 ✓ 느린 (SLOW) 구간의 Path가 특정하지 않고 산재되어 있음 ➡ 서버 연결 통신망을 기준으로 느린 구간에 대한 원인 파악 필요 (서버 문제 vs. 통신사 문제) * 결과 리포트 예시 ㅁ ◀ 응답시간 통계 화면 Wi-Fi 환경에서는 99.9 %가 1초 이내에 응답하는 우수한 상황
- 11. 11 2. 네트워크 응답 시간 _ Case #2 IMQA _ 성능 진단 및 컨설팅 ✓ 하루 중 응답 시간이 가장 낮은 시간대 분석 ➡ 네트워크 응답 시간이 가장 늦은 시간대는 15:00~15:30 (일간 추이) * 결과 리포트 예시 ㅁ 시간대별 네트워크 응답시간과 앱 성능을 분석합니다. ㅁ
- 12. 12 2. 네트워크 응답 시간 _ Case #3 모바일 앱에서 호출되는 기능 중에 네트워크 응답시간이 많이 걸리는 하위 메소드를 파악합니다. IMQA _ 성능 진단 및 컨설팅 ✓ 하위 5% 응답 시간에 해당되는 기능 분석 ➡ SKT, KT, LGT 등 외부망 이용 시, 통신 환경에 따른 Delay가 발생할 수 있음 * 결과 리포트 예시 ㅁ
- 13. 13 3. 자원 사용량 _ Case #1 하이브리드 앱의 웹 화면 로딩 속도 프로파일링이 가능합니다. (서버 시간, 앱 내부 로딩 시간 별도 분석 가능) IMQA _ 성능 진단 및 컨설팅 * 결과 리포트 예시 ㅁ
- 14. 14 3. 자원 사용량 _ Case #2 모바일 앱의 단말기에서 CPU와 메모리 자원 사용량에 대한 성능을 분석합니다. (사용량 전체 중 상위 95%, 하위 5% 분류) IMQA _ 성능 진단 및 컨설팅 CPU 권고 사용량 50% 이하에서 평균 사용량 13%, 하위 5% → 22% 사용 * 결과 리포트 예시 자원 사용량: CPU 자원 사용량: 메모리 메모리 권고 사용량 100MB 이하에서 평균 20MB, 하위 5% → 28MB 사용
- 15. 15 4. 배터리 사용량 사용자 모바일 기기의 배터리 사용량에 대한 성능을 분석합니다. IMQA _ 성능 진단 및 컨설팅 * 결과 리포트 예시 ㅁ -0.25 -0.2 -0.15 -0.1 -0.05 0 예시 앱 A. 채팅 B. 뮤직 배터리 사용량 비교 분석 vs. A & B 배터리 사용량이 비교 대상 A와 B 대비 낮은 편 • 3000mAh 기준으로 평가 • 비교 대상 A: ‘채팅 프로그램'에서 주기적으로 메시지를 전송, 간헐적 동영상 보기로 테스트 • 비교 대상 B: ‘뮤직 플레이어’를 화면에 켜놓은 상태로 몇 시간 동안 테스트
- 16. 16 5. 통신사 분석 서비스 사용자의 주 통신사를 분석합니다. IMQA _ 성능 진단 및 컨설팅 ✓ SK Telecom의 응답시간이 타 통신사에 비해 느림 ➡ 국내 인구 비율상 SK Telecom 사용자가 많으므로, 상대적으로 더 많은 기지국 확충이 필요해 보임 * 결과 리포트 예시 ㅁ 국내 3대 통신사 별 통신 응답 시간
- 17. 웹 서버 성능 진단
- 18. 18 웹 (Back-end) 진단 절차 앱 진단은 환경 분석 후, 이에 맞는 진단 준비 하에 전체 및 단위별 성능을 진단합니다. 성능 진단 결과 분석을 통해 각 항목별 문제점에 대한 해결 방안을 제시합니다. IMQA _ 성능 진단 및 컨설팅 환경 분석 진단 준비 환경 검증 성능 분석 결과 도출 • 서버 로그 분석 • 부하 테스트 시나리오 • 고객 요구사항 • 부하 테스트 대상 환경 - 대상: 해당 앱 • 부하 테스트 환경 - Google Cloud 10대 - Jmeter 5.1 - Open JDK 1.8 • 데이터 스크립트 작성 - Jmeter를 이용하여 작성 (.jmx 파일) • 진단 횟수 - 3회 • 진단 방법 - 개발 환경에 테스트 시나리오 검증 • 분석 방법 - Jmeter를 통한 전체 시나리오 테스트 • 분석 항목 - 요청 및 응답 값 확인 - 정상 서버 처리 확인 - 비정상 API 확인 • 성능 분석 리포트 - 성능 분석 내용 - 문제 원인 및 해결 방안 • Lessons & Learn - 장애 및 성능 문제 요소 • To-Be 모델 - 개발 관점 - 운영 관점 진단 환경 구성 진단 결과 정리 • 진단 횟수 - 5회 • 진단 방법 - 개별 시나리오 부하 테스트 및 분석 리포트 제공 • 분석 방법 - Jmeter를 통한 Warm-up 방식 • 분석 항목 - 응답시간 및 TPS - 에러율 및 임계값 - 비정상 API
- 19. 19 웹 (Back-end) 진단 방안 스크립트 작성 후, 진단 환경을 구성합니다. IMQA _ 성능 진단 및 컨설팅 진단 결과 정리 진단 환경 구성 JMeter와 Google Cloud 부하 테스트 환경 JMeter 전체 API 테스트 비정상 API 테스트 테스트 케이스 A 테스트 케이스 B 테스트 케이스 C 단위 테스트 시나리오 테스트 Google Cloud Instance 해당 앱 서버 APM
- 20. 부하 테스트 진행
- 21. 21 부하 테스트 주요 논의 사항 IMQA _ 성능 진단 및 컨설팅 현 테스트 시나리오 분석 부하 테스트 목적을 설정하고, 현재의 테스트 시나리오를 분석, 점검합니다. 테스트 시나리오 보완 방법 분석 결과를 기반으로 실제 사용 상황 및 특정 상황에 따른 시나리오 설계 부하 테스트 진행 방안 시나리오 테스트, 트랙잭션 별 단위 테스트 등 필요 항목에 따라 진행 방향을 설정합니다. 부하 테스트 전략 협의 진행 단계별로 전략을 세우고, 이에 따른 상세 목표를 설정합니다. 클라우드 기반의 테스트 방안 테스트 진행 시 필요한 툴 중 상황과 시나리오에 적합한 툴을 선정합니다.
- 22. 22 1. 부하 테스트 목적 단위 서버(테스트 서버), 실제 서버를 기준으로 부하 테스트 목적을 설정합니다. IMQA _ 성능 진단 및 컨설팅 사용자 시나리오 를 기반으로 한 테스트 트랜잭션 단위 테스트의 스트레스 테스트 부하 테스트 를 통한 임계값(Saturation Point) 산정 동시 접속자 수, TPS, 응답 시간 산정 최대 동시 접속자 수 산정 단위 서버 (테스트 서버) 실제 서버 (1) (2) (3) (1) 사용자 시나리오: 실제 해당 앱의 사용자의 용 흐름을 분석하여 테스트 시나리오를 작성 (2) 스트레스 테스트(Stress Test): 시스템이 과부하 상태에서 어떻게 작동하는지를 검사하는 테스트 (3) 부하 테스트(Load Test): 서버 자원의 한계에 도달할 때까지 시스템에 부하를 꾸준히 증가시키며 진행하는 테스트
- 23. 23 2. 테스트 시나리오 보완 방법 논의 분석 결과를 기반으로 테스트 시나리오 보완 방법을 논의하고 특정 상황에 대한 시나리오를 설계합니다. IMQA _ 성능 진단 및 컨설팅 실제 사용 상황에 맞는 시나리오에 대한 테스트 : 주요 화면 (Account, Activity, Report, Support) 접속 1안 사용자로부터 HTTP(S) 요청을 추출하여 시나리오 산정 (IMQA) : 특정일에 사용자가 발생시키는 테스트 분석 후 전달 가능 2안
- 24. 24 2. 테스트 시나리오 보완 방법 논의 IMQA _ 성능 진단 및 컨설팅 1안 실제 사용 상황에 맞는 시나리오에 대한 테스트 특정 시간 기준, 주요 트랙잭션 분포를 통한 시나리오를 산정합니다. 고객사와 협의 후 시나리오 도출 ex. Account, Activity, Report, Support 등 Case #1. 주요 화면에 들어가는 비율 Case #2. 문제가 있는 화면만 집중 선정한 주요 화면 별 비율 도출 주요 화면 중 Activity가 특히 느리다면, 해당 화면만 집중 진행
- 25. 25 2. 테스트 시나리오 보완 방법 논의 IMQA _ 성능 진단 및 컨설팅 2안 사용자로부터 HTTP(S) 요청을 추출하여 시나리오 산정 특정 시간 기준, 주요 트랙잭션 분포를 통한 시나리오를 산정합니다.
- 26. 26 IMQA _ 성능 진단 및 컨설팅 주요 시나리오 산정 후, 시나리오 별로 얼마나 견디는지 테스트 진행 주요 시나리오 테스트 (Warm-up 테스트) 트랜잭션 별 단위 테스트 (Warm-up 테스트) Top 20에 대한 트랜잭션에 대해서 얼마나 견디는지 테스트 진행 주요 시나리오 가중치 테스트 (시나리오별 가중치 테스트, Warm-up 테스트) 선정된 주요 시나리오에 가중치를 부여하여 테스트 진행 ex) A 시나리오 30%, B 시나리오 20%, C 시나리오 50% 3. 부하 테스트 진행 방법 (1) 진행 방향 논의
- 27. 27 3. 부하 테스트 진행 방법 (2) 최대 용량 산정 기준 협의 IMQA _ 성능 진단 및 컨설팅 Response Time 부하량 (가상 사용자 수) 부하량 (가상 사용자 수) TPS TPS 목표 응답시간 임계점
- 28. 28 3. 부하 테스트 진행 방법 (3) 주요 시나리오 선정 IMQA _ 성능 진단 및 컨설팅 단일 거래 테스트 복합 거래 테스트 단일 기능 시나리오 단일 기능 시나리오 A 단일 기능 시나리오 B 단일 기능 시나리오 C 10% 30% 60% 100%
- 29. 29 3. 부하 테스트 진행 방법 (4) 시나리오 테스트 - 예시 IMQA _ 성능 진단 및 컨설팅 부하 테스트 1만 명 진행 합격자 발표 시나리오는 1만 명 이전까지는 큰 문제가 발생하지 않았다. 다만, 1만 명이 넘어가는 순간 다량의 쿼리를 사용하는 서비스인 getRecruitList에서 문제가 발생하는 것을 확인할 수 있었다. 평균적으로 3초에서 4초대의 응답시간을 보였으며, 3만 명에서는 8초 정도의 응답시간을 보이기도 했다. 부하 테스트 2만 명 진행 부하 테스트 3만 명 진행 합격자 발표 시나리오, 1만 명씩 늘려서 테스트 2만 명 이상 테스트를 할 경우에는 중간중간 에러가 많이 발생하였으며, 해당 에러는 Timeout wating for idle object로 확인이 되었다. 대부분 느린 쿼리로 인해 발생한 문제로 추측된다. * A사 부하 테스트 예시
- 30. 30 IMQA _ 성능 진단 및 컨설팅 * A사 부하 테스트 예시 시나리오 테스트 분석 결과 Connection Pool 수치는 현재로서는 적당한 수치로 보인다. 다만, 테스트 당일 기준으로 첫 페이지에서 다량의 쿼리로 인해 서비스 전체가 느려진 것을 확인할 수 있었다. 최대 3만 명까지는 대부분은 문제가 없었으나, 일부 사용자들이 4초 이상 응답 속도를 보였다. 4초 이상 걸리는 대부분의 응답 서비스는 메인 페이지에서 오래 걸린 것으로 확인이 된다. 2만 명 이상의 사용자가 방문했을 경우 에러가 많이 잡혔으며, 이는 느린 쿼리의 문제로 추측이 된다. 호출과 /getRecruitList의 성능 저하가 대부분이었으며, 호출에서는 4초 이상 걸리는 단일 쿼리가 많이 잡혔다. 메인 페이지 호출 빈도를 줄이거나 메인 페이지의 데이터를 Caching 하는 방법으로 호출 빈도를 줄이는 것도 방법으로 보인다. 또는 쿼리 튜닝이나 합격자 발표를 위한 별도의 페이지를 만드는 것도 한 방법으로 보인다. 합격자 발표 자체에서의 큰 문제는 발생하지 않았다. (대부분 3초 이내의 응답속도) ➡ 이 때 문제가 되는 트랜잭션을 선정하여 트랜잭션 단위 테스트 진행 3. 부하 테스트 진행 방법 (4) 시나리오 테스트 ‒ 결과 공유
- 31. 31 IMQA _ 성능 진단 및 컨설팅 3. 부하 테스트 진행 방법 (4) 시나리오 테스트 ‒ 개선 후 테스트 결과 공유 개선 후 시나리오 테스트 Before / After 비교 * A사 부하 테스트 예시 부하 테스트 2만 명 진행 부하 테스트 3만 명 진행 TC 02 - 01에 비해서 역시 좋은 성능을 보여주고 있다. 대부분 3초 이내로 응답하였으며, 1초 이내의 데이터에서 진한 색으로 표시된 것으로 보아 대체로 안정적으로 데이터 응답을 하는 것으로 보인다.
- 32. 32 IMQA _ 성능 진단 및 컨설팅 3. 부하 테스트 진행 방법 (4) 시나리오 테스트 ‒ 해석 결과 전달 테스트 결과 * A사 부하 테스트 예시 TC 02 - 01 과 비교했을 경우 80% 이상의 성능 향상을 보여주고 있다. 3차 테스트에서는 합격자 발표 부하 테스트의 최대 수용 가능한 사용자 수를 측정하고 산출하여도 큰 이상이 없는 성능을 보여주고 있다. 그래도 응답시간이 늦은 서비스가 보였으며 해당 부분은 Join 문을 사 용하고 있어 어쩔 수 없이 저하가 발생할 수밖에 없는 부분으로 보인다. 사용자 3만 명부터 늦은 응답시간을 보인 비중은 1200히트 정도이며 이는 전체에 1%에 해당되는 수치이다.
- 33. 33 IMQA _ 성능 진단 및 컨설팅 4. 부하 테스트 단계별 전략 (1) 현 서비스 최소 단위 구성 후 선 테스트 서비스 최소 단위 구성 최소 단위 세트에서 부하 분석 후 컨설팅 리포트 제공 주요 트랜잭션 테스트의 성능 고도화에 집중 현 서비스 최소 단위 WAS, DB 등의 세트를 구성하여 테스트 시나리오별, 트랜잭션별, 시나리오 가중치 별 테스트
- 34. 34 IMQA _ 성능 진단 및 컨설팅 4. 부하 테스트 단계별 전략 (2) 최소 세트에서 문제점 도출 및 안정화 진행 Pre Test Main Test Conformation Test Regression Test Pre Test (사전 테스트) 관련 스크립트 및 환경 구성 체크 (방화벽, 네트워크 대역폭, 클러스트러링) Main Test (계통 테스트) 관련 에러 및 문제점 도출 (평균 1~2주) Conformation Test (확인 테스트 / 재 테스트) 결함이 해결되었는지 검증하는 테스트 Regression Test (회귀 테스트) 변화에 대한 영향 검증
- 35. 35 IMQA _ 성능 진단 및 컨설팅 4. 부하 테스트 단계별 전략 (3) 실 서비스 대용량 부하 테스트 시나리오 별, 트랜잭션 별, 시나리오 가중치 별 테스트 클라우드 기반의 1,000대 인스턴스로 테스트 주요 성능 리포트 제공
- 36. 36 IMQA _ 성능 진단 및 컨설팅 5. 관련 툴 선정 (1) 부하 발생기 1안. JMeter 2안. Google Cloud JMeter Cloud Instance Cloud Instance Cloud Instance Cloud Instance 웹 서비스 • 사내/사외 동일한 형태로 부하 테스트 가능 • 다양한 결과 리포트 쉽게 얻을 수 있음 • TPS 기반 / 시나리오 기반 / 가중치 기반 테스트 가능 • 빠른 부하 스크립트 재 개발이 가능 (1~3일) • 코드 없이 대부분 개발 가능 (필요 시, 코드 삽입 가능) • 유지 보수가 용이함 ✕ 부하 스크립트 재개발 필요 ✕ 클라우드 배포 시스템 및 Docker 버전 관리 필요 ✕ 비용: 1시간 테스트 10만 원 내외 (1,000대기준) GCP 제공 스크립트 개발 Cloud Instance Cloud Instance Cloud Instance Cloud Instance 웹 서비스 • 비용: 1시간 테스트 8만 원 (1,000대 기준) • TPS 기반의 테스트에만 유리함 ✕ 높은 신규 부하 스크립트 제작 비용 ✕ 구글 클라우드에서만 사용 가능 ✕ 시나리오 기반 / 시나리오 기반 가중치 테스트 불가
- 37. 37 IMQA _ 성능 진단 및 컨설팅 5. 관련 툴 선정 (1) 부하 발생기 퍼포먼스 테스트 툴 Wrk Vegeta Gatling JMeter nGrinder 수량 상관 없이 간단하게 서버 부하 테스트를 하고 싶을 때 초당 몇 개의 부하를 버티는지 테스트하고 싶을 때 높은 성능, 시나리오 작성, html 보고서 다양한 기능이나 플러그인이 강점 빠른 시나리오 작성 가능 시나리오, 시나리오 가중치 테스트 불가, 개별 트랜잭션 TPS 측정에 중점 Thread 기반으로 구현되어 있어 성능과 동시성에 대해 제한이 있음 * 참고 자료: 매드업 ‒ 서버 퍼포먼스 테스트 툴 사용 후기
- 38. 38 IMQA _ 성능 진단 및 컨설팅 5. 관련 툴 선정 (2) APM Application performance management 솔루션 개요 주요 기능 제니퍼 소프트 업계 1위 APM으로 강력한 지원 (APM의 시초) ✓ 실시간 트래픽 수집의 최강자 ✓ 다양한 파트너와 연동 (모바일, DB 모니터링 연동) ✓ 실사례 및 문제 발생 시 연계 가능한 파트너가 많음 리포트 ∙ 분석 기능 ∙ 타사 제품과 연동성이 장점, 업계 1위의 안정성 Elastic APM 다양한 언어를 지원하는 APM ✓ 다양한 언어 지원 (java, node, python, ruby 등) ✓ 오픈소스로 누구나 사용 가능 ✓ 실시간 장애 인지보다는 장애 후 원인 분석 가능 Java 외의 언어도 무상으로 쓸 수 있는 APM (Java, .NET, Ruby, Python, Node, Go 등)
- 39. 39 IMQA _ 성능 진단 및 컨설팅 5. 관련 툴 선정 (2) APM Application performance management 솔루션 개요 주요 기능 와탭 SaaS형 APM으로 쉬운 설치와 서버 용량 걱정 없는 무료 사용 (15일 제한) ✓ 막대한 트래픽의 모니터링을 클라우드 상에서 모두 수집 가능 ✓ 트랜잭션에서 걸리는 스택까지 수집 가능 ✓ 정확한 동시 접속자 수 산정 가능 (실 유저로 수집 가능) SaaS형으로 설치 용이 Pinpoint End to End 트랜잭션 분석 가능 (네이버 개발) ✓ 제니퍼와 유사한 기능 보유 ✓ End to End 트랜잭션을 모니터링하는데 중점적인 내부 설치 시 사용 / End to End 모니터링 시 필수
- 40. 40 IMQA _ 성능 진단 및 컨설팅 진행 사례 한국 마사회 SK브로드밴드 SKT 티맵 셀트리온 스킨큐어 AIA 바이탈리티 커리어케어 닥스웨이브 배달의명수 전주정보문화산업진흥원
- 41. 감 사 합 니 다 자세한 솔루션 문의는 전문 컨설턴트가 도와드립니다. 정현호 부장 | hhjung@onycom.com 02-6395-7722