오래전 이야기/Performance Test

사람을 위한 자동화: 전혀 귀찮지 않은 로드 테스팅

리눅스 엔지니어였던 2009. 1. 28. 15:46

아파치 JMeter와 아파치 Ant를 사용하여 로드 테스트를 자주 실행하자

developerWorks
문서 옵션
수평출력으로 설정

이 페이지 출력

이 페이지를 이메일로 보내기

이 페이지를 이메일로 보내기

샘플 코드

영어원문

영어원문


제안 및 의견
피드백

난이도 : 초급

Paul Duvall, CTO, Stelligent Incorporated

옮긴이: 백기선 dwkorea@kr.ibm.com

2008 년 6 월 17 일

로드 테스팅은 보통 개발 주기 후반부 활동으로 취급됩니다. 하지만 실제로는 그럴 필요가 없습니다. 사람을 위한 자동화 연재의 이번 회에서는, 자동화 전문가 Paul Duvall이 주기적으로 JMeter 테스트를 실행하는 통합 빌드 작성을 통해 개발 주기를 통해 문제를 발견하고 고치는 방법을 설명할 것입니다.

얼마나 많은 사용자가 동시에 여러분의 소프트웨어 시스템에 접속할 수 있는가? 성능 저하 없이 얼마나 많은 데이터를 로딩할 수 있는가? 시스템 작업량은 얼마나 되는가? 이런 요구사항들을 얼마나 자주 테스트하는가? 만약 여러분이 이러한 읽기와 성능 요구사항에 대해 최소한 하루에 한 번 기술할 수 있고 검증할 수 있다면 어떨 것 같은가? 로드 테스트를 정기적이고 자동화된 빌드의 일부로 만듬으로써, 특정 로드 조건에서 시스템 성능을 신속하게 판별할 수 있고 변화를 빠르게 수용할 수 있다.

본 연재에 대해

개발자로서, 우리는 고객의 프로세스를 자동화하기 위해 일한다. 하지만, 우리 대부분은 스스로의 개발 프로세스를 자동화할 수 있는 기회를 간과하곤 한다. 더 이상 그러지 않기 위해, 사람을 위한 자동화 연재를 기획하여 소프트웨어 개발 프로세스를 자동화하는 실용적인 사용법들과 자동화를 언제, 어떻게 성공적으로 적용하는지 설명하겠다.

필 자가 일했던 곳에서 다수의 트랜잭션으로 동작하는 애플리케이션 로드 테스트를 할 수 있는 자동화된 테스트 집합을 마련한 적이 있다. 문제는 테스트들이 약간의 수동 조작을 필요로 했다. 따라서 개발팀은 사람이 개입하지 않으면 그것들을 실행할 수 없었다. 이로 인해 테스트 작업은 테스터가 참여할 수 있는 시간으로 제한되었다(보통 업무 시간에만 가용하다). 실제로, 테스트 작업은 일과 중 몇 번만 진행되었다. 매 시간 발생하는 문제를 찾아내기에는 부족했다.

이번 기사에서는 JMeter를 사용하는 자동화된 테스트 작성 기술, 자동화 빌드 일부로 해당 테스트 실행, 매일 자동으로 테스트를 실행하도록 스케쥴링하기(컴퓨터의 사용량이 낮을 때 실행하도록)를 설명할 것이다. 테스트를 일정 주기 빌드의 일부로 실행하는 것은 다음과 같은 장점을 준다.

  • 언제든지 로드 테스트를 실행할 수 있다.
  • 개발 프로세스 초기에 로드와 성능 문제를 발견하고 해결할 수 있다.
  • 빌드 서버에서 최신 성능/로드 테스트를 모니터링할 수 있다.
  • 테스트를 설정하고 실행하는 데 한 사람에게 의존할 때 생길지도 모르는 병목과 오류를 줄인다.

JMeter가 무거운 짐을 옮기도록 놔두기

아파치 JMeter는 오픈 소스 프로젝트로 서버에 상당량의 부하를 시뮬레이션하는 데 사용할 수 있다(JMember에 대한 자세한 내용은 참고자료를 참조). JMeter의 방대한 문서에서는 많은 기능을 어떻게 사용하는지 설명하고 있으며 많은 예제를 보여주고 있다.

JMeter 실행하기

JMeter ZIP 파일(JMeter 다운로드 링크는 참고자료를 보라)을 다운로드하고 압축을 푼 다음, 커맨드 창을 열고 JMeter 압축을 푼 곳에서 cd bin을 입력하여 bin 디렉터리로 이동한다. bin 디렉터리에서, jmeter를 입력하여 JMeter 스윙 애플리케이션을 열면 그림 1과 같은 것을 볼 수 있다.


그림 1. JMeter GUI
테스트 계획을 세우기 위해 JMeter GUI 사용하기

테스트 계획 세우기

예제를 사용하여 테스트 작성하기

JMeter 는 많은 예제 계획과 스크립트들을 포함하고 있다. 처음부터 새로 테스트 계획을 세우지 말고 docs 디렉터리에 있는 예제를 이용해 프로젝트가 진행되는 것에 따라 테스트 계획을 점진적으로 구성하라. 부하와 성능 요구사항을 효과적으로 확인할 수 있는 테스트를 작성하는 데에는 학습이 많이 필요하다.

JMeter GUI를 사용해 테스트 계획을 작성할 수 있다. 다음과 같은 종류의 테스트 계획들이 JMeter에 포함되어 있다.

  • 웹 테스트 계획
  • 데이터베이스 테스트 계획
  • FTP 테스트 계획
  • LDAP 테스트 계획
  • Extended LDAP 테스트 계획
  • 웹 서비스 테스트 계획
  • JMS 점대점 방식 테스트 계획
  • JMS 토픽 방식 테스트 계획
  • 모니터링 테스트 계획
  • 리스너

각 각의 테스트 계획은 XML 파일 형태로 .jms 확장자로 저장된다. 이렇게 바이너리가 아닌 포맷이기 때문에 나중에 계획을 편하게 바꿀 수 있다. JMeter의 XML 스키마를 따라 테스트 계획을 생성할 수도 있지만, GUI를 사용하면 작업이 훨씬 수월하다. 뒤에서, JMeter 설정 값을 매개변수화해 테스트를 실행하는 방법을 커스터마이징하는 예제를 살펴볼 것이다.




위로


인건비를 절약하는 로드 테스트

테스트를 실행할 때 GUI를 사용하려면, 그것을 실행할 사람이 반드시 있어야 한다. 이로 인해, 병목 현상과 지식 편중을 야기할 수 있다. 테스트를 앤트(Ant) 빌드와 같이 자동화된 빌드를 통해 실행하면, JMeter 애플리케이션을 실행하지 않고도 JMeter 테스트를 실행할 수 있다. 더욱이, 매번 테스트를 똑같이 수행할 것이며 추가 작업 수당도 지불할 필요가 없다.

앤트를 사용하여 JMeter 테스트 다루기

필 자가 GUI 소프트웨어 도구 사용법을 익혔을 때, 커맨드 라인에서 실행할 수 있는 어떤 유틸리티가 없는지 살펴보길 좋아했다. 같은 동작을 반복해서 하기 싫었기 때문이다. 예를 들어, 필자는 매번 JMeter 애플리케이션을 열고, File > Open을 선택하고, 파일을 열고, 하나 또는 그 이상의 테스트들을 실행한다. 필자는 이 행위들을 스크립트로 만들어 매번 같은 방법으로 실행한다. 운이 좋게도, 앤트 태스크가 JMeter를 대신하여 이런 다양한 일을 해준다. 부가적인 매개변수와 프로퍼티들을 넘겨줄 수 있음과 동시에 로드 테스트들을 실행한다.

예제 빌드 스크립트

JMeter 배포판의 extras 디렉터리에는 build.xml 예제 빌드 스크립트가 들어있다. 여기에 보면 JMeter 앤트 태스크를 사용하는 예제들이 들어 있다.

Listing 1에서, 필자는 앤트의 taskdef를 사용하여 JMeter 태스크를 정의했다. 그 이름을 jmeter라고 지었고 이를 앤트 스크립트 어디서든 참조할 수 있다. 이 스크립트를 사용하려면 반드시 ant-jmeter.jar 파일(참고자료에서 다운로드 링크 참조)을 앤트 클래스패스에 추가해야 한다.


Listing 1. 앤트에 JMeter 태스크 정의하기
<taskdef name="jmeter" classname="org.programmerplanet.ant.taskdefs.jmeter.JMeterTask"/>

Listing 2에 있는 예제 코드는 단일 BreweryTestPlan.jmx라는 JMeter 로드 테스트를 실행한다. 특정 디렉터리에 있는 모든 테스트를 실행하려면, 특정 파일 이름 대신에 간단하게 *.jmx라고 입력하면 된다. jmeter 태스크가 필요로 하는 속성들은 jmeterhome, testplan(s), 또는 resultlogresultlogdir이다(Listing 2에서는 resultlogdir이 보이지 않는데, resultlog를 사용했기 때문이다).


Listing 2. 앤트에서 JMeter 실행하기
<jmeter
  jmeterhome="${jmeter.home}"
  resultlog="${basedir}/target/JMeterResults.xml">
  <testplans dir="${basedir}/tests/load" includes="BreweryTestPlan.jmx"/>
</jmeter>

Listing 2에 있는 앤트 코드는 JMeterResults.xml이라는 결과물 파일을 생성하고 그 파일은 HTML 보고서를 만들 때 사용된다.

XSLT를 사용하여 보고서 렌더링하기

Listing 3처럼 JMeterResult.xml 파일을 xslt 앤트 태스크에 넣어주면, Listing 2에서 실행한 모든 JMeter 테스트에 대한 HTML 보고서를 생성할 수 있다. XSL 스타일 시트(jmeter-result-detail-report_21.xsl)는 JMeter의 extras 디렉터리에 있으며 JMeterResults 파일을 HTML 파일로 변환할 때 사용한다.


Listing 3. XSLT를 사용하여 JMeter HTML 보고서 생성하기
<xslt in="${basedir}/target/JMeterResults.xml"
  out="${basedir}/target/JMeterResults.html"
  style="${jmeter.home}/extras/jmeter-results-detail-report_21.xsl"/>

JMeter는 또한 로드 테스트들의 결과를 종합하여 보여주는 XSL 스타일시트 파일도 제공한다.

HTML로 보고서 살펴보기

그림 2는 Listing 3의 xslt 태스크를 사용하여 생성한 HTML 보고서 예제다. 각각 실행한 로드 테스트와 함께 테스트 상태, 시간 그리고 모든 테스트의 상태와 시간을 묶어 보여준다.


그림 2. JMeter HTML 보고서 생성하기
JMeter HTML 보고서 생성하기

본 기사의 뒤에서, 이 보고서들을 어떻게 CruiseControl Continuous Integration(CI) 서버(참고자료 참조)에서 볼 수 있는지 설명할 것이다.

JMeter에 매개변수 넘기기

실 행하는 테스트의 종류에 따라, 매개변수와 프로퍼티를 넘겨 단일 테스트나 테스트 묶음을 다양한 방법으로 실행하고 싶을 것이다. 예를 들어, Listing 4는 JVM 메모리를 늘리는 방법과 순회할 스레드 개수를 설정하는 방법을 보여준다.


Listing 4. 부가적인 매개변수와 프로퍼티를 JMeter에 넘겨주기
<jmeter
  jmeterhome="${jmeter.home}"
  resultlog="${basedir}/target/JMeterResults.xml">
  <jvmarg value="-Xincgc"/>
  <jvmarg value="-Xmx128m"/>
  <jvmarg value="-Dproperty=value"/>
  <property name="request.threads" value="5"/>
  <property name="request.loop" value="50"/>
  <property name="jmeter.save.saveservice.assertion_results" value="all"/>
  <property name="jmeter.save.saveservice.output_format" value="xml"/>
  <testplans dir="${basedir}/tests/load" includes="BreweryTestPlan.jmx"/>
</jmeter>

JMeter가 테스트를 어떻게 실행할지와 관련된 많은 내장 매개변수와 프로퍼티들이 가용하다(더 많은 정보는 참고자료 참조).

매 개변수와 프로퍼티를 사용하여 로드 테스트를 어떻게 실행할지에 대해 어느 정도 유연함을 줄 수 있다. 그러나 그것으로는 테스팅이나 스테이징 같은 서로 다른 대상(target) 환경에서 로드 테스트를 어떻게 실행할 것인지 하는 문제는 해결하지 못한다. 환경에 특화된 정보를 테스트 계획에 추가하려면, jmx 파일들 안에 토큰을 추가하여 로드 테스트가 자동화된 빌드 스크립트에서 실행될 때 그것들을 필터링하고 수정할 수 있도록 해야 한다.




위로


Just-in-time 로드 테스팅

자동화된 빌드로 로드 테스트를 실행할 수 있게 되었다면, 이제 밤과 같이 일정 주기마다 실행하도록 스케쥴링을 하자. 이때 CI 또는 빌드 관리 서버를 사용할 수 있다.

CruiseControl을 스케쥴링하여 매일 로드 테스트 실행하기

CI 서버 사용 목적은 프로젝트의 버전 관리 저장소에 변경이 있을 때마다 자동으로 빌드를 실행하기 위함이다. 물론 빌드를 특정 시간에 실행하도록 설정할 수도 있다. 로드 테스트는 보통 많은 리소스를 필요로 하기 때문에, 테스트를 실행하는 시점에 자원이 충분히 가용해야 한다. 따라서 늦은 밤이나 이른 아침이 효율적일 것이다.

Listing 5에 보면, 자동화된 빌드를 11:00 PM(2300)에 실행하도록 CruiseControl(참고자료 참조)에 스케쥴링되어 있다. CruiseControl 설정 파일을 수정하여 run-load-tests와 같이 특정 앤트 타겟들을 실행하도록 설정할 수 있다.


Listing 5. CruiseControl을 사용하여 로드 테스트를 일정 시간마다 실행하기
  ...
  <modificationset>
    <svn RepositoryLocation="${svnrepo.location}"/>
    <timebuild username="admin" time="2300"/>
  </modificationset>
  ...

Listing 5와 같이 로드 테스트를 밤에 실행함으로써, 작업부하, 쉬는 날 또는 테스트 실행 잊어버리기에 대해 불평을 듣지 않아도 된다. 그래도 돌아갈테니 말이다.

CruiseControl에서 보고서 보여주기

여 러분은 이미 앤트를 사용하여 JMeter 테스트 보고서를 보는 방법을 살펴보았다. JMeter 보고서는 단일 머신의 개발자 한 명에게만 의사소통을 하는 한계가 있다. 로드 테스트는 전체 애플리케이션에 영향을 주고, 따라서 팀 전체가 그 결과를 보고 싶어할 것이다. 매우 쉽게 CI 서버를 설정하여 이 보고서를 보여주도록 할 수 있다. 보고서는 이미 앤트가 만들어 두었기 때문에, JMeter HTML 보고서를 CruiseControl 프로젝트 대시보드에서 접근할 수 있게만 하면 된다. CruiseControl의 config.xml 파일에 몇 줄만 추가하면 그렇게 할 수 있다. Listing 6을 참조하라.


Listing 6. CruiseControl에 JMeter 보고서 설정하기
<project name="brewery">
...
<log>
  <merge dir="merge dir="projects/${project.name}/reports/jmeter" />
</log>
...
</project>

이제, 팀원 모두가 같은 페이지를 볼 수 있다. 다수의 다른 CI와 빌드 관리 서버들도 이와 비슷한 보고서 통합 기능을 지니고 있다.




위로


결론

필 자는 자동화된 로드 테스트를 개발 도구에 추가하는 방법을 설명했다. 로드 테스트를 자동화된 빌드로 실행하고 테스트를 주기적으로 실행하도록 설정함으로써, 문제가 되기 전에 시스템 역량 이슈에 대해 알 수 있게 되었다. 이런 접근 방법은 아키텍처의 핵심에 접근이 쉽고 데이터 변경을 쉽게 해준다. 본 기사 연재에서 설명한 다른 기술들과 함께 사용하면, 개발 팀이 더 품질 좋은 소프트웨어를 빠르게 개발하게 할 수 있을 것이다.





위로


다운로드 하십시오

설명 이름 크기 다운로드 방식
이 글의 예제 앤트 스크립트 j-ap04088-jmeter-example.zip 6KB HTTP
다운로드 방식에 대한 정보


참고자료

교육

제품 및 기술 얻기
  • 앤트: 앤트를 다운로드하고 예측 가능하며 반복 가능한 방법으로 소프트웨어를 개선하라.

  • JMeter: JMeter를 다운로드하라.

  • JMeter 앤트 태스크:JMeter 테스트 계획을 실행하기 위한 앤트 태스크

  • CruiseControl: CruiseControl Continuous Integration 서버를 다운로드하라.

  • IBM 제품 평가판을 다운로드하고 애플리케이션 개발 도구와 DB2®, Lotus®, Rational®, Tivoli®, WebSphere®의 미들웨어 제품들을 사용하라.

토론


필자소개

Paul Duvall은 컨설팅 회사이자 개발 팀을 애자일 소프트웨어 제작에 최적화하는 데 있어 선구자적인 역할을 하는 Stelligent Incorporated의 CTO다. Paul Duvall은 Addison-Wesley Signature Series Book인 Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, 2007)의 공동 저자다. 또 UML 2 Toolkit (Wiley, 2003)과 No Fluff Just Stuff Anthology (Pragmatic Programmers, 2007)에도 기여하였다.

=========================
<출처: http://www.ibm.com/developerworks/kr/library/j-ap04088/index.html?ca=drs-kr >