[IMQA] performance consulting

웹 ∙ 앱 부하 테스트
성능 진단 및 컨설팅 안
본 문서는 어니컴(주)이 발행하는 문서이며 저작권법에 의해 보호를 받는 저작물입니다.
원문 출처를 표기하는 조건 하에 원문 그대로 공유 가능하며, 수정 및 영리 사용은 금지됩니다.
Copyright © 2021 by ONYCOM. Inc. All Rights Reserved.

Content
01
앱 성능 진단
02
웹 서버 성능 진단
03
부하 테스트

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 _ 성능 진단 및 컨설팅

5
앱 (Front-end) 진단 절차
앱 진단은 환경 분석 후, 이에 맞는 진단 준비 하에 성능 진단 및 분석을 진행합니다.
성능 진단 결과를 통해 각 항목별 문제점에 대한 해결 방안을 제시합니다.
환경
분석
진단
준비
성능
진단
분석
결과
도출
• 앱 개발 환경
- 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
앱 (Front-end) 진단 상세 내용
모바일 앱 진단의 핵심 활동인 성능 분석은 총 7가지의 방법으로 구분되어 단계별로 진행됩니다.
3. 자원 사용량
사용자 모바일 기기별 화면 로딩 시간
• 화면 로딩이 늦는 시간 (5초 이상 소요 기준)
• 화면 로딩 시간 비교 분석
• 병목 구간 유∙무 및 원인 분석
1. 화면 로딩 시간
2. 네트워크 응답시간
4. 배터리 사용량
• CPU 사용량 전체 중 상위 95%,
하위 5% 분류
• 메모리 사용량 전체 중 상위 95%,
하위 5% 분류
• 배터리 사용량 비교 분석
서버와의 Data 통신 시 요청에 따른 응답시간
• 하위 5% 이하에 해당되는 메소드 분석
• 하루 중 응답시간이 가장 낮은 시간대
• 응답시간 통계 (느린 구간 기준)
* 자원 사용량: CPU (운영체제 및 메모리)

7
앱 (Front-end) 진단 상세 내용
모바일 앱 진단의 핵심 활동인 성능 분석은 총 7가지의 방법으로 구분되어 단계별로 진행됩니다.
7. Hybrid App Profiling
사용자 별 모바일 기기의 종류 구분
• 앱 사용자 디바이스 분류
5. 디바이스 분포
6. Native App Profiling
Hybrid 사용 시 각 통신사 별 응답
시간
• Hybrid 화면 로딩 시 병목 구간
분석
Native 화면 로딩 시간 및 스택 Profiling
• Native 화면 로딩 시 병목 구간 분석

8
1. 화면 로딩 시간 _ 병목 구간 측정 Case #1
화면 로딩 시간 진단을 통해 사용 시 병목 구간의 발생 여부를 확인하고 이에 대한 원인을 분석합니다.
병목 구간 발생
✓ Main Activity에서 일부 병목 구간 발생 → 메인 화면에서 Call하여 그리는 UI 객체가 많음
➡ 3.0 메인 상대 좌표를 통한 레이아웃 구성 변경 필요
* 결과 리포트 예시

9
1. 화면 로딩 시간 _ 병목 구간 측정 Case #2
화면 로딩 시간 진단을 통해 사용 시 병목 구간의 발생 여부를 확인하고 이에 대한 원인을 분석합니다.
✓ LoginActivity가 4초 이상 소요됨에 따라 로그인 응답시간이 1.5초 이상 소요
➡ 로그인 관련 API의 최적화 필요 (로그인 인증에 특화된 서버 캐시 도입 필요)
ㅁ
병목구간 발생

10
2. 네트워크 응답 시간 _ Case #1
네트워크 응답 시간을 진단하고, 문제점을 파악하여 개선 방향을 제시합니다.
✓ 느린 (SLOW) 구간의 Path가 특정하지 않고 산재되어 있음
➡ 서버 연결 통신망을 기준으로 느린 구간에 대한 원인 파악 필요
(서버 문제 vs. 통신사 문제)
ㅁ
◀ 응답시간 통계 화면
Wi-Fi 환경에서는 99.9 %가
1초 이내에 응답하는 우수한
상황

11
✓ 하루 중 응답 시간이 가장 낮은 시간대 분석
➡ 네트워크 응답 시간이 가장 늦은 시간대는 15:00~15:30 (일간 추이)
ㅁ
시간대별 네트워크 응답시간과 앱 성능을 분석합니다.
ㅁ

12
모바일 앱에서 호출되는 기능 중에 네트워크 응답시간이 많이 걸리는 하위 메소드를 파악합니다.
✓ 하위 5% 응답 시간에 해당되는 기능 분석
➡ SKT, KT, LGT 등 외부망 이용 시, 통신 환경에 따른 Delay가 발생할 수 있음
ㅁ

13
3. 자원 사용량 _ Case #1
하이브리드 앱의 웹 화면 로딩 속도 프로파일링이 가능합니다. (서버 시간, 앱 내부 로딩 시간 별도 분석 가능)
ㅁ

14
3. 자원 사용량 _ Case #2
모바일 앱의 단말기에서 CPU와 메모리 자원 사용량에 대한 성능을 분석합니다.
(사용량 전체 중 상위 95%, 하위 5% 분류)
CPU 권고 사용량 50% 이하에서
평균 사용량 13%, 하위 5% → 22% 사용
자원 사용량: CPU 자원 사용량: 메모리
메모리 권고 사용량 100MB 이하에서
평균 20MB, 하위 5% → 28MB 사용

15
4. 배터리 사용량
사용자 모바일 기기의 배터리 사용량에 대한 성능을 분석합니다.
ㅁ
-0.25
-0.2
-0.15
-0.1
-0.05
0
예시 앱 A. 채팅 B. 뮤직
배터리 사용량 비교 분석 vs. A & B
배터리 사용량이 비교 대상 A와 B 대비 낮은 편
• 3000mAh 기준으로 평가
• 비교 대상 A: ‘채팅 프로그램'에서 주기적으로 메시지를 전송, 간헐적 동영상 보기로 테스트
• 비교 대상 B: ‘뮤직 플레이어’를 화면에 켜놓은 상태로 몇 시간 동안 테스트

16
5. 통신사 분석
서비스 사용자의 주 통신사를 분석합니다.
✓ SK Telecom의 응답시간이 타 통신사에 비해 느림
➡ 국내 인구 비율상 SK Telecom 사용자가 많으므로,
상대적으로 더 많은 기지국 확충이 필요해 보임
ㅁ
국내 3대 통신사 별 통신 응답 시간

18
웹 (Back-end) 진단 절차
앱 진단은 환경 분석 후, 이에 맞는 진단 준비 하에 전체 및 단위별 성능을 진단합니다.
성능 진단 결과 분석을 통해 각 항목별 문제점에 대한 해결 방안을 제시합니다.
환경
분석
진단
준비
환경
검증
성능
분석
결과
도출
• 서버 로그 분석
• 부하 테스트 시나리오
• 고객 요구사항
• 부하 테스트 대상 환경
- 대상: 해당 앱
• 부하 테스트 환경
- 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
웹 (Back-end) 진단 방안
스크립트 작성 후, 진단 환경을 구성합니다.
진단 결과 정리
진단 환경 구성
JMeter와 Google Cloud 부하 테스트 환경
JMeter
전체 API 테스트
비정상 API 테스트
테스트 케이스 A
테스트 케이스 B
테스트 케이스 C
단위 테스트
시나리오 테스트
Google Cloud
Instance
해당 앱 서버
APM

21
부하 테스트 주요 논의 사항
현 테스트 시나리오 분석
부하 테스트 목적을 설정하고, 현재의
테스트 시나리오를 분석, 점검합니다.
테스트 시나리오 보완 방법
분석 결과를 기반으로 실제 사용 상황 및
특정 상황에 따른 시나리오 설계
부하 테스트 진행 방안
시나리오 테스트, 트랙잭션 별 단위 테스트 등
필요 항목에 따라 진행 방향을 설정합니다.
부하 테스트 전략 협의
진행 단계별로 전략을 세우고, 이에 따른
상세 목표를 설정합니다.
클라우드 기반의 테스트 방안
테스트 진행 시 필요한 툴 중 상황과
시나리오에 적합한 툴을 선정합니다.

22
1. 부하 테스트 목적
단위 서버(테스트 서버), 실제 서버를 기준으로 부하 테스트 목적을 설정합니다.
사용자 시나리오 를 기반으로 한 테스트
트랜잭션 단위 테스트의 스트레스 테스트
부하 테스트 를 통한 임계값(Saturation Point) 산정
동시 접속자 수, TPS, 응답 시간 산정
최대 동시 접속자 수 산정
단위 서버
(테스트 서버)
실제 서버
(1)
(2)
(3)
(1) 사용자 시나리오: 실제 해당 앱의 사용자의 용 흐름을 분석하여 테스트 시나리오를 작성
(2) 스트레스 테스트(Stress Test): 시스템이 과부하 상태에서 어떻게 작동하는지를 검사하는 테스트
(3) 부하 테스트(Load Test): 서버 자원의 한계에 도달할 때까지 시스템에 부하를 꾸준히 증가시키며 진행하는 테스트

23
2. 테스트 시나리오 보완 방법 논의
분석 결과를 기반으로 테스트 시나리오 보완 방법을 논의하고 특정 상황에 대한 시나리오를 설계합니다.
실제 사용 상황에 맞는 시나리오에 대한 테스트
: 주요 화면 (Account, Activity, Report, Support) 접속
1안
사용자로부터 HTTP(S) 요청을 추출하여 시나리오 산정 (IMQA)
: 특정일에 사용자가 발생시키는 테스트 분석 후 전달 가능
2안

24
1안
실제 사용 상황에 맞는 시나리오에 대한 테스트
특정 시간 기준, 주요 트랙잭션 분포를 통한 시나리오를 산정합니다.
고객사와 협의 후 시나리오 도출
ex. Account, Activity, Report, Support 등
Case #1.
주요 화면에 들어가는 비율
Case #2.
문제가 있는 화면만 집중
선정한 주요 화면 별
비율 도출
주요 화면 중 Activity가
특히 느리다면, 해당 화면만
집중 진행

25
2안
사용자로부터 HTTP(S) 요청을 추출하여 시나리오 산정
특정 시간 기준, 주요 트랙잭션 분포를 통한 시나리오를 산정합니다.

26
주요 시나리오 산정 후,
시나리오 별로 얼마나
견디는지
테스트 진행
주요 시나리오 테스트
(Warm-up 테스트)
트랜잭션 별 단위 테스트
(Warm-up 테스트)
Top 20에 대한 트랜잭션에
대해서 얼마나 견디는지 테스트
진행
주요 시나리오 가중치 테스트
(시나리오별 가중치 테스트,
Warm-up 테스트)
선정된 주요 시나리오에
가중치를 부여하여 테스트 진행
ex) A 시나리오 30%,
B 시나리오 20%,
C 시나리오 50%
3. 부하 테스트 진행 방법
(1) 진행 방향 논의

27
(2) 최대 용량 산정 기준 협의
Response Time
부하량 (가상 사용자 수) 부하량 (가상 사용자 수)
TPS TPS
목표 응답시간
임계점

28
(3) 주요 시나리오 선정
단일 거래 테스트 복합 거래 테스트
단일 기능 시나리오 단일 기능 시나리오 A
단일 기능 시나리오 B
단일 기능 시나리오 C
10%
30%
60%
100%

29
(4) 시나리오 테스트 - 예시
부하 테스트 1만 명 진행
합격자 발표 시나리오는 1만 명 이전까지는 큰 문제가 발생하지 않았다.
다만, 1만 명이 넘어가는 순간 다량의 쿼리를 사용하는 서비스인 getRecruitList에서 문제가 발생하는 것을 확인할 수 있었다.
평균적으로 3초에서 4초대의 응답시간을 보였으며, 3만 명에서는 8초 정도의 응답시간을 보이기도 했다.
부하 테스트 2만 명 진행 부하 테스트 3만 명 진행
합격자 발표 시나리오, 1만 명씩 늘려서 테스트
2만 명 이상 테스트를 할 경우에는 중간중간 에러가 많이 발생하였으며, 해당 에러는 Timeout wating for idle object로 확인이 되었다.
대부분 느린 쿼리로 인해 발생한 문제로 추측된다.
* A사 부하 테스트 예시

30
시나리오 테스트 분석 결과
Connection Pool 수치는 현재로서는 적당한 수치로 보인다.
다만, 테스트 당일 기준으로 첫 페이지에서 다량의 쿼리로 인해 서비스 전체가 느려진 것을 확인할 수 있었다.
최대 3만 명까지는 대부분은 문제가 없었으나, 일부 사용자들이 4초 이상 응답 속도를 보였다.
4초 이상 걸리는 대부분의 응답 서비스는 메인 페이지에서 오래 걸린 것으로 확인이 된다.
2만 명 이상의 사용자가 방문했을 경우 에러가 많이 잡혔으며, 이는 느린 쿼리의 문제로 추측이 된다.
호출과 /getRecruitList의 성능 저하가 대부분이었으며, 호출에서는 4초 이상 걸리는 단일 쿼리가 많이 잡혔다.
메인 페이지 호출 빈도를 줄이거나 메인 페이지의 데이터를 Caching 하는 방법으로 호출 빈도를 줄이는 것도 방법으로 보인다.
또는 쿼리 튜닝이나 합격자 발표를 위한 별도의 페이지를 만드는 것도 한 방법으로 보인다.
합격자 발표 자체에서의 큰 문제는 발생하지 않았다. (대부분 3초 이내의 응답속도)
➡ 이 때 문제가 되는 트랜잭션을 선정하여
트랜잭션 단위 테스트 진행
(4) 시나리오 테스트 ‒ 결과 공유

31
(4) 시나리오 테스트 ‒ 개선 후 테스트 결과 공유
개선 후 시나리오 테스트 Before / After 비교
부하 테스트 2만 명 진행 부하 테스트 3만 명 진행
TC 02 - 01에 비해서 역시 좋은 성능을 보여주고 있다.
대부분 3초 이내로 응답하였으며, 1초 이내의 데이터에서 진한 색으로 표시된 것으로 보아
대체로 안정적으로 데이터 응답을 하는 것으로 보인다.

32
(4) 시나리오 테스트 ‒ 해석 결과 전달
테스트 결과
TC 02 - 01 과 비교했을 경우 80% 이상의 성능 향상을 보여주고 있다.
3차 테스트에서는 합격자 발표 부하 테스트의 최대 수용 가능한 사용자
수를 측정하고 산출하여도 큰 이상이 없는 성능을 보여주고 있다.
그래도 응답시간이 늦은 서비스가 보였으며 해당 부분은 Join 문을 사
용하고 있어 어쩔 수 없이 저하가 발생할 수밖에 없는 부분으로 보인다.
사용자 3만 명부터 늦은 응답시간을 보인 비중은 1200히트 정도이며
이는 전체에 1%에 해당되는 수치이다.

33
4. 부하 테스트 단계별 전략
(1) 현 서비스 최소 단위 구성 후 선 테스트
서비스
최소 단위
구성
최소 단위 세트에서 부하
분석 후 컨설팅 리포트 제공
주요 트랜잭션 테스트의
성능 고도화에 집중
현 서비스 최소 단위 WAS,
DB 등의 세트를 구성하여
테스트
시나리오별, 트랜잭션별,
시나리오 가중치 별 테스트

34
(2) 최소 세트에서 문제점 도출 및 안정화 진행
Pre Test Main Test
Conformation
Test
Regression
Test
Pre Test
(사전 테스트)
관련 스크립트 및 환경
구성 체크 (방화벽,
네트워크 대역폭,
클러스트러링)
Main Test
(계통 테스트)
관련 에러 및 문제점
도출 (평균 1~2주)
Conformation Test
(확인 테스트 / 재
테스트)
결함이 해결되었는지
검증하는 테스트
Regression Test
(회귀 테스트)
변화에 대한 영향 검증

35
(3) 실 서비스 대용량 부하 테스트
시나리오 별,
트랜잭션 별,
시나리오 가중치 별
테스트
클라우드 기반의
1,000대
인스턴스로
테스트
주요 성능
리포트 제공

36
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
(1) 부하 발생기
퍼포먼스 테스트 툴
Wrk Vegeta Gatling JMeter nGrinder
수량 상관 없이
간단하게 서버
부하 테스트를
하고 싶을 때
초당 몇 개의 부하를
버티는지
테스트하고 싶을 때
높은 성능,
시나리오 작성,
html 보고서
다양한 기능이나
플러그인이 강점
빠른 시나리오
작성 가능
시나리오,
시나리오 가중치
테스트 불가, 개별
트랜잭션 TPS
측정에 중점
Thread 기반으로
구현되어 있어
성능과 동시성에
대해 제한이 있음
* 참고 자료: 매드업 ‒ 서버 퍼포먼스 테스트 툴 사용 후기

38
(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
(2) APM Application performance management
솔루션 개요 주요 기능
와탭
SaaS형 APM으로
쉬운 설치와
서버 용량 걱정 없는 무료 사용
(15일 제한)
✓ 막대한 트래픽의 모니터링을 클라우드 상에서
모두 수집 가능
✓ 트랜잭션에서 걸리는 스택까지 수집 가능
✓ 정확한 동시 접속자 수 산정 가능 (실 유저로 수집 가능)
SaaS형으로 설치 용이
Pinpoint
End to End 트랜잭션 분석 가능
(네이버 개발)
✓ 제니퍼와 유사한 기능 보유
✓ End to End 트랜잭션을 모니터링하는데 중점적인
내부 설치 시 사용 / End to End 모니터링 시 필수

40
진행 사례
한국 마사회 SK브로드밴드 SKT 티맵
셀트리온 스킨큐어 AIA 바이탈리티 커리어케어
닥스웨이브 배달의명수 전주정보문화산업진흥원

감 사 합 니 다
자세한 솔루션 문의는 전문 컨설턴트가 도와드립니다.
정현호 부장 | hhjung@onycom.com 02-6395-7722

[IMQA] performance consulting

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to [IMQA] performance consulting

Similar to [IMQA] performance consulting (20)

More from IMQA

More from IMQA (10)

[IMQA] performance consulting