SlideShare ist ein Scribd-Unternehmen logo
1 von 92
Downloaden Sie, um offline zu lesen
실전 서버 부하 테스트 노하우
손영수, 차용빈
ysson@onycom.com
어니컴 성능솔루션 사업부
발표에 앞서
어니컴은
마사회, 대기업 입사 지원 시스템, 글로벌 제약회사, ERP등
다양한 업체의 부하 성능 테스트및 컨설팅을 한 경험을 가진 회사입니다.
이 자료는 부하 테스트 / 성능 측정 노하우를 공유하는 자료입니다.
(https://www.facebook.com/imqa.io 에서 자료 공개 예정)
모든 저작권은 어니컴에 있음을 알려 드리며,
원본 출처를 공개하는 조건에서 재 배포를 허락합니다.
0. 개요 그리고 오해 풀기..
웹 어플리케이션은 어떻게 동작하나
User
Transaction
SQL SQL
Http
File
Resource
`
부하 테스트 솔루션은 어떻게 동작하냐?
컨트
롤러
스크
립트
에이전트
에이전트
프로세스
프로세스
쓰레드 1
쓰레드 2
쓰레드 3
쓰레드 4
쓰레드 5
쓰레드 6
USER
USER
USER
USER
USER
USER
프로세스
프로세스
부하 테스트 하기
자원을 사용트랜잭션 처리부하발생기
Transaction
SQL SQL
Http
File
Resource
`
컨트롤러
가상 유저
부하 테스트시 실수 하는 것?
• 부하만 정말 열심히 준다.
• 자 서버 죽었어요?
• 개발자 : 원인이 무엇인가요…
• 병목 지점을 판단해서 코드 레벨로 말해주기를 원한다.
• 성능 테스터 : 전 개발자가 아닌데요…
• 고객 : 병목지점을 꼭 찍어서 알려 주셔야죠
• 결론 : 개발자만큼 알아야 한다 (Java, Node, Python등..)
진짜 우리가 해야 할 것은?
Transaction
SQL SQL
Http
File
Resource
`
인프라 모니터링어플리케이션 모니터링
부하발생기
부하발생기 가상 유저
부하 주기 뿐만 아니라 + @를 잘해야 한다.
• 부하는 어떻게 발생시키는 가? (Jmeter 잘 쓰기)
• 발생된 트랜잭션을 잘 처리하는가? 병목 찾기 (APM 사용하기)
• 서버의 자원은 충분한가? (서버 모니터링 - 성능 지표 읽기)
• 고급 주제
• 테스트를 현실적으로 잘 할려면 어떻게 해야 하는가? (테스트 계획안)
• 테스트에 필요한 요청사항들은? (어떠한 데이터를 수집해야 하나?)
• 클라우드 사용시 주의해야 할 것들은? (클라우드의 함정)
성능 테스팅이란?
• 목적
시스템의 병목 지점을 찾는 것!
성능 테스트 정의
• 정의 :
특정 부하에서 응답성 및 안정성 측면에서, 시스템이 어떻게 동작
하는지, 측정하기 위한 비 기능 테스트입니다.
• 얻을 수 있는 것들 :
확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성
을 조사, 측정, 검증 또는 검증 할 수 있습니다
성능 테스트의 종류
부하 / 용량 산정 테스팅
Load/Capacity Testing
스트레스 테스팅
Stress Testing
내구성 테스트
Endurance/Soak Testing
최고점 부하 테스트
Spike Testing
간단한 정리
1. JMeter 다루기
7일안에 Jmeter 끝내기 : https://www.guru99.com/jmeter-tutorials.html
Blazemeter Jmeter 무료 Webcast : https://www.blazemeter.com/jmeter/
ONYCOM 방문 강좌 : 직원 1명당 10만원 (최소 강좌 100만원부터 시작)
2. 성능 부하 테스트 안
주요 논의 사항
• 현 테스트 시나리오 분석
• 테스트 시나리오 보완 방법
• 부하 테스트 진행방안
• 부하 테스트 전략 협의
• 클라우드 기반의 테스트 방안
16
0. 부하테스트 목적
• 단위 서버(STG 서버) 기준, 최대 동시접속자 수 산정
• 실제 서버 기준, 사용자 시나리오(1) 기반으로 한 테스트
• 실제 서버 기준, 트랜잭션 단위 테스트의 스트레스 테스트(2)
• 실제 서버 기준, 부하 테스트(3)를 통한 임계값(Saturation Point) 산정
• 실제 서버 기준, 동시접속자 수, TPS, 응답시간 산정
17
(1)사용자 시나리오 : 실제 마사회 마이카드를 사용하는 사용자의 사용 흐름을 분석하여 테스트 시나리오를 작성함.
(2)스트레스(Stress) 테스트 : 시스템이 과부하 상태에서 어떻게 작동하는지를 검사하는 테스트.
(3)부하(Load) 테스트 : 서버 자원의 한계에 도달할 때까지 시스템에 부하를 꾸준히 증가시키며 진행하는 테스트.
• Wrk : 간단하게 서버 부하 테스트를 하고 싶을 때
• Vegeta : 초당 몇 개의 부하를 버티는지 테스트 하고 싶을 때
• Gatling : 높은 성능, 시나리오 작성, html 보고서 (코드 작성 필요)
• JMeter : 다양한 기능이나 플러그인이 강점 / 빠른 시나리오 작성 가능
• nGrinder : 시나리오, 시나리오 가중치 테스트 불가 , 개별 트랜잭션 TPS 측정에
중점 , Thread 기반으로 구현되어 있어 성능과 동시성에 대해 제한이 있음.
18
1. 부하 관련 툴 선정 (장단점.)
2안. JMETER
ü기존 시스템 인터페이스 이용및 변경 적음
üTPS 기반의 단순 테스트에는 유리함
X시나리오 기반 테스트 및 가중치 테스트 불가
X빈약한 리포트
JMETER
ü다양한 결과 리포트 쉽게 얻을수 있음
üTPS / 시나리오 기반 /가중치 기반 테스트 가능
ü빠른 부하 스크립트 개발이 가능 (1~3일)
ü풍부한 플러그인 제공 (상용, 무료 많음)
X진입점 (잘 정리된 자료가 없다)
X빈약한 리포트
1. 부하 관련 툴 선정 (부하 발생기)
Agent
1안. nGrinder
Agent Agent …Agent
nGrinder
Controller
API API API
고객
서비스
고객
서비스
컨트
롤러
스크
립트
에이전트
에이전트
프로세스
프로세스
쓰레드 1
쓰레드 2
쓰레드 3
쓰레드 4
쓰레드 5
쓰레드 6
USER
USER
USER
USER
USER
USER
프로세스
프로세스
20
참고. 부하 발생 구조
• 1안) 사용 상황에 맞는 시나리오 수립 후 테스트 (배포전)
• 가입 / 수강 / 결재 시나리오
• 딜 종료 후, 결과 확인 시나리오
• 딜 정보 확인 및 배당률 확인 시나리오
• 2안) 사용자로 부터 HTTP(S) 요청을 추출해서 시나리오 산정 (APM 사용)
• 내부 APM 연동 후 데이터 수집. (상용, 오픈소스, 유료 15일)
• 가능하다면 베타 그룹, 크라우드 테스트를 통해 데이터 수집 할 것을 추천
21
2. 테스트 시나리오 보완 방법 논의
• 고객별 시나리오 도출
• 예)
• 경우1_ 5분전에 구매를 완료하는 사용자 비율
• 선 구매 이후 ­> 반복되는 실시간 배당율 확인
• 경우2_ 30~10 초 전에 구매를 완료하는 사용자 비율
• 실시간 배당율 확인 및 실시간 배팅 정보구매
22
1안) 실제 사용 상황에 맞는 시나리오에 대한 테스트
시나리오를 완벽하게 도출하기 위해서 협의 필요
Blazemeter : Jmeter 스크립트 생성 도구(크롬 플러그인)
스크립트 녹화 녹화된 스크립트 편집 다양한 포멧으로 저장
25
2안) APM의 결과를 추출해서 시나리오 산정
경기 시간 기준, 주요 트랜잭션 분포를 통한 시나리오 산정
• 주요 시나리오 테스트 (Warm-Up 테스트)
• 주요 시나리오 선정 후 (가입 , 강좌 수강등) 시나리오별로 얼마나 견디는지 테스트
•
• 트랜잭션별 단위 테스트 (Warm-Up 테스트)
• Top 20에 대한 트랜잭션에 대해서 얼마나 견디는지 테스트
• 주요 시나리오 가중치 테스트 (시나리오 별 가중치 테스트, Warm-Up 테스트)
• 위 선정된 주요 시나리오에 가중치를 부여 하여 테스트
• 예 ) A 시나리오 30%, B 시나리오 20%, C 시나리오 50%
26
3. 부하 테스트 진행 방향
27
3.1. Warm-Up 테스트 진행 (기준 정하기)
28
3.2. 주요 시나리오 선정
시나리오 테스트 예시
합격자 발표 시나리오, 1만명씩 늘려서 테스트
부하테스트 1만명 진행
합격자 발표 시나리오는 1만명 이전까지는 큰 문제가 발생하지 않았다.
다만, 1만명이 넘어가는 순간 다량의 쿼리를 사용하는 서비스인 getRecruitList 에서 문제가 발생하는 것을 확인 할 수 있었다.
평균적으로 3초에서 4초대의 응답시간을 보였으며, 3만명에서는 8초 정도의 응답시간을 보이기도 했다.
2만명 이상 테스트를 할 경우에는 중간중간 에러가 많이 발생 하였으며, 해당 에러는 Timeout wating for idle object로 확인이 되었다.
대부분 느린 쿼리로 인해 발생 한 문제로 추측이 된다.
부하테스트 2만명 진행 부하테스트 3만명 진행
A사 부하테스트 예시
29
Connection Pool 수치는 현재로서는 적당한 수치로 보인다.
다만, 테스트 당일 기준으로 첫 페이지에서 다량의 쿼리로 인해 서비스 전체가 느려진 것을 확인 할 수 있었다.
최대 3만명까지는 대부분은 문제가 없었으나, 일부 사용자들이 4초 이상 응답 속도를 보였다.
4초 이상 걸리는 대부분의 응답 서비스는 메인 페이지에서 오래 걸린 것으로 확인이 된다.
2만명 이상의 사용자가 방문 했을 경우 에러가 많이 잡혔으며, 이는 느린 쿼리의 문제로 추측이 된다.
/ 호출과 /getRecruitList의 성능 저하가 대부분이었으며, / 호출에서는 4초 이상 걸리는 단일 쿼리가 많이 잡혔다.
메인 페이지 호출 빈도를 줄이거나 메인페이지의 데이터를 Caching하는 방법으로 호출 빈도를 줄이는 것도 한 방법으로 보
인다.
또는 쿼리 튜닝이나 합격자 발표를 위한 별도의 페이지를 만드는 것도 한 방법으로 보인다.
합격자 발표 자체에서의 큰 문제는 발생하지 않았다. (대부분 3초 이내의 응답속도)
3. 테스트 결과
이때 문제가 되는 트랜잭션들을 선정해 트랜잭션 단위 테스트 진행
시나리오 테스트 분석 후 - 테스트 결과 공유
30
A사 부하테스트 예시
부하테스트 2만명
TC 02 - 01 에 비해서 역시 좋은 성능을 보여주고 있다.
대부분 3초 이내로 응답하였으며, 1초 이내의 데이터에서 진한색으로 표시된 것으로 보아 대부분은 안정적으로
데이터 응답을 하는 것으로 보인다.
부하테스트 3만명 진행
개선 후 시나리오 테스트 Before / After 비교
A사 부하테스트 예시
31
부하테스트 3만명
3. 테스트 결과
합격자 발표 시나리오를
비교했을 경우 80% 이상의 성능 향상을 보여주고 있다.
3차 테스트에서는 합격자 발표 부하테스트의 최대 수용 가능한 사용자 수를 측
정하고 산출하여도 큰 이상이 없는 성능을 보여주고 있다.
응답시간이 늦은 서비스가 보였으며 해당 부분은 Join문을 사용하고 있어 어쩔
수 없이 저하가 발생 할 수 밖에 없는 부분으로 보인다.
사용자 3만명부터 늦은 응답시간을 보인 비중은 1200히트 정도이며 이는 전
체에 1%에 해당되는 수치이다.
시나리오 부하테스트 후, 해석 결과 전달
A사 부하테스트 예시
32
1) 현 서비스 최소 단위 구성하기
• 현 서비스의 최소 단위 WAS, DB등의 세트를 구성해서 테스트
• 섹션 3에서 언급한 시나리오별, 트랜잭션별, 시나리오 가중치 별 테스트
• 최소 단위 세트에서 부하 분석후 컨설팅 리포트 제공
• 주요 트랜잭션 테스트의 성능 고도화에 집중
33
4. 부하 테스트 단계별 전략
2) 최소 셋트에서 문제점 도출및 안정화 진행
• PRETEST (사전 테스트) : 관련 스크립트및 환경 구성 체크 (방화벽, 네트워크 대역폭, 클러스터링)
• MAINTEST (계통 테스트) : 관련 에러 및 문제점 도출 (평균 1,2주)
• CONFORMATION TEST (확인 테스트/재 테스트) : 결함이 해결되었는지 검증하는 테스트
• REGRESSIO TEST (회귀테스트) : 변화에 대한 영향 검증
34
4. 부하 테스트 단계별 전략
3) 실 서비스 대용량 부하 테스트
• 섹션 3에서 언급한 시나리오 별, 트랜잭션 별, 시나리오 가중치 별 테스트
• 클라우드 기반의 100대 인스턴스로 테스트 (100대면 가상 유저 4000명 정도는 가능)
• 주요 성능 리포트 제공
35
4. 부하 테스트 단계별 전략
솔루션 개요 주요 기능
제니퍼 소프트
업계 1위의 APM
APM의 시초
강력한 지원
∙ 실시간 트래픽 수집의 최강자
다양한 파트너와 연동 (모바일 , DB 모니터링 연동)
실 사례및 문제 발생 시 도와줄 파트너가 많다
리포트및 분석 기능이 강력함, 타사 제품과 연동성 강력, 업계 1위의 안정성
Elastic APM
다양한 언어를 지원하
는 APM
• 다양한 언어를 지원 (java,node,python, ruby 등)
• 오픈소스 로 누구나 사용 가능함.
• 실시간 장애 인지보다는 장애 후 원인 분석 가능
Java 이외의 언어도 , 무상으로 쓸수 있는 APM (Java, .NET, Ruby, Python, Node. Go 등)
36
5. 관련 툴 선정 (APM)
솔루션 개요 주요 기능
와탭
SaaS형 APM으로
큰 설치없이 서버 용
량 걱정없이 무료로
사용가능
(15일 제한)
∙ 막대한 트래픽의 모니터링을 클라우드 상에서 다 수집이 가능
(15일후 데이터 자동 파기)
∙ 트랜잭션에서 걸리는 스택까지 수집이 가능 (강점- 타 APM 없는 기능)
∙ 정확한 동시 접속자 수 산정 가능 (실 유저로 수집이 가능함)
리포트및 분석 기능이 강력함, 15일간 모든 기능을 사용 가능
Pinpoint
End 2 End 트랜잭션
분석이 가능함
( 네이버 개발 )
• 제니퍼와 유사한 기능을지고 있음
• End2End Transaction을 모니터링 하는데 초점이 있음
내부 솔루션 설치의 어려움 / 적절한 용량 논의후 구성
가능한 고객이 사용하는 APM으로 데이터 해석이 필요함.
유료 제품인 경우 APM은 라이센스 문제로 최소 셋트 테스트에만 적용
37
5. 관련 툴 선정 (APM)
38
5. 왜 Jmeter를 사용해야 하나? 클라우드 연동
구글 클라우드를 활용한 부하 분산 테스트의 경우에는 JMeter 2.9를 이용합니다.
JMeter 4 버전 이후에는 SSL 관련 옵션 등 많은 변경부분 때문에, 2.9를 사용합니다.
참
고
X
권장 OS : OS X, Linux
부하 분산 테스트 환경 구축
39
jmeter controller
jmeter server
7.1. JMeter Controller 설정
40
remote_hosts=10.0.0.2,10.0.0.3,...,10.0.0.n
통신 포트 설정 변경
41
통신 포트 설정 변경
42
jmeter-server 설정
server_port=2099
server.rmi.localport=4000
jmeter controller 설정
remote_hosts=10.0.0.2:2099
client.rmi.localport=4001
8. 테스트 시 주의 사항
43
44
Jmeter + Google Cloud 관련 프로젝트 링크 - https://bit.ly/2AVq0pk
X
권장 OS : OS X, Linux
단 바로 작동하지 않음.
요즘 Google Cloud 관련 API를 변경 및 추가 후 사용할 수 있음.
중급 기준 : 1달 정도 추가 개발 필요.
1) 버킷 생성하기
45
Console 화면에서 Storage 페이지로 이동한다
1) 버킷 생성하기
46
Storage 버킷을 만듭니다. 버킷 이름은 원하든 대로 입력을 해주시고, 만들기 버튼을 누른다.
gcp_upload_files 폴더에 있는 내용을 전체 올려줍니다
1) 버킷 생성하기
47
Jmeter-server 파일을 올려줍니다
2) 구글 클라우드 플랫폼 인증 설정
4
8
구글 클라우드 플랫폼에 스크립트가 접근하기 위해서는 API 사용자 인증이 필요하다.
그림과 같이 API 및 서비스 메뉴로 접근한다
2) 구글 클라우드 플랫폼 인증 설정
4
9
API 및 서비스 메뉴에서 사용자 인증 정보 탭으로 이동한다
2) 구글 클라우드 플랫폼 인증 설정
5
0
OAuth 동의 화면 탭으로 이동하여, 애플리케이션 이름 부분에 원하는 이름을 적은 후 저장한다
2) 구글 클라우드 플랫폼 인증 설정
5
1
사용자 인증 정보 탭으로 다시 이동하여, 사용자 인증 정보를 만든다. 이때 OAuth 클라이언트 ID를 선택한다
2) 구글 클라우드 플랫폼 인증 설정
5
2
기타를 선택한 후 원하는 이름을 적어 클라이언트 ID 를 만든다
2) 구글 클라우드 플랫폼 인증 설정
5
3
클라이언트 ID와 클라이언트 보안 비밀은 따로 저장을 해 두십시오.
스크립트에서 사용이 됩니다. 설정이 이 페이지에서 다시 확인 할 수 있다
4) 스크립트 실행 방법
5
4
# JMETER 인스턴스 생성하기 (PREFIX에 구분할 수 있는 접두어 설정)
(NUMBER에 생성하고 싶은 인스턴스 갯수)
./jmeter_cluster.py start --prefix <PREFIX> <NUMBER>
# JMETER 서버들 종료하고 반납하기
./jmeter_cluster.py shutdown --prefix <PREFIX>
# JMETER 클라이언트를 실행 방법
./jmeter_cluster.py client
3. 서버 성능 분석하기
진짜 우리가 해야 할 것은?
Transaction
SQL SQL
Http
File
Resource
`
Infra 모니터링어플리케이션 모니터링
부하발생기
부하발생기 가상 유저
1) 운영체제에서는 어떤 데이터를 수집해야 하나?
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
어려운 방법보다 USE 메소드를 이용.
Saturation
Utilization
X
Errors
Utilization : 얼만큼 자원을 썼는지?
Saturation : 얼마나 많은 부하(extra works)가 들어왔는지.
Error : 발생한 에러는?
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
USE 메소드의 예.
Resource Utilization Saturation Errors
CPU mpstat-PALL1,
sumnon-idlefields
vmstat1,"r" perf
Memory
Capacity free­m,"used"/"total"
vmstat1,"si"+"so";
demsg|grepkilled
dmesg
StorageI/O iostat­xz1,
"%util"
iostat­xnz1,
"avgqu-sz">1
/sys/…/ioerr_cnt;
smartctl
Network nicstat,"%Util" ifconfig,"overrunns";
netstat­s"retrans…"
ifconfig,
"errors"
주의할 점 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
2) 고객이 클라우드를 사용한다면..
클라우드는 공유 자원..
클라우드는 공유 자원..
요청이 많으면 즉 내 차례를 기다리거나..
클라우드는 공유 자원..
상황에 맞게 제한된 자원을
나눠가지던가..
잘 동작하던 게임서버에서
User들이
갑자기 튕겨나간 사례.
IOPS가 높을때 마다, Disk Queue Length가 높은 수치로 증가 -> 클라우
드에선 늘 발생할 수 있는 문제..
몇몇 존에 있는 서버만 IOPS가 250으로 항상 일정
알고보니 자원의 제약..
해결책..
만약 A사 (AM?, AZ?)
제품이면 제값 주고
Provisioned IOPS 구입!
해결책..
만약 A사 (AM?, AZ?)
제품이면 제값 주고
Premium Storage Disk 구입!
클라우드 환경에서 수집해야 되는 대표적인 지표 몇개.
§ IOPS
§ Disk Queue Length (win) / iowait (linux)
§ CPU Steal Time 등..
§ http://bencane.com/2012/08/06/troub
leshooting-high-io-wait-in-linux/
클라우드 에서의 성능 측정이 어려운 이유..
첫째, 일부 부분은 우리가 통제할 수 없다.
우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만
어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다.
우리가 모든 환경을 통제할 수 없으니 정확하게 느려지거나
단절 되는 이유를 알아내기 매우 힘들다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
4. APM 다루기
진짜 우리가 해야 할 것은?
Transaction
SQL SQL
Http
File
Resource
`
Infra 모니터링어플리케이션 모니터링
부하발생기
부하발생기 가상 유저
APM의 핵심은 무수하게 많은 트랜잭션을 잘 분석하는 것
3:04 3:05 3:06 3:07
40초
80초
10초
평균 응답시간 – 과연 최적의 표현??
뉴렐릭, Elastic APM – 사후 분석 , 개발자 관점
AppDynamics - 운영자 중심의 APM
제니퍼 류 (스카우터, 와탭, 튜나)
4. 비공개 노하우 공유
Slow Tx보다는
시간 * 빈도수 = 총합 시간이 많은 Tx를 먼저 시행
장애 스냅샷에 대한 유형 판단 능력을 키워라
A. 수직선
B. 수평선
83
A. 수직선 (Vertical Lining)
하나의 서버에서만 또는 여러 대의 서버에서 동일하게 이러한 상황이 발생
했는지 파악을 해야합니다.
하나의 서버에서만 이러한 현상을 보인다면, 메소드 락(Java Synchronized)
이나 그 애플리케이션 서버만의 문제지만, 여러 대의 애플리케이션 서버에
서 동일하게 이러한 수직 선이 생기면, 외부의 문제로 보셔야 합니다.
대부분 데이터베이스와 연관된 문제로 DB Lock, Connection Pool, 또는 공
유하고 있는 자원의 부족 문제를 의심해 보셔야 합니다.
또는 특정 외부 http call이 제한된 user만 받거나, 제한된 자원을 쓰고 있는
경우에 호출할 때마다 느려지는 경우 이러한 현상을 볼 수 있습니다.
84
B. 수평선 (Horizontal Lining)
특정 시간 만큼 공백을 이루면서 가로로 선이 계속 발생하는 현상 이 그림은 20
시 2분경, 응답시간 12초 정도 쯤에서 에러들이 가로로 일직선을 이루는 모습을
보실 수 있습니다.
이런 현상이 서비스 운영 시 발생한다면 다음과 같은 상황을 의심
1) 자원을 획득하기 위해 반복적으로 재시도 할 때 ­ 동일 트랜잭션(URL)인 경우
자주 발생합니다. 특정 자원을 획득하지 못 해 주기적으로 재시도를 하는 로직을
넣은 경우입니다.
2) 30, 60, 90초 라인이 형성되는 경우 ­ DB Timeout을 의심해 봐야 합니다.
30초의 타임 아웃이 풀려, 일제히 찍히는 경우가 발생합니다.
85
C. 초기화에 의한 일시적인 병목현상
위의 그림은 특정시간에 시스템이 오픈 되고, 다수의 사용자가 대기 상태에 있다
가 동시에 접속을 시도하면서 발생하는 현상입니다. 약 5분 동안 병목 현상을 보
이다가, 서비스가 정상화 되었습니다.
이러한 현상은 수강신청이나 마사회와 같은 특정 시간에 티켓 발급 시 종종 발생
합니다. 사용자의 일순간 급격한 증가가 원인이라면 지속적으로 서비스가 느려
져야 하는데, 몇 분 후 다시 응답이 정상상태로 돌아온 것으로 보아, 초기화 과정
에서 발생한 일시적인 병목이라고 보는 것이 맞습니다.
일반적으로 Java-Web의 초기화 과정 중 주요한 부하 원인들은 다음과 같습니다.
- JSP 컴파일
- Class Loading
- 메뉴/권한 정보 초기화
- DB, 외부 연동 POOL 초기화
하지만 실제는 복합적으로 결과가 나온다.
실제 Tx를 보면
문제를 해결할 수 있을까?
Filter Chain에 걸려 있는 상황이 빈번하다
8
8
메모리 자원 부족으로 인한 Thread (FilterChain) 대기 현상 발생
8000계좌를 초과해서 들어오게 되면,
Thread가 Stuck되는 현상이 발생하여, 전체 유저가 늦어지는 것보다는
적절한 Threadshold를 주어 기존 유저들이라도 쾌적하게 대응하는 것들이 필요함
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
올바른 부하테스트를 위해서는.
Transaction
SQL SQL
Http
File
Resource
`
Infra 모니터링어플리케이션 모니터링
부하발생기
부하발생기 가상 유저
발표 :
모바일 성능 분석 솔루션 : IMQA
자동화 테스트 솔루션 : mTworks 을 전시하고 있으니 많은 참여 바랍니다.
감사합니다.

Weitere ähnliche Inhalte

Was ist angesagt?

서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)수보 김
 
[NDC17] Kubernetes로 개발서버 간단히 찍어내기
[NDC17] Kubernetes로 개발서버 간단히 찍어내기[NDC17] Kubernetes로 개발서버 간단히 찍어내기
[NDC17] Kubernetes로 개발서버 간단히 찍어내기SeungYong Oh
 
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)IMQA
 
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021AWSKRUG - AWS한국사용자모임
 
Performance Testing using Loadrunner
Performance Testingusing LoadrunnerPerformance Testingusing Loadrunner
Performance Testing using Loadrunnerhmfive
 
잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다
잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다
잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다Arawn Park
 
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
 
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기NHN FORWARD
 
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트) 마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트) Amazon Web Services Korea
 
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017Amazon Web Services Korea
 
Web Services Automated Testing via SoapUI Tool
Web Services Automated Testing via SoapUI ToolWeb Services Automated Testing via SoapUI Tool
Web Services Automated Testing via SoapUI ToolSperasoft
 
Fault Tolerance 소프트웨어 패턴
Fault Tolerance 소프트웨어 패턴Fault Tolerance 소프트웨어 패턴
Fault Tolerance 소프트웨어 패턴IMQA
 
[오픈소스컨설팅]J boss6 7_교육자료
[오픈소스컨설팅]J boss6 7_교육자료[오픈소스컨설팅]J boss6 7_교육자료
[오픈소스컨설팅]J boss6 7_교육자료Ji-Woong Choi
 
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)SangIn Choung
 
쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기Brian Hong
 
Fault Tolerance 패턴
Fault Tolerance 패턴 Fault Tolerance 패턴
Fault Tolerance 패턴 YoungSu Son
 
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017Amazon Web Services Korea
 
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
 
쿠버네티스 기반 PaaS 솔루션 - Playce Kube를 소개합니다.
쿠버네티스 기반 PaaS 솔루션 - Playce Kube를 소개합니다.쿠버네티스 기반 PaaS 솔루션 - Playce Kube를 소개합니다.
쿠버네티스 기반 PaaS 솔루션 - Playce Kube를 소개합니다.Open Source Consulting
 
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례if kakao
 

Was ist angesagt? (20)

서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)서버학개론(백엔드 서버 개발자를 위한)
서버학개론(백엔드 서버 개발자를 위한)
 
[NDC17] Kubernetes로 개발서버 간단히 찍어내기
[NDC17] Kubernetes로 개발서버 간단히 찍어내기[NDC17] Kubernetes로 개발서버 간단히 찍어내기
[NDC17] Kubernetes로 개발서버 간단히 찍어내기
 
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)모니터링 영역의 변천사_클라우드, 디지털 경험까지)
모니터링 영역의 변천사_클라우드, 디지털 경험까지)
 
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
Amazon EKS로 간단한 웹 애플리케이션 구축하기 - 김주영 (AWS) :: AWS Community Day Online 2021
 
Performance Testing using Loadrunner
Performance Testingusing LoadrunnerPerformance Testingusing Loadrunner
Performance Testing using Loadrunner
 
잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다
잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다
잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다
 
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개
 
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
[2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
 
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트) 마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
 
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
마이크로서비스를 위한 AWS 아키텍처 패턴 및 모범 사례 - AWS Summit Seoul 2017
 
Web Services Automated Testing via SoapUI Tool
Web Services Automated Testing via SoapUI ToolWeb Services Automated Testing via SoapUI Tool
Web Services Automated Testing via SoapUI Tool
 
Fault Tolerance 소프트웨어 패턴
Fault Tolerance 소프트웨어 패턴Fault Tolerance 소프트웨어 패턴
Fault Tolerance 소프트웨어 패턴
 
[오픈소스컨설팅]J boss6 7_교육자료
[오픈소스컨설팅]J boss6 7_교육자료[오픈소스컨설팅]J boss6 7_교육자료
[오픈소스컨설팅]J boss6 7_교육자료
 
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
[기본과정] 코드 테스트와 커버리지 기본 교육(개념)
 
쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기
 
Fault Tolerance 패턴
Fault Tolerance 패턴 Fault Tolerance 패턴
Fault Tolerance 패턴
 
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
AWS 고객이 주로 겪는 운영 이슈에 대한 해법-AWS Summit Seoul 2017
 
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
 
쿠버네티스 기반 PaaS 솔루션 - Playce Kube를 소개합니다.
쿠버네티스 기반 PaaS 솔루션 - Playce Kube를 소개합니다.쿠버네티스 기반 PaaS 솔루션 - Playce Kube를 소개합니다.
쿠버네티스 기반 PaaS 솔루션 - Playce Kube를 소개합니다.
 
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
 

Ähnlich wie 웹서버 부하테스트 실전 노하우

Performance consulting
Performance consultingPerformance consulting
Performance consultingIMQA
 
[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How ToJi-Woong Choi
 
모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415SeungBeom Ha
 
Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안중선 곽
 
practical perf testing - d2startup
practical perf testing - d2startuppractical perf testing - d2startup
practical perf testing - d2startupJunHo Yoon
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기YoungSu Son
 
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템SeungBeom Ha
 
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)SangIn Choung
 
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2tobeware
 
Apache JMeter로 웹 성능 테스트 방법
Apache JMeter로 웹 성능 테스트 방법Apache JMeter로 웹 성능 테스트 방법
Apache JMeter로 웹 성능 테스트 방법Young D
 
한대희 Web proxy_개발_2006년11월_pas_ktf
한대희 Web proxy_개발_2006년11월_pas_ktf한대희 Web proxy_개발_2006년11월_pas_ktf
한대희 Web proxy_개발_2006년11월_pas_ktfDaehee Han
 
H/W 규모산정기준
H/W 규모산정기준H/W 규모산정기준
H/W 규모산정기준sam Cyberspace
 
Mobile Push Notification Solution
Mobile Push Notification SolutionMobile Push Notification Solution
Mobile Push Notification Solution남익 이
 
AWS Innovate: Mobile App testing with AWS Device Farm- Kevin Kim
AWS Innovate: Mobile App testing with AWS Device Farm- Kevin KimAWS Innovate: Mobile App testing with AWS Device Farm- Kevin Kim
AWS Innovate: Mobile App testing with AWS Device Farm- Kevin KimAmazon Web Services Korea
 
[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
 
Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos uEngine Solutions
 
장애 분석 절차 (서영일)
장애 분석 절차 (서영일)장애 분석 절차 (서영일)
장애 분석 절차 (서영일)WhaTap Labs
 
Final 07.컨테이너 환경에서 모니터링 이슈와 해결 방안
Final 07.컨테이너 환경에서 모니터링 이슈와 해결 방안Final 07.컨테이너 환경에서 모니터링 이슈와 해결 방안
Final 07.컨테이너 환경에서 모니터링 이슈와 해결 방안Opennaru, inc.
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기YoungSu Son
 

Ähnlich wie 웹서버 부하테스트 실전 노하우 (20)

Performance consulting
Performance consultingPerformance consulting
Performance consulting
 
[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To
 
모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415모바일 앱(App) 개발 테스트 솔루션 v20160415
모바일 앱(App) 개발 테스트 솔루션 v20160415
 
Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안
 
practical perf testing - d2startup
practical perf testing - d2startuppractical perf testing - d2startup
practical perf testing - d2startup
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기
 
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
모바일 앱(App) 개발 테스트 솔루션 - 인터링크시스템
 
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)
 
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
투비웨어 AgitarOne Junit 단위테스트자동화 솔루션소개_201608_v1.2
 
Apache JMeter로 웹 성능 테스트 방법
Apache JMeter로 웹 성능 테스트 방법Apache JMeter로 웹 성능 테스트 방법
Apache JMeter로 웹 성능 테스트 방법
 
한대희 Web proxy_개발_2006년11월_pas_ktf
한대희 Web proxy_개발_2006년11월_pas_ktf한대희 Web proxy_개발_2006년11월_pas_ktf
한대희 Web proxy_개발_2006년11월_pas_ktf
 
H/W 규모산정기준
H/W 규모산정기준H/W 규모산정기준
H/W 규모산정기준
 
Mobile Push Notification Solution
Mobile Push Notification SolutionMobile Push Notification Solution
Mobile Push Notification Solution
 
AWS Innovate: Mobile App testing with AWS Device Farm- Kevin Kim
AWS Innovate: Mobile App testing with AWS Device Farm- Kevin KimAWS Innovate: Mobile App testing with AWS Device Farm- Kevin Kim
AWS Innovate: Mobile App testing with AWS Device Farm- Kevin Kim
 
Performance test
Performance testPerformance test
Performance test
 
[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 클라우드 성능 모니터링
 
Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos
 
장애 분석 절차 (서영일)
장애 분석 절차 (서영일)장애 분석 절차 (서영일)
장애 분석 절차 (서영일)
 
Final 07.컨테이너 환경에서 모니터링 이슈와 해결 방안
Final 07.컨테이너 환경에서 모니터링 이슈와 해결 방안Final 07.컨테이너 환경에서 모니터링 이슈와 해결 방안
Final 07.컨테이너 환경에서 모니터링 이슈와 해결 방안
 
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
클라우드 & 모바일 환경에서 알아야 할 성능 품질 이야기
 

Mehr von IMQA

[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?IMQA
 
실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기실 사례로 보는 고객 디지털 경험 지키기
실 사례로 보는 고객 디지털 경험 지키기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 RallyIMQA
 
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, FRVTIMQA
 
인공지능 식별추적시스템 성능 검증 평가 사례
인공지능 식별추적시스템 성능 검증 평가 사례 인공지능 식별추적시스템 성능 검증 평가 사례
인공지능 식별추적시스템 성능 검증 평가 사례 IMQA
 
Introduction of IMQA MPM Solution
Introduction of IMQA MPM SolutionIntroduction of IMQA MPM Solution
Introduction of IMQA MPM SolutionIMQA
 
확장가능한 웹 아키텍쳐 구축 방안
확장가능한 웹 아키텍쳐 구축 방안 확장가능한 웹 아키텍쳐 구축 방안
확장가능한 웹 아키텍쳐 구축 방안 IMQA
 

Mehr von IMQA (8)

[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?[IMQA] 빠른 웹페이지 만들기 - 당신의 웹페이지는 몇 점인가요?
[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
 
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
 
확장가능한 웹 아키텍쳐 구축 방안
확장가능한 웹 아키텍쳐 구축 방안 확장가능한 웹 아키텍쳐 구축 방안
확장가능한 웹 아키텍쳐 구축 방안
 

웹서버 부하테스트 실전 노하우

  • 1. 실전 서버 부하 테스트 노하우 손영수, 차용빈 ysson@onycom.com 어니컴 성능솔루션 사업부
  • 2. 발표에 앞서 어니컴은 마사회, 대기업 입사 지원 시스템, 글로벌 제약회사, ERP등 다양한 업체의 부하 성능 테스트및 컨설팅을 한 경험을 가진 회사입니다. 이 자료는 부하 테스트 / 성능 측정 노하우를 공유하는 자료입니다. (https://www.facebook.com/imqa.io 에서 자료 공개 예정) 모든 저작권은 어니컴에 있음을 알려 드리며, 원본 출처를 공개하는 조건에서 재 배포를 허락합니다.
  • 3. 0. 개요 그리고 오해 풀기..
  • 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 사용하기) • 서버의 자원은 충분한가? (서버 모니터링 - 성능 지표 읽기) • 고급 주제 • 테스트를 현실적으로 잘 할려면 어떻게 해야 하는가? (테스트 계획안) • 테스트에 필요한 요청사항들은? (어떠한 데이터를 수집해야 하나?) • 클라우드 사용시 주의해야 할 것들은? (클라우드의 함정)
  • 10. 성능 테스팅이란? • 목적 시스템의 병목 지점을 찾는 것!
  • 11. 성능 테스트 정의 • 정의 : 특정 부하에서 응답성 및 안정성 측면에서, 시스템이 어떻게 동작 하는지, 측정하기 위한 비 기능 테스트입니다. • 얻을 수 있는 것들 : 확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성 을 조사, 측정, 검증 또는 검증 할 수 있습니다
  • 12. 성능 테스트의 종류 부하 / 용량 산정 테스팅 Load/Capacity Testing 스트레스 테스팅 Stress Testing 내구성 테스트 Endurance/Soak Testing 최고점 부하 테스트 Spike Testing
  • 14. 1. JMeter 다루기 7일안에 Jmeter 끝내기 : https://www.guru99.com/jmeter-tutorials.html Blazemeter Jmeter 무료 Webcast : https://www.blazemeter.com/jmeter/ ONYCOM 방문 강좌 : 직원 1명당 10만원 (최소 강좌 100만원부터 시작)
  • 15. 2. 성능 부하 테스트 안
  • 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 고객 서비스 고객 서비스
  • 20. 컨트 롤러 스크 립트 에이전트 에이전트 프로세스 프로세스 쓰레드 1 쓰레드 2 쓰레드 3 쓰레드 4 쓰레드 5 쓰레드 6 USER USER USER USER USER USER 프로세스 프로세스 20 참고. 부하 발생 구조
  • 21. • 1안) 사용 상황에 맞는 시나리오 수립 후 테스트 (배포전) • 가입 / 수강 / 결재 시나리오 • 딜 종료 후, 결과 확인 시나리오 • 딜 정보 확인 및 배당률 확인 시나리오 • 2안) 사용자로 부터 HTTP(S) 요청을 추출해서 시나리오 산정 (APM 사용) • 내부 APM 연동 후 데이터 수집. (상용, 오픈소스, 유료 15일) • 가능하다면 베타 그룹, 크라우드 테스트를 통해 데이터 수집 할 것을 추천 21 2. 테스트 시나리오 보완 방법 논의
  • 22. • 고객별 시나리오 도출 • 예) • 경우1_ 5분전에 구매를 완료하는 사용자 비율 • 선 구매 이후 ­> 반복되는 실시간 배당율 확인 • 경우2_ 30~10 초 전에 구매를 완료하는 사용자 비율 • 실시간 배당율 확인 및 실시간 배팅 정보구매 22 1안) 실제 사용 상황에 맞는 시나리오에 대한 테스트
  • 23. 시나리오를 완벽하게 도출하기 위해서 협의 필요
  • 24. Blazemeter : Jmeter 스크립트 생성 도구(크롬 플러그인) 스크립트 녹화 녹화된 스크립트 편집 다양한 포멧으로 저장
  • 25. 25 2안) APM의 결과를 추출해서 시나리오 산정 경기 시간 기준, 주요 트랜잭션 분포를 통한 시나리오 산정
  • 26. • 주요 시나리오 테스트 (Warm-Up 테스트) • 주요 시나리오 선정 후 (가입 , 강좌 수강등) 시나리오별로 얼마나 견디는지 테스트 • • 트랜잭션별 단위 테스트 (Warm-Up 테스트) • Top 20에 대한 트랜잭션에 대해서 얼마나 견디는지 테스트 • 주요 시나리오 가중치 테스트 (시나리오 별 가중치 테스트, Warm-Up 테스트) • 위 선정된 주요 시나리오에 가중치를 부여 하여 테스트 • 예 ) A 시나리오 30%, B 시나리오 20%, C 시나리오 50% 26 3. 부하 테스트 진행 방향
  • 27. 27 3.1. Warm-Up 테스트 진행 (기준 정하기)
  • 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
  • 40. 7.1. JMeter Controller 설정 40 remote_hosts=10.0.0.2,10.0.0.3,...,10.0.0.n
  • 41. 통신 포트 설정 변경 41
  • 42. 통신 포트 설정 변경 42 jmeter-server 설정 server_port=2099 server.rmi.localport=4000 jmeter controller 설정 remote_hosts=10.0.0.2:2099 client.rmi.localport=4001
  • 43. 8. 테스트 시 주의 사항 43
  • 44. 44 Jmeter + Google Cloud 관련 프로젝트 링크 - https://bit.ly/2AVq0pk X 권장 OS : OS X, Linux 단 바로 작동하지 않음. 요즘 Google Cloud 관련 API를 변경 및 추가 후 사용할 수 있음. 중급 기준 : 1달 정도 추가 개발 필요.
  • 45. 1) 버킷 생성하기 45 Console 화면에서 Storage 페이지로 이동한다
  • 46. 1) 버킷 생성하기 46 Storage 버킷을 만듭니다. 버킷 이름은 원하든 대로 입력을 해주시고, 만들기 버튼을 누른다. gcp_upload_files 폴더에 있는 내용을 전체 올려줍니다
  • 47. 1) 버킷 생성하기 47 Jmeter-server 파일을 올려줍니다
  • 48. 2) 구글 클라우드 플랫폼 인증 설정 4 8 구글 클라우드 플랫폼에 스크립트가 접근하기 위해서는 API 사용자 인증이 필요하다. 그림과 같이 API 및 서비스 메뉴로 접근한다
  • 49. 2) 구글 클라우드 플랫폼 인증 설정 4 9 API 및 서비스 메뉴에서 사용자 인증 정보 탭으로 이동한다
  • 50. 2) 구글 클라우드 플랫폼 인증 설정 5 0 OAuth 동의 화면 탭으로 이동하여, 애플리케이션 이름 부분에 원하는 이름을 적은 후 저장한다
  • 51. 2) 구글 클라우드 플랫폼 인증 설정 5 1 사용자 인증 정보 탭으로 다시 이동하여, 사용자 인증 정보를 만든다. 이때 OAuth 클라이언트 ID를 선택한다
  • 52. 2) 구글 클라우드 플랫폼 인증 설정 5 2 기타를 선택한 후 원하는 이름을 적어 클라이언트 ID 를 만든다
  • 53. 2) 구글 클라우드 플랫폼 인증 설정 5 3 클라이언트 ID와 클라이언트 보안 비밀은 따로 저장을 해 두십시오. 스크립트에서 사용이 됩니다. 설정이 이 페이지에서 다시 확인 할 수 있다
  • 54. 4) 스크립트 실행 방법 5 4 # JMETER 인스턴스 생성하기 (PREFIX에 구분할 수 있는 접두어 설정) (NUMBER에 생성하고 싶은 인스턴스 갯수) ./jmeter_cluster.py start --prefix <PREFIX> <NUMBER> # JMETER 서버들 종료하고 반납하기 ./jmeter_cluster.py shutdown --prefix <PREFIX> # JMETER 클라이언트를 실행 방법 ./jmeter_cluster.py client
  • 55. 3. 서버 성능 분석하기
  • 56. 진짜 우리가 해야 할 것은? Transaction SQL SQL Http File Resource ` Infra 모니터링어플리케이션 모니터링 부하발생기 부하발생기 가상 유저
  • 57. 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
  • 61. USE 메소드의 예. Resource Utilization Saturation Errors CPU mpstat-PALL1, sumnon-idlefields vmstat1,"r" perf Memory Capacity free­m,"used"/"total" vmstat1,"si"+"so"; demsg|grepkilled dmesg StorageI/O iostat­xz1, "%util" iostat­xnz1, "avgqu-sz">1 /sys/…/ioerr_cnt; smartctl Network nicstat,"%Util" ifconfig,"overrunns"; netstat­s"retrans…" ifconfig, "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
  • 63. 2) 고객이 클라우드를 사용한다면..
  • 65. 클라우드는 공유 자원.. 요청이 많으면 즉 내 차례를 기다리거나..
  • 66. 클라우드는 공유 자원.. 상황에 맞게 제한된 자원을 나눠가지던가..
  • 68. IOPS가 높을때 마다, Disk Queue Length가 높은 수치로 증가 -> 클라우 드에선 늘 발생할 수 있는 문제.. 몇몇 존에 있는 서버만 IOPS가 250으로 항상 일정 알고보니 자원의 제약..
  • 69. 해결책.. 만약 A사 (AM?, AZ?) 제품이면 제값 주고 Provisioned IOPS 구입!
  • 70. 해결책.. 만약 A사 (AM?, AZ?) 제품이면 제값 주고 Premium Storage Disk 구입!
  • 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
  • 74. 진짜 우리가 해야 할 것은? Transaction SQL SQL Http File Resource ` Infra 모니터링어플리케이션 모니터링 부하발생기 부하발생기 가상 유저
  • 75. APM의 핵심은 무수하게 많은 트랜잭션을 잘 분석하는 것 3:04 3:05 3:06 3:07 40초 80초 10초
  • 76. 평균 응답시간 – 과연 최적의 표현??
  • 77. 뉴렐릭, Elastic APM – 사후 분석 , 개발자 관점
  • 78. AppDynamics - 운영자 중심의 APM
  • 79. 제니퍼 류 (스카우터, 와탭, 튜나)
  • 81. Slow Tx보다는 시간 * 빈도수 = 총합 시간이 많은 Tx를 먼저 시행
  • 82. 장애 스냅샷에 대한 유형 판단 능력을 키워라 A. 수직선 B. 수평선
  • 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 초기화
  • 86. 하지만 실제는 복합적으로 결과가 나온다. 실제 Tx를 보면 문제를 해결할 수 있을까?
  • 87. Filter Chain에 걸려 있는 상황이 빈번하다
  • 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
  • 90. 올바른 부하테스트를 위해서는. Transaction SQL SQL Http File Resource ` Infra 모니터링어플리케이션 모니터링 부하발생기 부하발생기 가상 유저
  • 91. 발표 : 모바일 성능 분석 솔루션 : IMQA 자동화 테스트 솔루션 : mTworks 을 전시하고 있으니 많은 참여 바랍니다.