Performance consulting

성능 진단 및 컨설팅 안
1

솔루션 문의는 전문 컨설턴트가
도와드립니다.
2
담당 : 이수민 대리 l lsm0516@onycom.com
조기홍 책임 l loveu2020@onycom.com

4.2.3.9 모바일 서비스 진단 개요
직접 개발한 자사 솔루션을 통해, Front End와 Back End로 구분하여
각 영역별로 최적화된 성능 진단 방법과 솔루션을 사용하여 진단 및 분석을 수행
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
부하 진단 (Back-end)앱 진단 (Front-end)
진단
목적
 앱의 잠재 리스크 파악
 앱 성능 개선을 위한 문제 파악
 모바일 서비스 성능 개선 방향 도출
모바일 애플리케이션 진단 (with IMQA) 단말~서버(네트워크) Performance Test (with J-Meter)
1. 환경 분석
2. 진단 준비
3. 성능 진단
4. 성능 분석
5. 결과 도출
개
선
방
향
진단
목적
 앱 ~ 서버 간, 성능 저하 요인 발견
 현재 서비스 아키텍처 한계 파악 (임계치)
 최대 부하, 최대 트랜잭션 처리 용량 검증
진단
방법
I II
1. 환경 분석
2. 테스트 시나리오 협의
3. 스크립트 개발
4. WARM UP TEST
5. 실 환경 테스트
개
선
방
향
진단
방법
3

4.2.3.10 앱 진단 (Front-end) - 개요
앱 진단은 1. 환경 분석, 2. 진단 준비, 3. 성능 진단, 4. 성능 분석, 5. 결과 도출의 총 5가지 내용으로 진행
앱 (Front-end) 진단 절차
환경 분석 진단 준비 성능 진단 분석 결과 도출
 앱 개발 환경
- Android
- iOS
 서비스 시나리오
 테스트 시나리오
 고객 요구사항
 앱 환경
- 진단 솔루션: IMQA
- 대상 : 해당 앱
 성능 데이터 수집 환경
- 수집 서버: IMQA SaaS
- 수집 주기: 10초
- VM 환경: 32Core CPU,
64GB Mem, 300GB SDD
 데이터 추출 방식/대상
- 실제 앱 배포
- 덤프 생성주기: 1분
 진단 횟수: 3회
 진단도구
- IMQA 성능 진단 툴 활용
 진단 대상 협의
1안 ) 내부 직원만 배포
2안) 30%만 일부 수집
3안) 100% 실 유저 수집
 분석 방법
- 항목별 성능 상세 분석
 분석 항목
- 화면 로딩시간
- 네트워크 응답시간
- 자원 사용량 (CPU,MEM)
- 배터리 사용량
- 디바이스 분포
- Native App Profiling
- Hybrid App Profiling
 ‘성능 분석 리포트’
- 성능 지표 내용
- 문제 원인 및 해결 방안
 Lessons & Learn
- 장애 및 성능 문제 요소
 To-Be 모델
- 개발 관점
- 운영 관점
- 서비스 관점
1. 진단 환경 구성 2. 진단 3.결과 정리
5

모바일 앱 진단의 핵심 활동인 성능 분석은 총 7가지의 방법으로 구분되어 단계 별로 진행
앱 (Front-end) 진단 상세 내용
4.2.3.10 앱 진단 (Front-end) – 상세 내용
네트워크 응답시간분석2.  서버와의 DATA 통신 시 정보 요청에 따른 응답시간
1. 하위 5% 이하에 해당되는 메소드 분석
2. 하루 중 응답시간이 가장 낮은 시간대
3. 응답시간 통계 *느린 구간 기준
자원 사용량분석3.
 사용자 별 모바일 기기의 자원 사용량
※ 자원 사용량: CPU *운영체제 및 메모리
1. CPU 사용량 전체 중 상위 95%, 하위 5% 분류
2. 메모리 사용량 전체 중 상위 95%, 하위 5% 분류
디바이스 분포분석5.  사용자 별 모바일 기기의 종류 구분 1. 앱 사용자 디바이스 분류
Native App Profiling분석6.  Native 화면 로딩시간 및 스택 Profiling 1. Native 화면 로딩 시 병목구간 분석
Hybrid App Profiling분석7.  Hybrid 사용 시 각 통신사 별 응답시간 1. Hybrid 화면 로딩 시 병목구간 분석
배터리 사용량분석4.  사용자 별 모바일 기기의 배터리 사용량 1. 배터리 사용량 비교 분석 vs. A & B (비교 대상)
화면 로딩시간분석1.  사용자 모바일 기기 별 화면 로딩시간
1. 화면 로딩이 늦는 구간 *5초 이상 소요 기준
2. 화면 로딩 시간 비교 분석 vs. A & B (비교 대상)
3. 병목 구간 유무 및 원인 분석
6

모바일 Front End 분석 1. 화면 로딩 시간 진단을 통해 사용 시 병목구간의 발생 여부를 확인하고 이에 대한
원인을 분석 (결과 리포트 예시)
4.2.3.10 앱 진단 (Front-end) – 분석1. 화면 로딩시간
분석 1. 화면 로딩 시간 – 3. 병목구간 측정 (1/2)
 병목구간 발생
 Main Activity에서 일부 병목구간 발생 → 메인 화면에서 CALL 하는 그리는 UI 객체가 많음이슈 및 문제점
개선 방향  3.0 메인 화면의 call 객체 간소화 및 상대 좌표를 통한 레이아웃 구성 변경
7

모바일 Front End 분석 1. 화면 로딩 시간 진단을 통해 사용 시 병목구간의 발생 여부를 확인하고 이에 대한
원인을 분석 (결과 리포트 예시)
4.2.3.10 앱 진단 (Front-end) – 분석1. 화면 로딩시간
분석 1. 화면 로딩 시간 – 3. 병목구간 측정 (2/2)
 LoginActivity가 4초 이상 소요됨에 따라 로그인 응답시간이 1.5초 이상 소요됨이슈 및 문제점
개선 방향  로그인 관련 API의 최적화 필요 (로그인 인증에 특화된 서버 캐시 도입 필요)
 병목구간 발생
8

하이브리드 앱의 웹 화면 로딩 속도 프로파일링 (서버 시간, 앱 내부 로딩 시간 별도로 판단 가능)
분석 3. 자원 사용량
 해당 없음
이슈 및 문제점
개선방향
 해당 없음
4.2.3.10 앱 진단 (Front-end) – 분석3. 자원 사용량
9

모바일 앱에서 호출되는 기능 중에 네트워크 응답시간이 많이 걸리는 하위 메소드를 파악
분석 2. 네트워크 응답시간 (Response Time)
1. 하위 5% 응답시간 해당되는 기능 분석
• 분석 내용 (Fact)
- SK/ KT/ LG 등 외부망 이용 시
통신 환경에 따른 Delay가 발생할 수 있음
4.2.3.10 앱 진단 (Front-end) – 분석2. 네트워크 응답시간
10

시간대별 네트워크 응답시간과 앱 성능을 분석
2. 하루 중 응답시간이 가장 낮은 시간대
- 네트워크 응답시간이 가장 늦은
시간대는 3:00 ~ 3:30pm (일간 추이)
11

모바일 Front End 성능 분석은 총 7가지 방법으로 구분되며, 분석 2.에서는 네트워크 응답시간에 대한
성능을 분석
느린 (SLOW) 구간의 Path가
특정하지 않고 산재되어 있음
개선방향
 서버 연결 통신망을 기준으로 느린
구간에 대한 원인 파악 필요
(서버 문제 vs. 통신사 문제)
3. 응답시간 통계 *느린 구간 기준
Wi-Fi 환경에서는 99.9 % 가 1초
이내에 응답하는 우수한 상황
12

모바일 앱의 단말기에서 CPU와 메모리 자원 사용량에 대한 성능을 분석
분석 3. 자원 사용량
 해당 없음
개선방향
 해당 없음
사용량 전체 중 상위 95%, 하위 5% 분류
4.2.3.10 앱 진단 (Front-end) – 분석3. 자원 사용량
자원 사용량 : CPU
자원 사용량 : 메모리
CPU 권고 사용량 50% 이하에서
평균 사용량 13%, 하위 5% →
22% 사용
메모리 권고 사용량 100MB
이하에서 평균 20MB, 하위 5% →
28MB 사용
우수
우수
13

사용자 모바일 기기의 배터리 사용량에 대한 성능을 분석
분석4. 배터리 사용량
 해당 없음
개선방향
 해당 없음
4.2.3.10 앱 진단 (Front-end) – 분석4. 배터리 사용량
-0.12%
-0.22% -0.22%
-0.25%
-0.20%
-0.15%
-0.10%
-0.05%
0.00%
Sample Telegram MP3 Player
배터리 사용량 비교 분석 vs. A & B
• 비교 대상 A. ‘채팅 프로그램'에서 주기적으로 메시지를 전송, 간헐적 동영상 보기로 테스트
• 비교 대상 B. ‘뮤직 플레이어’를 화면에 켜놓은 상태로 몇 시간 동안 테스트
예시 앱 A. 채팅 B. 뮤직
배터리 사용량이 비교 대상 A와 B
대비 낮은 편
우수
• 3000mAh 기준으로 평가
14

서비스 사용자의 주 이용 통신사를 분석
분석7. 통신사
 모수의 부족
SK Telecom의 응답시간이 타
통신사에 비해 느림
개선방향
 국내 인구 비율상 SK Telecom
사용자가 많으므로, 상대적으로 더
많은 기지국 확충이 필요해 보임
4.2.3.10 앱 진단 (Front-end) – 분석7. 통신사
국내 3대 통신사 별 통신 응답시간
SK Telecom의 속도가 다른
통신사에 비해 느림
15

4.2.3.11 부하 진단 (Back-end) - 개요
Back End 진단은 1. 환경 분석, 2. 진단 준비, 3. 전체 성능 분석, 4. 단위 성능 분석, 5. 결과 도출의 총 5가지
내용으로 진행
부하 (Back-end) 진단 절차
환경 분석 진단 준비 진단 환경 검증 전체 성능 분석 결과 도출
 서버 로그 분석
 부하 테스트 시나리오
 고객 요구사항
 부하테스트 대상 환경
- 대상 : 해당 앱
 부하테스트 환경
- Google Cloud 10대
- Jmeter 5.1
- Open JDK 1.8
 테스트 스크립트 작성
- Jmeter 를 이용하여 작성
(.jmx 파일)
 진단 방법
- 개발 환경에 테스트
시나리오 검증
 분석 방법
- Jmeter를 통한 전체
시나리오 테스트
 분석 항목
- 요청 값 및 응답 값 확인
- 정상 서버 처리 확인
- 비정상 API 확인
 진단 방법
- 개별 시나리오 부하 테스트
및 분석 리포트 제공
 분석 방법
- Jmeter를 통한 Warm-Up
방식 부하 테스트
 분석 항목
- 응답시간 및 TPS
- 에러율 및 임계값
- 비정상 API
 ‘성능 분석 리포트’
- 성능 분석 내용
- 문제 원인 및 해결 방안
 Lessons & Learn
- 장애 및 성능 문제 요소
 To-Be 모델
- 개발 관점
- 운영 관점
17

4.2.3.11 부하 진단 (Back-end) – 환경 구성부하 진단은 해당 앱에서 사용하는 API를 분석하여 진단 시나리오를 작성한 후 J-Meter를 이용하여 테스트
스크립트를 작성한 후 진단 환경을 구성
부하 (Back-end) 진단 방안
단위 테스트
시나리오 테스트
테스트 케이스 B
테스트 케이스 C
전체 API 테스트
비정상 API 테스트
테스트 케이스 A 해당 앱 서버
 APM
Jmeter 와 Google Cloud 부하 테스트 환경
Jmeter
Google Cloud
Instance
시나리오 별
테스트 스크립트 작성
18

부하테스트 주요 논의 사항
•현 테스트 시나리오 분석
•테스트 시나리오 보완 방법
•부하 테스트 진행 방안
•부하 테스트 전략 협의
•클라우드 기반의 테스트 방안
19

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

•1안) 실제 사용 상황에 맞는 시나리오에 대한 테스트
•주요 화면 (Account, Activity, Report, Support) 접속
•2안) 사용자로부터 HTTP(S) 요청을 추출해서 시나리오 산정 (IMQA)
•특정일에 사용자가 발생시키는 데이터 분석 후 전달 가능
2. 테스트 시나리오 보완 방법 논의
21

•고객사와 협의 후 시나리오 도출
•(예시) Account, Activity, Report, Support
•경우 1_ 위 4개 주요 화면에 들어가는 비율 협의
- Account, Activity, Report, Support 별 비율 도출
•경우 2_ 문제가 있는 화면만 주요 선정
- Activity가 특히 느리다면, 그 부분만 집중 산정
1안) 실제 사용 상황에 맞는 시나리오에 대한 테스트
22

2안) HTTP(S) 요청을 추출해서 시나리오 산정
특정 시간 기준, 주요 트랜잭션 분포를 통한 시나리오 산정
23

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

3-1. 최대 용량 산정 기준 협의
25

3-2. 주요 시나리오 선정
26

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

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

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

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

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

2) 최소 셋트에서 문제점 도출및 안정화 진행
• PRETEST (사전 테스트) : 관련 스크립트 및 환경 구성 체크 (방화벽, 네트워크 대역폭, 클러스터링)
• MAINTEST (계통 테스트) : 관련 에러 및 문제점 도출 (평균 1,2주)
• CONFORMATION TEST (확인 테스트/재 테스트) : 결함이 해결되었는지 검증하는 테스트
• REGRESSIO TEST (회귀테스트) : 변화에 대한 영향 검증
32

3) 실 서비스 대용량 부하 테스트
• 섹션 3에서 언급한 시나리오 별, 트랜잭션 별, 시나리오 가중치 별 테스트
• 클라우드 기반의 1000대 인스턴스로 테스트
• 주요 성능 리포트 제공
33

1안. JMeter 2안. Google Cloud
34
5. 관련 툴 선정 (부하 발생기)
…
 비용 : 1시간 테스트 8만 원 (1,000대 기준)
 TPS 기반의 테스트에만 유리함
X 부하 스크립터 새로 제작 비용 높음
X 구글 클라우드 에서만 사용 가능
X 시나리오 기반 테스트 / 시나리오 기반 가중치 테스트 불가
 사내/사외 동일한 형태로 부하 테스트 가능
 다양한 결과 리포트 쉽게 얻을 수 있음
 TPS 기반 테스트/ 시나리오 기반 테스트/가중치 테스트 가능
 빠른 부하 스크립트 재 개발이 가능 (1~3일)
 코드 없이 개발이 대부분 가능함 (코드 필요하면 삽입 가능)
 유지 보수가 용이함
X 부하 스크립트 재개발 필요
X 클라우드 배포 시스템 및 Docker 버전 관리 필요
X 비용 : 1시간 테스트 10만 원 내외 (1,000대기준)
웹 서비스
JMeter
Cloud
Instance
웹 서비스
GCP 제공 스트립트 개발
Cloud
Instance

참고 자료) 퍼포먼스 테스트 툴 사용 후기 https://tech.madup.com/2018/07/17/performance_test_tool.html
• Wrk : 몇 개 날리는 게 상관없이 간단하게 서버 부하 테스트를 하고 싶을 때
• Vegeta : 초당 몇 개의 부하를 버티는지 테스트하고 싶을 때
• Gatling : 높은 성능, 시나리오 작성, html 보고서
• JMeter : 다양한 기능이나 플러그인이 강점 / 빠른 시나리오 작성 가능
• nGrinder : 시나리오, 시나리오 가중치 테스트 불가, 개별 트랜잭션 TPS 측정에 중점, Thread 기반으로
구현되어 있어 성능과 동시성에 대해 제한이 있음. (grinder)
5. 관련 툴 선정 (부하 발생기)
35

5. 관련 툴 선정 (APM)
36
솔루션 개요 주요 기능
제니퍼 소프트
업계 1위 APM
APM의 시초
강력한 지원
• 실시간 트래픽 수집의 최강자 다양한 파트너와 연동
(모바일 , DB 모니터링 연동)
• 실 사례 및 문제 발생 시 연계 할 파트너 多
리포트 및 분석 기능이 강력함, 타사 제품과 연동성 강력, 업계 1위의 안정성
Elastic APM
다양한 언어를
지원하는 APM
• 다양한 언어를 지원 (java,node,python, ruby 등)
• 오픈소스로 누구나 사용 가능
• 실시간 장애 인지보다는 장애 후 원인 분석 가능
Java 이외의 언어도 , 무상으로 쓸수 있는 APM (Java, .NET, Ruby, Python, Node, Go 등)

5. 관련 툴 선정 (APM)
37
솔루션 개요 주요 기능
와탭
SaaS형 APM
쉬운 설치와 서버 용량
걱정 없는 무료 사용
(15일 제한)
• 막대한 트래픽의 모니터링을 클라우드 상에서 모두 수집 가능
(15일 후 데이터 자동 파기)
• 트랜잭션에서 걸리는 스택까지 수집 가능 (강점-타 APM 없는 독보적인 기능)
• 정확한 동시 접속자 수 산정 가능 (실 유저로 수집 가능)
SaaS형으로 설치 용이
Pinpoint
End 2 End 트랜잭션
분석 가능
(네이버 개발)
• 제니퍼와 유사한 기능 보유
• End2End Transaction을 모니터링하는데 중점적임
내부 설치 시 사용 / End 2 End 모니터링 시 필수

Reference
38
AIA 바이탈리티
SK브로드밴드 커리어케어한국마사회
닥스웨이브

컨설팅 비용
39
솔루션
모바일 서버 성능 모니터링 모바일 자동화 테스트 웹 서버 성능 테스트
가격 비상주 5,000,000
협의 후 픽스
테스트 케이스 양에 비례
상주 1일/ 1,000,000
비상주 1일/ 700,000
기간 1~2주 소요 1일 테스트 / 1달 단위 1~2주 소요

감사합니다.
자세한 솔루션 문의는 전문 컨설턴트가 도와드립니다.
본사 : 서울특별시 중구 세종대로21길 22 태성빌딩 l TEL : 02-541-0080
연구소 : 경기도 용인시 기흥구 흥덕중앙로 120, U-Tower
담당 : 이수민 대리 l lsm0516@onycom.com
조기홍 책임 l loveu2020@onycom.com

Performance consulting

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Performance consulting

Similar to Performance consulting (20)

More from IMQA

More from IMQA (7)

Performance consulting