1. 실전 서버 부하 테스트 노하우
손영수, 차용빈
ysson@onycom.com
어니컴 성능솔루션 사업부
2. 발표에 앞서
어니컴은
마사회, 대기업 입사 지원 시스템, 글로벌 제약회사, ERP등
다양한 업체의 부하 성능 테스트및 컨설팅을 한 경험을 가진 회사입니다.
이 자료는 부하 테스트 / 성능 측정 노하우를 공유하는 자료입니다.
(https://www.facebook.com/imqa.io 에서 자료 공개 예정)
모든 저작권은 어니컴에 있음을 알려 드리며,
원본 출처를 공개하는 조건에서 재 배포를 허락합니다.
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 사용하기)
• 서버의 자원은 충분한가? (서버 모니터링 - 성능 지표 읽기)
• 고급 주제
• 테스트를 현실적으로 잘 할려면 어떻게 해야 하는가? (테스트 계획안)
• 테스트에 필요한 요청사항들은? (어떠한 데이터를 수집해야 하나?)
• 클라우드 사용시 주의해야 할 것들은? (클라우드의 함정)
11. 성능 테스트 정의
• 정의 :
특정 부하에서 응답성 및 안정성 측면에서, 시스템이 어떻게 동작
하는지, 측정하기 위한 비 기능 테스트입니다.
• 얻을 수 있는 것들 :
확장성, 신뢰성 및 리소스 사용과 같은 시스템의 다른 품질 속성
을 조사, 측정, 검증 또는 검증 할 수 있습니다
12. 성능 테스트의 종류
부하 / 용량 산정 테스팅
Load/Capacity Testing
스트레스 테스팅
Stress Testing
내구성 테스트
Endurance/Soak Testing
최고점 부하 테스트
Spike Testing
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
고객
서비스
고객
서비스
21. • 1안) 사용 상황에 맞는 시나리오 수립 후 테스트 (배포전)
• 가입 / 수강 / 결재 시나리오
• 딜 종료 후, 결과 확인 시나리오
• 딜 정보 확인 및 배당률 확인 시나리오
• 2안) 사용자로 부터 HTTP(S) 요청을 추출해서 시나리오 산정 (APM 사용)
• 내부 APM 연동 후 데이터 수집. (상용, 오픈소스, 유료 15일)
• 가능하다면 베타 그룹, 크라우드 테스트를 통해 데이터 수집 할 것을 추천
21
2. 테스트 시나리오 보완 방법 논의
22. • 고객별 시나리오 도출
• 예)
• 경우1_ 5분전에 구매를 완료하는 사용자 비율
• 선 구매 이후 > 반복되는 실시간 배당율 확인
• 경우2_ 30~10 초 전에 구매를 완료하는 사용자 비율
• 실시간 배당율 확인 및 실시간 배팅 정보구매
22
1안) 실제 사용 상황에 맞는 시나리오에 대한 테스트
25. 25
2안) APM의 결과를 추출해서 시나리오 산정
경기 시간 기준, 주요 트랜잭션 분포를 통한 시나리오 산정
26. • 주요 시나리오 테스트 (Warm-Up 테스트)
• 주요 시나리오 선정 후 (가입 , 강좌 수강등) 시나리오별로 얼마나 견디는지 테스트
•
• 트랜잭션별 단위 테스트 (Warm-Up 테스트)
• Top 20에 대한 트랜잭션에 대해서 얼마나 견디는지 테스트
• 주요 시나리오 가중치 테스트 (시나리오 별 가중치 테스트, Warm-Up 테스트)
• 위 선정된 주요 시나리오에 가중치를 부여 하여 테스트
• 예 ) A 시나리오 30%, B 시나리오 20%, C 시나리오 50%
26
3. 부하 테스트 진행 방향
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
42. 통신 포트 설정 변경
42
jmeter-server 설정
server_port=2099
server.rmi.localport=4000
jmeter controller 설정
remote_hosts=10.0.0.2:2099
client.rmi.localport=4001
44. 44
Jmeter + Google Cloud 관련 프로젝트 링크 - https://bit.ly/2AVq0pk
X
권장 OS : OS X, Linux
단 바로 작동하지 않음.
요즘 Google Cloud 관련 API를 변경 및 추가 후 사용할 수 있음.
중급 기준 : 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
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
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
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 초기화
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