SlideShare a Scribd company logo
성능 진단 및 컨설팅 안
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
4.2.3.10 앱 진단 (Front-end) - 개요
앱 진단은 1. 환경 분석, 2. 진단 준비, 3. 성능 진단, 4. 성능 분석, 5. 결과 도출의 총 5가지 내용으로 진행
앱 (Front-end) 진단 절차
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
환경 분석 진단 준비 성능 진단 분석 결과 도출
 앱 개발 환경
- 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가지의 방법으로 구분되어 단계 별로 진행
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
앱 (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. 병목 구간 유무 및 원인 분석
1. 진단 환경 구성 2. 진단 3.결과 정리
6
모바일 Front End 분석 1. 화면 로딩 시간 진단을 통해 사용 시 병목구간의 발생 여부를 확인하고 이에 대한
원인을 분석 (결과 리포트 예시)
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
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 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
4.2.3.10 앱 진단 (Front-end) – 분석1. 화면 로딩시간
분석 1. 화면 로딩 시간 – 3. 병목구간 측정 (2/2)
 LoginActivity가 4초 이상 소요됨에 따라 로그인 응답시간이 1.5초 이상 소요됨이슈 및 문제점
개선 방향  로그인 관련 API의 최적화 필요 (로그인 인증에 특화된 서버 캐시 도입 필요)
 병목구간 발생
8
하이브리드 앱의 웹 화면 로딩 속도 프로파일링 (서버 시간, 앱 내부 로딩 시간 별도로 판단 가능)
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
분석 3. 자원 사용량
 해당 없음
이슈 및 문제점
개선방향
 해당 없음
4.2.3.10 앱 진단 (Front-end) – 분석3. 자원 사용량
9
모바일 앱에서 호출되는 기능 중에 네트워크 응답시간이 많이 걸리는 하위 메소드를 파악
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
분석 2. 네트워크 응답시간 (Response Time)
1. 하위 5% 응답시간 해당되는 기능 분석
• 분석 내용 (Fact)
- SK/ KT/ LG 등 외부망 이용 시
통신 환경에 따른 Delay가 발생할 수 있음
4.2.3.10 앱 진단 (Front-end) – 분석2. 네트워크 응답시간
10
시간대별 네트워크 응답시간과 앱 성능을 분석
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
분석 2. 네트워크 응답시간 (Response Time)
4.2.3.10 앱 진단 (Front-end) – 분석2. 네트워크 응답시간
2. 하루 중 응답시간이 가장 낮은 시간대
• 분석 내용 (Fact)
- 네트워크 응답시간이 가장 늦은
시간대는 3:00 ~ 3:30pm (일간 추이)
11
모바일 Front End 성능 분석은 총 7가지 방법으로 구분되며, 분석 2.에서는 네트워크 응답시간에 대한
성능을 분석
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
분석 2. 네트워크 응답시간 (Response Time)
느린 (SLOW) 구간의 Path가
특정하지 않고 산재되어 있음
이슈 및 문제점
개선방향
 서버 연결 통신망을 기준으로 느린
구간에 대한 원인 파악 필요
(서버 문제 vs. 통신사 문제)
3. 응답시간 통계 *느린 구간 기준
• 분석 내용 (Fact)
Wi-Fi 환경에서는 99.9 % 가 1초
이내에 응답하는 우수한 상황
4.2.3.10 앱 진단 (Front-end) – 분석2. 네트워크 응답시간
12
모바일 앱의 단말기에서 CPU와 메모리 자원 사용량에 대한 성능을 분석
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
분석 3. 자원 사용량
 해당 없음
이슈 및 문제점
개선방향
 해당 없음
사용량 전체 중 상위 95%, 하위 5% 분류
4.2.3.10 앱 진단 (Front-end) – 분석3. 자원 사용량
자원 사용량 : CPU
자원 사용량 : 메모리
• 분석 내용 (Fact)
CPU 권고 사용량 50% 이하에서
평균 사용량 13%, 하위 5% →
22% 사용
• 분석 내용 (Fact)
메모리 권고 사용량 100MB
이하에서 평균 20MB, 하위 5% →
28MB 사용
우수
우수
13
사용자 모바일 기기의 배터리 사용량에 대한 성능을 분석
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
분석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. 뮤직
• 분석 내용 (Fact)
배터리 사용량이 비교 대상 A와 B
대비 낮은 편
우수
• 3000mAh 기준으로 평가
14
서비스 사용자의 주 이용 통신사를 분석
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
분석7. 통신사
 모수의 부족
SK Telecom의 응답시간이 타
통신사에 비해 느림
이슈 및 문제점
개선방향
 국내 인구 비율상 SK Telecom
사용자가 많으므로, 상대적으로 더
많은 기지국 확충이 필요해 보임
4.2.3.10 앱 진단 (Front-end) – 분석7. 통신사
국내 3대 통신사 별 통신 응답시간
• 분석 내용 (Fact)
SK Telecom의 속도가 다른
통신사에 비해 느림
15
웹 서버 성능 진단
16
4.2.3.11 부하 진단 (Back-end) - 개요
Back End 진단은 1. 환경 분석, 2. 진단 준비, 3. 전체 성능 분석, 4. 단위 성능 분석, 5. 결과 도출의 총 5가지
내용으로 진행
부하 (Back-end) 진단 절차
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
환경 분석 진단 준비 진단 환경 검증 전체 성능 분석 결과 도출
 서버 로그 분석
 부하 테스트 시나리오
 고객 요구사항
 부하테스트 대상 환경
- 대상 : 해당 앱
 부하테스트 환경
- Google Cloud 10대
- Jmeter 5.1
- Open JDK 1.8
 테스트 스크립트 작성
- Jmeter 를 이용하여 작성
(.jmx 파일)
 진단 횟수: 3회
 진단 방법
- 개발 환경에 테스트
시나리오 검증
 분석 방법
- Jmeter를 통한 전체
시나리오 테스트
 분석 항목
- 요청 값 및 응답 값 확인
- 정상 서버 처리 확인
- 비정상 API 확인
 진단 횟수: 5회
 진단 방법
- 개별 시나리오 부하 테스트
및 분석 리포트 제공
 분석 방법
- Jmeter를 통한 Warm-Up
방식 부하 테스트
 분석 항목
- 응답시간 및 TPS
- 에러율 및 임계값
- 비정상 API
 ‘성능 분석 리포트’
- 성능 분석 내용
- 문제 원인 및 해결 방안
 Lessons & Learn
- 장애 및 성능 문제 요소
 To-Be 모델
- 개발 관점
- 운영 관점
1. 진단 환경 구성 2. 진단 3.결과 정리
17
4.2.3.11 부하 진단 (Back-end) – 환경 구성부하 진단은 해당 앱에서 사용하는 API를 분석하여 진단 시나리오를 작성한 후 J-Meter를 이용하여 테스트
스크립트를 작성한 후 진단 환경을 구성
부하 (Back-end) 진단 방안
4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석
4.2 발매 업무 및 정보시스템 현황분석
단위 테스트
시나리오 테스트
테스트 케이스 B
테스트 케이스 C
전체 API 테스트
비정상 API 테스트
테스트 케이스 A 해당 앱 서버
 APM
Jmeter 와 Google Cloud 부하 테스트 환경
1. 진단 환경 구성 2. 진단 3.결과 정리
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 비교
A사 부하테스트 예시
29
테스트 결과
TC 02 - 01 과 비교했을 경우 80% 이상의 성능 향상을 보여주고 있다.
3차 테스트에서는 합격자 발표 부하 테스트의 최대 수용 가능한 사용자
수를 측정하고 산출하여도 큰 이상이 없는 성능을 보여주고 있다.
그래도 응답시간이 늦은 서비스가 보였으며 해당 부분은 Join 문을 사용
하고 있어 어쩔 수 없이 저하가 발생할 수밖에 없는 부분으로 보인다.
사용자 3만 명부터 늦은 응답시간을 보인 비중은 1200히트 정도이며 이
는 전체에 1%에 해당되는 수치이다.
시나리오 부하테스트 후 해석 결과 전달
A사 부하테스트 예시
30
1) 현 서비스 최소 단위 구성 후 선 테스트
•현 서비스의 최소 단위 WAS, DB 등의 세트를 구성해서 테스트
•섹션 3에서 언급한 시나리오별, 트랜잭션 별, 시나리오 가중치 별 테스트
•최소 단위 세트에서 부하 분석 후 컨설팅 리포트 제공
•주요 트랜잭션 테스트의 성능 고도화에 집중
4. 부하 테스트 단계별 전략
31
2) 최소 셋트에서 문제점 도출및 안정화 진행
• PRETEST (사전 테스트) : 관련 스크립트 및 환경 구성 체크 (방화벽, 네트워크 대역폭, 클러스터링)
• MAINTEST (계통 테스트) : 관련 에러 및 문제점 도출 (평균 1,2주)
• CONFORMATION TEST (확인 테스트/재 테스트) : 결함이 해결되었는지 검증하는 테스트
• REGRESSIO TEST (회귀테스트) : 변화에 대한 영향 검증
4. 부하 테스트 단계별 전략
32
3) 실 서비스 대용량 부하 테스트
• 섹션 3에서 언급한 시나리오 별, 트랜잭션 별, 시나리오 가중치 별 테스트
• 클라우드 기반의 1000대 인스턴스로 테스트
• 주요 성능 리포트 제공
4. 부하 테스트 단계별 전략
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

More Related Content

What's hot

MySQL Deep dive with FusionIO
MySQL Deep dive with FusionIOMySQL Deep dive with FusionIO
MySQL Deep dive with FusionIO
I Goo Lee
 
Battle Of The Microservice Frameworks: Micronaut versus Quarkus edition!
Battle Of The Microservice Frameworks: Micronaut versus Quarkus edition! Battle Of The Microservice Frameworks: Micronaut versus Quarkus edition!
Battle Of The Microservice Frameworks: Micronaut versus Quarkus edition!
Michel Schudel
 
Advanced nGrinder
Advanced nGrinderAdvanced nGrinder
Advanced nGrinder
JunHo Yoon
 
Top 10 reasons to migrate to Gradle
Top 10 reasons to migrate to GradleTop 10 reasons to migrate to Gradle
Top 10 reasons to migrate to Gradle
Strannik_2013
 
ログ解析を支えるNoSQLの技術
ログ解析を支えるNoSQLの技術ログ解析を支えるNoSQLの技術
ログ解析を支えるNoSQLの技術Drecom Co., Ltd.
 
Massive service basic
Massive service basicMassive service basic
Massive service basic
DaeMyung Kang
 
MongoDBの監視
MongoDBの監視MongoDBの監視
MongoDBの監視
Tetsutaro Watanabe
 
第三回ありえる社内勉強会 「いわががのLombok」
第三回ありえる社内勉強会 「いわががのLombok」第三回ありえる社内勉強会 「いわががのLombok」
第三回ありえる社内勉強会 「いわががのLombok」yoshiaki iwanaga
 
Spring vs. spring boot
Spring vs. spring bootSpring vs. spring boot
Spring vs. spring boot
ChloeChoi23
 
Automated Test Framework with Cucumber
Automated Test Framework with CucumberAutomated Test Framework with Cucumber
Automated Test Framework with Cucumber
Ramesh Krishnan Ganesan
 
오픈 스펙을 대상으로 한 테스트설계사례
오픈 스펙을 대상으로 한 테스트설계사례오픈 스펙을 대상으로 한 테스트설계사례
오픈 스펙을 대상으로 한 테스트설계사례
SangIn Choung
 
서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해
중선 곽
 
UFT-1.pptx
UFT-1.pptxUFT-1.pptx
UFT-1.pptx
AmarDeo7
 
Node.js API 서버 성능 개선기
Node.js API 서버 성능 개선기Node.js API 서버 성능 개선기
Node.js API 서버 성능 개선기
JeongHun Byeon
 
애자일의 모든것
애자일의 모든것애자일의 모든것
애자일의 모든것
KH Park (박경훈)
 
IBM JVM 소개 - Oracle JVM 과 비교
IBM JVM 소개 - Oracle JVM 과 비교IBM JVM 소개 - Oracle JVM 과 비교
IBM JVM 소개 - Oracle JVM 과 비교
JungWoon Lee
 
Apache JMeter - A brief introduction
Apache JMeter - A brief introductionApache JMeter - A brief introduction
Apache JMeter - A brief introduction
silenceIT Inc.
 
負荷テスト入門
負荷テスト入門負荷テスト入門
負荷テスト入門
Takeo Noda
 
Load testing jmeter
Load testing jmeterLoad testing jmeter
Load testing jmeter
Billa Kota Sriram
 
개발이 테스트를 만났을 때(Shift left testing)
개발이 테스트를 만났을 때(Shift left testing)개발이 테스트를 만났을 때(Shift left testing)
개발이 테스트를 만났을 때(Shift left testing)
SangIn Choung
 

What's hot (20)

MySQL Deep dive with FusionIO
MySQL Deep dive with FusionIOMySQL Deep dive with FusionIO
MySQL Deep dive with FusionIO
 
Battle Of The Microservice Frameworks: Micronaut versus Quarkus edition!
Battle Of The Microservice Frameworks: Micronaut versus Quarkus edition! Battle Of The Microservice Frameworks: Micronaut versus Quarkus edition!
Battle Of The Microservice Frameworks: Micronaut versus Quarkus edition!
 
Advanced nGrinder
Advanced nGrinderAdvanced nGrinder
Advanced nGrinder
 
Top 10 reasons to migrate to Gradle
Top 10 reasons to migrate to GradleTop 10 reasons to migrate to Gradle
Top 10 reasons to migrate to Gradle
 
ログ解析を支えるNoSQLの技術
ログ解析を支えるNoSQLの技術ログ解析を支えるNoSQLの技術
ログ解析を支えるNoSQLの技術
 
Massive service basic
Massive service basicMassive service basic
Massive service basic
 
MongoDBの監視
MongoDBの監視MongoDBの監視
MongoDBの監視
 
第三回ありえる社内勉強会 「いわががのLombok」
第三回ありえる社内勉強会 「いわががのLombok」第三回ありえる社内勉強会 「いわががのLombok」
第三回ありえる社内勉強会 「いわががのLombok」
 
Spring vs. spring boot
Spring vs. spring bootSpring vs. spring boot
Spring vs. spring boot
 
Automated Test Framework with Cucumber
Automated Test Framework with CucumberAutomated Test Framework with Cucumber
Automated Test Framework with Cucumber
 
오픈 스펙을 대상으로 한 테스트설계사례
오픈 스펙을 대상으로 한 테스트설계사례오픈 스펙을 대상으로 한 테스트설계사례
오픈 스펙을 대상으로 한 테스트설계사례
 
서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해서버 성능에 대한 정의와 이해
서버 성능에 대한 정의와 이해
 
UFT-1.pptx
UFT-1.pptxUFT-1.pptx
UFT-1.pptx
 
Node.js API 서버 성능 개선기
Node.js API 서버 성능 개선기Node.js API 서버 성능 개선기
Node.js API 서버 성능 개선기
 
애자일의 모든것
애자일의 모든것애자일의 모든것
애자일의 모든것
 
IBM JVM 소개 - Oracle JVM 과 비교
IBM JVM 소개 - Oracle JVM 과 비교IBM JVM 소개 - Oracle JVM 과 비교
IBM JVM 소개 - Oracle JVM 과 비교
 
Apache JMeter - A brief introduction
Apache JMeter - A brief introductionApache JMeter - A brief introduction
Apache JMeter - A brief introduction
 
負荷テスト入門
負荷テスト入門負荷テスト入門
負荷テスト入門
 
Load testing jmeter
Load testing jmeterLoad testing jmeter
Load testing jmeter
 
개발이 테스트를 만났을 때(Shift left testing)
개발이 테스트를 만났을 때(Shift left testing)개발이 테스트를 만났을 때(Shift left testing)
개발이 테스트를 만났을 때(Shift left testing)
 

Similar to Performance consulting

[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To
Ji-Woong Choi
 
장애 분석 절차 (서영일)
장애 분석 절차 (서영일)장애 분석 절차 (서영일)
장애 분석 절차 (서영일)
WhaTap Labs
 
[오픈소스컨설팅]Java Performance Tuning
[오픈소스컨설팅]Java Performance Tuning[오픈소스컨설팅]Java Performance Tuning
[오픈소스컨설팅]Java Performance Tuning
Ji-Woong Choi
 
모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415
SeungBeom Ha
 
H/W 규모산정기준
H/W 규모산정기준H/W 규모산정기준
H/W 규모산정기준
sam Cyberspace
 
UI 정적분석툴 소개와 활용사례
UI 정적분석툴 소개와 활용사례UI 정적분석툴 소개와 활용사례
UI 정적분석툴 소개와 활용사례
SangIn Choung
 
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
SeungBeom Ha
 
메인프레임모니터링자동화 애플트리랩
메인프레임모니터링자동화 애플트리랩메인프레임모니터링자동화 애플트리랩
메인프레임모니터링자동화 애플트리랩JaeWoo Wie
 
[OpenInfra Days Korea 2018] (Track 4) - Grafana를 이용한 OpenStack 클라우드 성능 모니터링
[OpenInfra Days Korea 2018] (Track 4) - Grafana를 이용한 OpenStack 클라우드 성능 모니터링[OpenInfra Days Korea 2018] (Track 4) - Grafana를 이용한 OpenStack 클라우드 성능 모니터링
[OpenInfra Days Korea 2018] (Track 4) - Grafana를 이용한 OpenStack 클라우드 성능 모니터링
OpenStack Korea Community
 
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
IMQA
 
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
SangIn Choung
 
JMP를 활용한 전자/반도체 산업 Yield Enhancement Methodology
JMP를 활용한 전자/반도체 산업 Yield Enhancement MethodologyJMP를 활용한 전자/반도체 산업 Yield Enhancement Methodology
JMP를 활용한 전자/반도체 산업 Yield Enhancement Methodology
JMP Korea
 
600.Troubleshooting Patterns
600.Troubleshooting Patterns600.Troubleshooting Patterns
600.Troubleshooting Patterns
Opennaru, inc.
 
Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안
중선 곽
 
Opensource APM SCOUTER in practice
Opensource APM SCOUTER in practiceOpensource APM SCOUTER in practice
Opensource APM SCOUTER in practice
GunHee Lee
 
우리 제품의 검증 프로세스 소개 자료
우리 제품의 검증 프로세스 소개 자료 우리 제품의 검증 프로세스 소개 자료
우리 제품의 검증 프로세스 소개 자료
SangIn Choung
 
Oracle Application Performance Monitoring Cloud Service 소개
Oracle Application Performance Monitoring Cloud Service 소개Oracle Application Performance Monitoring Cloud Service 소개
Oracle Application Performance Monitoring Cloud Service 소개
Mee Nam Lee
 
Keynotes 모바일어플리케이션응답시간관리
Keynotes 모바일어플리케이션응답시간관리Keynotes 모바일어플리케이션응답시간관리
Keynotes 모바일어플리케이션응답시간관리
JaeWoo Wie
 
Five Star Mobile App을 위한 테스트 체계 만들기
Five Star Mobile App을 위한 테스트 체계 만들기Five Star Mobile App을 위한 테스트 체계 만들기
Five Star Mobile App을 위한 테스트 체계 만들기
Ki Bae Kim
 
디지털트윈 시공간 현상 정보 가시화 사례와 과제 - 한국지도학회 2024년 춘계학술대회 발표 자료
디지털트윈 시공간 현상 정보 가시화 사례와 과제 - 한국지도학회 2024년 춘계학술대회 발표 자료디지털트윈 시공간 현상 정보 가시화 사례와 과제 - 한국지도학회 2024년 춘계학술대회 발표 자료
디지털트윈 시공간 현상 정보 가시화 사례와 과제 - 한국지도학회 2024년 춘계학술대회 발표 자료
SANGHEE SHIN
 

Similar to Performance consulting (20)

[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To
 
장애 분석 절차 (서영일)
장애 분석 절차 (서영일)장애 분석 절차 (서영일)
장애 분석 절차 (서영일)
 
[오픈소스컨설팅]Java Performance Tuning
[오픈소스컨설팅]Java Performance Tuning[오픈소스컨설팅]Java Performance Tuning
[오픈소스컨설팅]Java Performance Tuning
 
모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415
 
H/W 규모산정기준
H/W 규모산정기준H/W 규모산정기준
H/W 규모산정기준
 
UI 정적분석툴 소개와 활용사례
UI 정적분석툴 소개와 활용사례UI 정적분석툴 소개와 활용사례
UI 정적분석툴 소개와 활용사례
 
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
 
메인프레임모니터링자동화 애플트리랩
메인프레임모니터링자동화 애플트리랩메인프레임모니터링자동화 애플트리랩
메인프레임모니터링자동화 애플트리랩
 
[OpenInfra Days Korea 2018] (Track 4) - Grafana를 이용한 OpenStack 클라우드 성능 모니터링
[OpenInfra Days Korea 2018] (Track 4) - Grafana를 이용한 OpenStack 클라우드 성능 모니터링[OpenInfra Days Korea 2018] (Track 4) - Grafana를 이용한 OpenStack 클라우드 성능 모니터링
[OpenInfra Days Korea 2018] (Track 4) - Grafana를 이용한 OpenStack 클라우드 성능 모니터링
 
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
 
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
 
JMP를 활용한 전자/반도체 산업 Yield Enhancement Methodology
JMP를 활용한 전자/반도체 산업 Yield Enhancement MethodologyJMP를 활용한 전자/반도체 산업 Yield Enhancement Methodology
JMP를 활용한 전자/반도체 산업 Yield Enhancement Methodology
 
600.Troubleshooting Patterns
600.Troubleshooting Patterns600.Troubleshooting Patterns
600.Troubleshooting Patterns
 
Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안
 
Opensource APM SCOUTER in practice
Opensource APM SCOUTER in practiceOpensource APM SCOUTER in practice
Opensource APM SCOUTER in practice
 
우리 제품의 검증 프로세스 소개 자료
우리 제품의 검증 프로세스 소개 자료 우리 제품의 검증 프로세스 소개 자료
우리 제품의 검증 프로세스 소개 자료
 
Oracle Application Performance Monitoring Cloud Service 소개
Oracle Application Performance Monitoring Cloud Service 소개Oracle Application Performance Monitoring Cloud Service 소개
Oracle Application Performance Monitoring Cloud Service 소개
 
Keynotes 모바일어플리케이션응답시간관리
Keynotes 모바일어플리케이션응답시간관리Keynotes 모바일어플리케이션응답시간관리
Keynotes 모바일어플리케이션응답시간관리
 
Five Star Mobile App을 위한 테스트 체계 만들기
Five Star Mobile App을 위한 테스트 체계 만들기Five Star Mobile App을 위한 테스트 체계 만들기
Five Star Mobile App을 위한 테스트 체계 만들기
 
디지털트윈 시공간 현상 정보 가시화 사례와 과제 - 한국지도학회 2024년 춘계학술대회 발표 자료
디지털트윈 시공간 현상 정보 가시화 사례와 과제 - 한국지도학회 2024년 춘계학술대회 발표 자료디지털트윈 시공간 현상 정보 가시화 사례와 과제 - 한국지도학회 2024년 춘계학술대회 발표 자료
디지털트윈 시공간 현상 정보 가시화 사례와 과제 - 한국지도학회 2024년 춘계학술대회 발표 자료
 

More from IMQA

[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
IMQA
 
실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기
IMQA
 
Fault Tolerance 소프트웨어 패턴
Fault Tolerance 소프트웨어 패턴Fault Tolerance 소프트웨어 패턴
Fault Tolerance 소프트웨어 패턴
IMQA
 
DHS S&T MDTF Biometric Technology Rally
DHS S&T MDTF Biometric Technology RallyDHS S&T MDTF Biometric Technology Rally
DHS S&T MDTF Biometric Technology Rally
IMQA
 
AI 파이프라인과 실전 테스팅 전략
AI 파이프라인과 실전 테스팅 전략AI 파이프라인과 실전 테스팅 전략
AI 파이프라인과 실전 테스팅 전략
IMQA
 
NIST Face Recognition Vendor Test, FRVT
NIST Face Recognition Vendor Test, FRVTNIST Face Recognition Vendor Test, FRVT
NIST Face Recognition Vendor Test, FRVT
IMQA
 
인공지능 식별추적시스템 성능 검증 평가 사례
인공지능 식별추적시스템 성능 검증 평가 사례 인공지능 식별추적시스템 성능 검증 평가 사례
인공지능 식별추적시스템 성능 검증 평가 사례
IMQA
 
Introduction of IMQA MPM Solution
Introduction of IMQA MPM SolutionIntroduction of IMQA MPM Solution
Introduction of IMQA MPM Solution
IMQA
 
확장가능한 웹 아키텍쳐 구축 방안
확장가능한 웹 아키텍쳐 구축 방안 확장가능한 웹 아키텍쳐 구축 방안
확장가능한 웹 아키텍쳐 구축 방안
IMQA
 

More from IMQA (9)

[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
 
실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기
 
Fault Tolerance 소프트웨어 패턴
Fault Tolerance 소프트웨어 패턴Fault Tolerance 소프트웨어 패턴
Fault Tolerance 소프트웨어 패턴
 
DHS S&T MDTF Biometric Technology Rally
DHS S&T MDTF Biometric Technology RallyDHS S&T MDTF Biometric Technology Rally
DHS S&T MDTF Biometric Technology Rally
 
AI 파이프라인과 실전 테스팅 전략
AI 파이프라인과 실전 테스팅 전략AI 파이프라인과 실전 테스팅 전략
AI 파이프라인과 실전 테스팅 전략
 
NIST Face Recognition Vendor Test, FRVT
NIST Face Recognition Vendor Test, FRVTNIST Face Recognition Vendor Test, FRVT
NIST Face Recognition Vendor Test, FRVT
 
인공지능 식별추적시스템 성능 검증 평가 사례
인공지능 식별추적시스템 성능 검증 평가 사례 인공지능 식별추적시스템 성능 검증 평가 사례
인공지능 식별추적시스템 성능 검증 평가 사례
 
Introduction of IMQA MPM Solution
Introduction of IMQA MPM SolutionIntroduction of IMQA MPM Solution
Introduction of IMQA MPM Solution
 
확장가능한 웹 아키텍쳐 구축 방안
확장가능한 웹 아키텍쳐 구축 방안 확장가능한 웹 아키텍쳐 구축 방안
확장가능한 웹 아키텍쳐 구축 방안
 

Performance consulting

  • 1. 성능 진단 및 컨설팅 안 1
  • 2. 솔루션 문의는 전문 컨설턴트가 도와드립니다. 2 담당 : 이수민 대리 l lsm0516@onycom.com 조기홍 책임 l loveu2020@onycom.com
  • 3. 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
  • 5. 4.2.3.10 앱 진단 (Front-end) - 개요 앱 진단은 1. 환경 분석, 2. 진단 준비, 3. 성능 진단, 4. 성능 분석, 5. 결과 도출의 총 5가지 내용으로 진행 앱 (Front-end) 진단 절차 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 환경 분석 진단 준비 성능 진단 분석 결과 도출  앱 개발 환경 - 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
  • 6. 모바일 앱 진단의 핵심 활동인 성능 분석은 총 7가지의 방법으로 구분되어 단계 별로 진행 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 앱 (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. 병목 구간 유무 및 원인 분석 1. 진단 환경 구성 2. 진단 3.결과 정리 6
  • 7. 모바일 Front End 분석 1. 화면 로딩 시간 진단을 통해 사용 시 병목구간의 발생 여부를 확인하고 이에 대한 원인을 분석 (결과 리포트 예시) 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 4.2.3.10 앱 진단 (Front-end) – 분석1. 화면 로딩시간 분석 1. 화면 로딩 시간 – 3. 병목구간 측정 (1/2)  병목구간 발생  Main Activity에서 일부 병목구간 발생 → 메인 화면에서 CALL 하는 그리는 UI 객체가 많음이슈 및 문제점 개선 방향  3.0 메인 화면의 call 객체 간소화 및 상대 좌표를 통한 레이아웃 구성 변경 7
  • 8. 모바일 Front End 분석 1. 화면 로딩 시간 진단을 통해 사용 시 병목구간의 발생 여부를 확인하고 이에 대한 원인을 분석 (결과 리포트 예시) 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 4.2.3.10 앱 진단 (Front-end) – 분석1. 화면 로딩시간 분석 1. 화면 로딩 시간 – 3. 병목구간 측정 (2/2)  LoginActivity가 4초 이상 소요됨에 따라 로그인 응답시간이 1.5초 이상 소요됨이슈 및 문제점 개선 방향  로그인 관련 API의 최적화 필요 (로그인 인증에 특화된 서버 캐시 도입 필요)  병목구간 발생 8
  • 9. 하이브리드 앱의 웹 화면 로딩 속도 프로파일링 (서버 시간, 앱 내부 로딩 시간 별도로 판단 가능) 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 분석 3. 자원 사용량  해당 없음 이슈 및 문제점 개선방향  해당 없음 4.2.3.10 앱 진단 (Front-end) – 분석3. 자원 사용량 9
  • 10. 모바일 앱에서 호출되는 기능 중에 네트워크 응답시간이 많이 걸리는 하위 메소드를 파악 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 분석 2. 네트워크 응답시간 (Response Time) 1. 하위 5% 응답시간 해당되는 기능 분석 • 분석 내용 (Fact) - SK/ KT/ LG 등 외부망 이용 시 통신 환경에 따른 Delay가 발생할 수 있음 4.2.3.10 앱 진단 (Front-end) – 분석2. 네트워크 응답시간 10
  • 11. 시간대별 네트워크 응답시간과 앱 성능을 분석 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 분석 2. 네트워크 응답시간 (Response Time) 4.2.3.10 앱 진단 (Front-end) – 분석2. 네트워크 응답시간 2. 하루 중 응답시간이 가장 낮은 시간대 • 분석 내용 (Fact) - 네트워크 응답시간이 가장 늦은 시간대는 3:00 ~ 3:30pm (일간 추이) 11
  • 12. 모바일 Front End 성능 분석은 총 7가지 방법으로 구분되며, 분석 2.에서는 네트워크 응답시간에 대한 성능을 분석 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 분석 2. 네트워크 응답시간 (Response Time) 느린 (SLOW) 구간의 Path가 특정하지 않고 산재되어 있음 이슈 및 문제점 개선방향  서버 연결 통신망을 기준으로 느린 구간에 대한 원인 파악 필요 (서버 문제 vs. 통신사 문제) 3. 응답시간 통계 *느린 구간 기준 • 분석 내용 (Fact) Wi-Fi 환경에서는 99.9 % 가 1초 이내에 응답하는 우수한 상황 4.2.3.10 앱 진단 (Front-end) – 분석2. 네트워크 응답시간 12
  • 13. 모바일 앱의 단말기에서 CPU와 메모리 자원 사용량에 대한 성능을 분석 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 분석 3. 자원 사용량  해당 없음 이슈 및 문제점 개선방향  해당 없음 사용량 전체 중 상위 95%, 하위 5% 분류 4.2.3.10 앱 진단 (Front-end) – 분석3. 자원 사용량 자원 사용량 : CPU 자원 사용량 : 메모리 • 분석 내용 (Fact) CPU 권고 사용량 50% 이하에서 평균 사용량 13%, 하위 5% → 22% 사용 • 분석 내용 (Fact) 메모리 권고 사용량 100MB 이하에서 평균 20MB, 하위 5% → 28MB 사용 우수 우수 13
  • 14. 사용자 모바일 기기의 배터리 사용량에 대한 성능을 분석 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 분석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. 뮤직 • 분석 내용 (Fact) 배터리 사용량이 비교 대상 A와 B 대비 낮은 편 우수 • 3000mAh 기준으로 평가 14
  • 15. 서비스 사용자의 주 이용 통신사를 분석 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 분석7. 통신사  모수의 부족 SK Telecom의 응답시간이 타 통신사에 비해 느림 이슈 및 문제점 개선방향  국내 인구 비율상 SK Telecom 사용자가 많으므로, 상대적으로 더 많은 기지국 확충이 필요해 보임 4.2.3.10 앱 진단 (Front-end) – 분석7. 통신사 국내 3대 통신사 별 통신 응답시간 • 분석 내용 (Fact) SK Telecom의 속도가 다른 통신사에 비해 느림 15
  • 16. 웹 서버 성능 진단 16
  • 17. 4.2.3.11 부하 진단 (Back-end) - 개요 Back End 진단은 1. 환경 분석, 2. 진단 준비, 3. 전체 성능 분석, 4. 단위 성능 분석, 5. 결과 도출의 총 5가지 내용으로 진행 부하 (Back-end) 진단 절차 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 환경 분석 진단 준비 진단 환경 검증 전체 성능 분석 결과 도출  서버 로그 분석  부하 테스트 시나리오  고객 요구사항  부하테스트 대상 환경 - 대상 : 해당 앱  부하테스트 환경 - Google Cloud 10대 - Jmeter 5.1 - Open JDK 1.8  테스트 스크립트 작성 - Jmeter 를 이용하여 작성 (.jmx 파일)  진단 횟수: 3회  진단 방법 - 개발 환경에 테스트 시나리오 검증  분석 방법 - Jmeter를 통한 전체 시나리오 테스트  분석 항목 - 요청 값 및 응답 값 확인 - 정상 서버 처리 확인 - 비정상 API 확인  진단 횟수: 5회  진단 방법 - 개별 시나리오 부하 테스트 및 분석 리포트 제공  분석 방법 - Jmeter를 통한 Warm-Up 방식 부하 테스트  분석 항목 - 응답시간 및 TPS - 에러율 및 임계값 - 비정상 API  ‘성능 분석 리포트’ - 성능 분석 내용 - 문제 원인 및 해결 방안  Lessons & Learn - 장애 및 성능 문제 요소  To-Be 모델 - 개발 관점 - 운영 관점 1. 진단 환경 구성 2. 진단 3.결과 정리 17
  • 18. 4.2.3.11 부하 진단 (Back-end) – 환경 구성부하 진단은 해당 앱에서 사용하는 API를 분석하여 진단 시나리오를 작성한 후 J-Meter를 이용하여 테스트 스크립트를 작성한 후 진단 환경을 구성 부하 (Back-end) 진단 방안 4.2.3 모바일 발매 업무/시스템 현황 4. 업무 및 정보시스템 현황분석 4.2 발매 업무 및 정보시스템 현황분석 단위 테스트 시나리오 테스트 테스트 케이스 B 테스트 케이스 C 전체 API 테스트 비정상 API 테스트 테스트 케이스 A 해당 앱 서버  APM Jmeter 와 Google Cloud 부하 테스트 환경 1. 진단 환경 구성 2. 진단 3.결과 정리 Jmeter Google Cloud Instance 시나리오 별 테스트 스크립트 작성 18
  • 19. 부하테스트 주요 논의 사항 •현 테스트 시나리오 분석 •테스트 시나리오 보완 방법 •부하 테스트 진행 방안 •부하 테스트 전략 협의 •클라우드 기반의 테스트 방안 19
  • 20. 1. 부하테스트 목적 •단위 서버(테스트 서버) 기준, 최대 동시 접속자 수 산정 •실제 서버 기준, 사용자 시나리오(1) 기반으로 한 테스트 •실제 서버 기준, 트랜잭션 단위 테스트의 스트레스 테스트(2) •실제 서버 기준, 부하 테스트(3)를 통한 임계값(Saturation Point) 산정 •실제 서버 기준, 동시 접속자 수, TPS, 응답시간 산정 (1)사용자 시나리오 : 실제 해당 앱의 사용자의 사용 흐름을 분석하여 테스트 시나리오를 작성 (2)스트레스(Stress) 테스트 : 시스템이 과부하 상태에서 어떻게 작동하는지를 검사하는 테스트 (3)부하(Load) 테스트 : 서버 자원의 한계에 도달할 때까지 시스템에 부하를 꾸준히 증가시키며 진행하는 테스트 20
  • 21. •1안) 실제 사용 상황에 맞는 시나리오에 대한 테스트 •주요 화면 (Account, Activity, Report, Support) 접속 •2안) 사용자로부터 HTTP(S) 요청을 추출해서 시나리오 산정 (IMQA) •특정일에 사용자가 발생시키는 데이터 분석 후 전달 가능 2. 테스트 시나리오 보완 방법 논의 21
  • 22. •고객사와 협의 후 시나리오 도출 •(예시) Account, Activity, Report, Support •경우 1_ 위 4개 주요 화면에 들어가는 비율 협의 - Account, Activity, Report, Support 별 비율 도출 •경우 2_ 문제가 있는 화면만 주요 선정 - Activity가 특히 느리다면, 그 부분만 집중 산정 1안) 실제 사용 상황에 맞는 시나리오에 대한 테스트 22
  • 23. 2안) HTTP(S) 요청을 추출해서 시나리오 산정 특정 시간 기준, 주요 트랜잭션 분포를 통한 시나리오 산정 23
  • 24. •주요 시나리오 테스트 (Warm-Up 테스트) - 주요 시나리오 선정 후 시나리오 별로 얼마나 견디는지 테스트 •트랜잭션 별 단위 테스트 (Warm-Up 테스트) - Top 20에 대한 트랜잭션에 대해서 얼마나 견디는지 테스트 •주요 시나리오 가중치 테스트 (시나리오 별 가중치 테스트, Warm-Up 테스트) - 위 선정된 주요 시나리오에 가중치를 부여하여 테스트 예 ) A 시나리오 30%, B 시나리오 20%, C 시나리오 50% 3. 부하 테스트 진행 방향 24
  • 25. 3-1. 최대 용량 산정 기준 협의 25
  • 27. 시나리오 테스트 예시 합격자 발표 시나리오, 1만 명씩 늘려서 테스트 부하 테스트 1만 명 진행 합격자 발표 시나리오는 1만 명 이전까지는 큰 문제가 발생하지 않았다. 다만, 1만 명이 넘어가는 순간 다량의 쿼리를 사용하는 서비스인 getRecruitList에서 문제가 발생하는 것을 확인할 수 있었다. 평균적으로 3초에서 4초대의 응답시간을 보였으며, 3만 명에서는 8초 정도의 응답시간을 보이기도 했다. 2만 명 이상 테스트를 할 경우에는 중간중간 에러가 많이 발생하였으며, 해당 에러는 Timeout wating for idle object로 확인이 되었다. 대부분 느린 쿼리로 인해 발생 한 문제로 추측이 된다. 부하 테스트 2만 명 진행 부하 테스트 3만 명 진행 A사 부하테스트 예시27
  • 28. CConnection Pool 수치는 현재로서는 적당한 수치로 보인다. 다만, 테스트 당일 기준으로 첫 페이지에서 다량의 쿼리로 인해 서비스 전체가 느려진 것을 확인할 수 있었다. 최대 3만 명까지는 대부분은 문제가 없었으나, 일부 사용자들이 4초 이상 응답 속도를 보였다. 4초 이상 걸리는 대부분의 응답 서비스는 메인 페이지에서 오래 걸린 것으로 확인이 된다. 2만 명 이상의 사용자가 방문했을 경우 에러가 많이 잡혔으며, 이는 느린 쿼리의 문제로 추측이 된다. 호출과 /getRecruitList의 성능 저하가 대부분이었으며, 호출에서는 4초 이상 걸리는 단일 쿼리가 많이 잡혔다. 메인 페이지 호출 빈도를 줄이거나 메인 페이지의 데이터를 Caching 하는 방법으로 호출 빈도를 줄이는 것도 방법으로 보인다. 또는 쿼리 튜닝이나 합격자 발표를 위한 별도의 페이지를 만드는 것도 한 방법으로 보인다. 합격자 발표 자체에서의 큰 문제는 발생하지 않았다. (대부분 3초 이내의 응답속도) 테스트 결과 → 이때 문제가 되는 트랜잭션들을 선정해 트랜잭션 단위 테스트 진행 시나리오 테스트 분석 후 - 테스트 결과 공유 A사 부하테스트 예시 28
  • 29. 부하테스트 2만 명 진행 TC 02 - 01에 비해서 역시 좋은 성능을 보여주고 있다. 대부분 3초 이내로 응답하였으며, 1초 이내의 데이터에서 진한 색으로 표시된 것으로 보아 대부분은 안정적으로 데이터 응답을 하는 것으로 보인다. 부하 테스트 3만 명 진행 개선후 시나리오 테스트 Before / After 비교 A사 부하테스트 예시 29
  • 30. 테스트 결과 TC 02 - 01 과 비교했을 경우 80% 이상의 성능 향상을 보여주고 있다. 3차 테스트에서는 합격자 발표 부하 테스트의 최대 수용 가능한 사용자 수를 측정하고 산출하여도 큰 이상이 없는 성능을 보여주고 있다. 그래도 응답시간이 늦은 서비스가 보였으며 해당 부분은 Join 문을 사용 하고 있어 어쩔 수 없이 저하가 발생할 수밖에 없는 부분으로 보인다. 사용자 3만 명부터 늦은 응답시간을 보인 비중은 1200히트 정도이며 이 는 전체에 1%에 해당되는 수치이다. 시나리오 부하테스트 후 해석 결과 전달 A사 부하테스트 예시 30
  • 31. 1) 현 서비스 최소 단위 구성 후 선 테스트 •현 서비스의 최소 단위 WAS, DB 등의 세트를 구성해서 테스트 •섹션 3에서 언급한 시나리오별, 트랜잭션 별, 시나리오 가중치 별 테스트 •최소 단위 세트에서 부하 분석 후 컨설팅 리포트 제공 •주요 트랜잭션 테스트의 성능 고도화에 집중 4. 부하 테스트 단계별 전략 31
  • 32. 2) 최소 셋트에서 문제점 도출및 안정화 진행 • PRETEST (사전 테스트) : 관련 스크립트 및 환경 구성 체크 (방화벽, 네트워크 대역폭, 클러스터링) • MAINTEST (계통 테스트) : 관련 에러 및 문제점 도출 (평균 1,2주) • CONFORMATION TEST (확인 테스트/재 테스트) : 결함이 해결되었는지 검증하는 테스트 • REGRESSIO TEST (회귀테스트) : 변화에 대한 영향 검증 4. 부하 테스트 단계별 전략 32
  • 33. 3) 실 서비스 대용량 부하 테스트 • 섹션 3에서 언급한 시나리오 별, 트랜잭션 별, 시나리오 가중치 별 테스트 • 클라우드 기반의 1000대 인스턴스로 테스트 • 주요 성능 리포트 제공 4. 부하 테스트 단계별 전략 33
  • 34. 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
  • 35. 참고 자료) 퍼포먼스 테스트 툴 사용 후기 https://tech.madup.com/2018/07/17/performance_test_tool.html • Wrk : 몇 개 날리는 게 상관없이 간단하게 서버 부하 테스트를 하고 싶을 때 • Vegeta : 초당 몇 개의 부하를 버티는지 테스트하고 싶을 때 • Gatling : 높은 성능, 시나리오 작성, html 보고서 • JMeter : 다양한 기능이나 플러그인이 강점 / 빠른 시나리오 작성 가능 • nGrinder : 시나리오, 시나리오 가중치 테스트 불가, 개별 트랜잭션 TPS 측정에 중점, Thread 기반으로 구현되어 있어 성능과 동시성에 대해 제한이 있음. (grinder) 5. 관련 툴 선정 (부하 발생기) 35
  • 36. 5. 관련 툴 선정 (APM) 36 솔루션 개요 주요 기능 제니퍼 소프트 업계 1위 APM APM의 시초 강력한 지원 • 실시간 트래픽 수집의 최강자 다양한 파트너와 연동 (모바일 , DB 모니터링 연동) • 실 사례 및 문제 발생 시 연계 할 파트너 多 리포트 및 분석 기능이 강력함, 타사 제품과 연동성 강력, 업계 1위의 안정성 Elastic APM 다양한 언어를 지원하는 APM • 다양한 언어를 지원 (java,node,python, ruby 등) • 오픈소스로 누구나 사용 가능 • 실시간 장애 인지보다는 장애 후 원인 분석 가능 Java 이외의 언어도 , 무상으로 쓸수 있는 APM (Java, .NET, Ruby, Python, Node, Go 등)
  • 37. 5. 관련 툴 선정 (APM) 37 솔루션 개요 주요 기능 와탭 SaaS형 APM 쉬운 설치와 서버 용량 걱정 없는 무료 사용 (15일 제한) • 막대한 트래픽의 모니터링을 클라우드 상에서 모두 수집 가능 (15일 후 데이터 자동 파기) • 트랜잭션에서 걸리는 스택까지 수집 가능 (강점-타 APM 없는 독보적인 기능) • 정확한 동시 접속자 수 산정 가능 (실 유저로 수집 가능) SaaS형으로 설치 용이 Pinpoint End 2 End 트랜잭션 분석 가능 (네이버 개발) • 제니퍼와 유사한 기능 보유 • End2End Transaction을 모니터링하는데 중점적임 내부 설치 시 사용 / End 2 End 모니터링 시 필수
  • 39. 컨설팅 비용 39 솔루션 모바일 서버 성능 모니터링 모바일 자동화 테스트 웹 서버 성능 테스트 가격 비상주 5,000,000 협의 후 픽스 테스트 케이스 양에 비례 상주 1일/ 1,000,000 비상주 1일/ 700,000 기간 1~2주 소요 1일 테스트 / 1달 단위 1~2주 소요
  • 40. 감사합니다. 자세한 솔루션 문의는 전문 컨설턴트가 도와드립니다. 본사 : 서울특별시 중구 세종대로21길 22 태성빌딩 l TEL : 02-541-0080 연구소 : 경기도 용인시 기흥구 흥덕중앙로 120, U-Tower 담당 : 이수민 대리 l lsm0516@onycom.com 조기홍 책임 l loveu2020@onycom.com