Site icon GRIP.News

JMeter와 nmon 을 이용한 시스템/서비스 테스트 #1 / 환경만들기

grip.news

2015년 10월 19일에 작성된 포스트 입니다.

솔루션을 만들 때 어느 정도의 처리를 ‘원활히’ 처리할 수 있고 어느 정도면 ‘사용할만’ 하며, 어느 정도에서 실패 상태로 가는지 알아야 한다. 이를 알기 위해선 테스트가 필요한데, 주어진 환경에서 RESTFul API 를 얼마나 원활하게 처리할 수 있는지 확인하는 방법을 간단히 알아보자.

우선 “테스트”를 간단히 알아보자. 말 그대로 만든 것이 문제가 없는지 확인하는 것으로 큰 범주에서는 부하 테스트(Load-test)와 특이점 테스트(Singularity-test)로 나뉘며 주로 테스트라 함은 전자인 부하 테스트에 한정된다.

‘부하 테스트(Load-test)’와 ‘스트레스 테스트(Stress-test)’를 혼동하는 경우가 적지 않은데 물론 설명하고자 하는 사람에 따라 차이가 있다. 본인 생각에선 인프라-솔류션 관점에서 부하 테스트는 스트레스 테스트, 성능 테스트 그리고 신뢰도 테스트가 포함된다 보고 있다. 이를 간단히 다시 풀어서 설명하자면 다음과 같다.

스트레스 테스트(Stress-test)

사용자가 발생 시킨 EVENT를 처리하기 위해 실행되는 서버에서 실행된 애플리케이션 실행 시 필요로 하는 각종 리소스(CPU/RAM/IO 등)의 허용 한도를 넘어서서 비 정상적인 높은 부하를 발생 시킨다. 일정 한도를 넘어서는 부하 상황이 되면 경우에 따라 애플리케이션이 다운되거나 데이터를 유실 하는 등의 비 정상적 작동을 유발 시킴으로써 결점과 결함을 찾는다.

성능테스트(Performance Test)

부하 테스트 항목 중 성능 측면만 검토한다. 시스템 및 애플리케이션의 성능은 점진적인 부하 증가 과정에 더 이상 단위 시간 당 최대 처리량(TPS)이 증가하지 않는 시점을 찾음으로서 주어진 조건에서 최대 수용 가능 한 동시 트랜잭션을 확인한다.

신뢰도 테스트 (Reliability Test)

악화된 환경 및 조건에서 시스템 및 어플리케이션으로의 요청이 얼마나 안정적으로 처리되는지 검토한다.처리에 대한 성공 및 실패를 검토하고 시스템 장애 시 정상적으로 대응이 가능한지 확인한다

모든 테스트는 일정기간 이상(장시간), 다양한 환경과 방법으로 진행해야 하는것이 일반적. 물론 지금은 그 방법만 전하고자 하니 테스트 방법 자체만 확인하도록 한다.

테스트 환경

  1. AWS t2.micro (TOKYO)
  2. Ubuntu Server 14.04 LTS
  3. nginx + flask (uwsgi)

테스트 주제

  1. nginx + flask 로 RESTFul API 를 만든다.
  2. 얼마나 많은 Transaction 을 처리할 수 있는가?

테스트 툴

  1. Apache Group jmeter (Client Test Tool)
  2. IBM nmon (Server Monitoring Tool)

최근 Server/Client 상호 통신 방식으로 동기화 형태에서 가장 많이 쓰이는 건 HTTP기반 RESTFul 이다. 저렴하고 자그마한 t2.micro에 apt-get 을 통해 nginx 와 flask를 설치하고, 가장 간단한 RESTFul API 를 하나 만든다. 조건은 데이터 형태는 jSON 으로 주어지며 timer 값에 따라 sleep 를 준다.

 

테스트 환경 만들기


후다닥 테스트를 위한 EC2 를 만들고, Elastic IP 를 부여한다.

sudo apt-get update
sudo apt-get upgrade
sudo sync
sudo reboot

패키지와 라이브러리를 최신의 것으로 업데이트 해 준다. 그리고 nginx 와 flask 설치.

sudo su
apt-get install nginx python-virtualenv
pip install flask

nginx 와 flask 를 설치하고 연결해 주면 끝.

대략 700MBytes 의 메모리의 여분이 남아있다.

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping : 4
microcode : 0x428
cpu MHz : 2494.044
cache size : 25600 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips : 4988.08
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

cpuinfo 에 따르면 E5-2670 v2 @ 2.50GHz 이지만 실제 이 CPU 성능의 1/10 도 나오지 않는다. Cloud 환경으로 오면서 가장 먼저 의미 없는 수치로 전락해 버린 bogomips. 마지막으로 RESTFul API 가 정상적으로 응답하는지 확인만 하면 된다.

 

서버 모니터링 툴 설치하기

Client 요청이 발생했을 때 Latency 등으로 Condition 을 감지할 수 있지만 정확한 서버 상태를 인지하기 어렵다. AWS 환경에서는 Cloud Watch를 기본으로 제공하나 자세하지 않고, Zabbix 의 경우 주기가 길며 리소스를 많이(?) 사용한다. 이러한 이유에서 추천하는 툴은 IBM 의 nmon.

Nigel’s performance Monitor for Linux 로 IBM AIX 테스트 툴로 시스템의 전반적인 상태 모니터링이 가능하고, 백그라운드로 동작해도 차지하는 리소스가 크지 않다. 더욱이, 결과물을 엑셀 차트로 쉽게 변환이 가능한 장점이 있다.

Freeware의 Tool 은 선택의 폭이 넓지 않다. 노가다로 뛴다면 top, iptraf, uptime 등으로 CPU / MEMORY / NETWORK / LOAD 를 확인할 수 있지만 사용성이 떨어지고 몇몇 제품은 설치가 귀찮다.

sudo apt-get install nmon

nmon 설치는 apt-get 으로 쉽게 설치가 가능하다. (CentOS 는 yum 으로 설치 가능) nmon 은 2가지 방법으로 동작한다. Text graphic UI 로 변화하는 값을 초단위로 모니터링이 가능하며, 백그라운드로 로그를 남길 수있다. 로그 파일은 csv 로 변환해 엑셀에서 차트로 확인할 수 있다.

 

클라이언트 테스트 툴 설치

규모가 있는 회사는 전문적인 테스트 툴을 도입해야 한다. 테스트 툴은 성능도 중요하지만 지원이 필수이므로 (커스터마이징/오류 때문) HP 의 Loadrunner 가 가장 많이 사용된다. 하지만 비.싸.다. Naver 의 grinder 기반 ngrinder 가 있지만 스크립트를 수정해야 하기 때문에 귀찮다. 단순한 웹 서버 성능 테스트라면 ab(apache bench)가 있지만 테스트 결과가 너무 2차원적이라 ‘정도’만 확인 가능하기에 동일한 Apache Group 에서 만든 JMeter 를 많이 사용하고, 이글에서도 이 툴을 설명하고자 한다.

컴퓨터에 JDK가 설치되어 있는 상태에서 상기 URL 의 zip 파일을 받아 압축을 푼다. 그리고 /bin 폴더에 위치한 jmeter.bat 을 실행한다.

테스트하고자 하는 시스템의 조건은 복잡하지 않다. 일반 컴퓨터에 무난한 네트워크(가정집 정도의)만 있으면 된다. ‘대용량’의 파일 또는 ‘논리 로직’이 복잡하게 들어간 경우라면 시스템이 좋아야 겠지만 이번 테스트 목적에서는 Transaction 만 확인할 것이기 때문. 우린 이제 다음의 테스트를 진행할 수 있게 되었다.

  1. Performance Test
    CPU / Memory / IO 중 70% 또는 WEB/WAS 의 이상적 응답성을 벗어나기 이전의 최대 Connection (TPS)
  2. Stress Test
    CPU / Memory / IO 중 100% 를 넘어서도 그 이상의 Request 를 발생시켜 서버의 어플리케이션 어느 하나라도죽었을 때 허용했던 최대Connection
  3. Reliability Test
    직접 테스트는 안해 보겠지만 정리 정도.
Exit mobile version