성능 테스트 자동화 환경 구축기 (2)

도입

저번시간에 작성한 성능 테스트 자동화 환경 구축기(1)에 대한 내용을 정리해 보면, 성능 테스트를 위해 여러 가지 요소들이 필요했다. 우선, 성능 테스트를 위한 대량의 요청을 생성해주는 nGrinder, 서버 상태를 모니터링할 수 있는 PinPoint, 그리고 성능 테스트 대상이 되는 API 서버를 AWS 상에 구축해야 했다. 이를 위해 우리는 Terraform을 활용하여 AWS 자원(EC2, VPC, RDS 등)을 코드로 관리할 수 있도록 설정하였다.

 

하지만 단순히 AWS 자원을 콘솔이 아닌 코드로 관리할 수 있게 되었다고 해서 성능 테스트 자동화 환경을 구축했다고 말할 수는 없다. 그렇다면, 진정한 의미에서 성능 테스트 자동화 환경을 구축했다고 말하려면 무엇이 더 필요할까?

자동화의 필요성

성능 테스트는 다음과 같은 과정으로 이루어진다.

1. 성능 테스트 시나리오 구상
   시스템의 어느 부분에 어떻게 부하를 줄 것인지를 결정하고 부하 상황에서 시스템이 어떻게 동작하면 좋을지 기댓값을 설정해야한다.
2. 성능 테스트 환경 구축
   성능 테스트를 수행하기 위해서는 부하 생성기, API 서버, 모니터링 도구들을 구축해야 한다. 이때 성능 테스트의 대상인 API 서버의 서버 수, 서버 스팩을 결정하고 scalue-out하고 scale-up 하는 등의 scale을 조절하는 작업을 하게 된다.
3. 성능 테스트 생성 및 수행
   테스트 환경 구축이 다 되면 준비된 시나리오에 따라서 실제로 요청을 발생 시키면서 성능 테스트를 수행하게 된다.
4. 테스트 결과 지표 관측 및 기록
   테스트가 시작되면 동시에 서버가 어떻게 동작하는지 관측하고 기록하는 일을 하게된다.
5. 테스트 결과 분석
   테스트 수행이 끝나면 관측한 지표를 바탕으로 서버가 요청을 잘 처리했는지 시스템이 기대한대로 동작했는지 등을 체크한다.

추가로 테스트가 필요한 경우에는 위와 같은 과정들을 반복하게 된다. 그런데 이 과정들을 가만히 살펴보면 전체적으로 서로 다른 두가지 그룹으로 나눌 수 있다.

 

위 과정에서 2번 3번 4번은 성능 테스트를 하면서 계속해서 반복해야 하는 과정들이다. 준비된 시나리오 대로 단순히 수행하기만 하면 되는 일이다. 성능 테스트 환경을 구축하고, 성능 테스트를 수행하고, 테스트 결과 지표를 관측하는 이 부분은 순차적으로 진행되는 파이프라인 구조라고도 할 수 있다. 보통 성능 테스트를 하면 이 과정에서 쏟는 노력과 시간이 많으면 절반 이상이 될 때도 있다.

 

그런데 개발자가 시간을 쏟고 집중해서 해야 되는 부분은 사실 1번과 5번 부분이다. 성능 테스트 시나리오를 구상하고 테스트 결과를 분석하는 일은 상당히 복잡한 사고를 필요로 하는 일이다. 예를들어 시나리오대로 테스트를 했는데 결과를 보고 왜 서버가 느리지? 어떻게 하면 더 개선할 수 있지 등과 같이 다양한 고민들을 하게 된다. 그래서 해당 부분은 자동화 하기가 어려운 부분이다.

 

반면에 2번 3번 4번은 단순 반복되는 작업이므로 자동화가 가능하다. 이런 부분들이 자동화가 되면 여기에 쏟는 시간들을 아껴 진정으로 필요한 부분인 1번과 5번 작업에 집중할 수 있게 된다. 그래서 2번 3번 4번 부분을 자동화 하는것을 목표로 자동화 환경을 구축해 보았다.

어떻게 구현할까?

AWS CLI, nGrinder, Jenkins를 이용하여 구현할 수 있었다.

 

AWS CLI를 통해 command line으로 인프라를 제어할 수 있고 nGrinder는 REST API를 지원하고 있다. 그래서 http 요청을 통해서 테스트를 생성하고 수행하게 할 수 있다. 이런 내용들을 잘 조합을 해서 groovy script로 잘 정리한 다음에 Jenkins에 전달하면 간단하게 파이프라인을 구축해 볼 수 있다.

 

그래서 실제로는 다음과 같이 동작하게 된다. 일단 Jenkins 서버를 하나 띄우고 파이프라인을 구축해 둔다. 여기서 테스트 시나리오를 구성하고 테스트 스크립트 까지 다 준비 됐다고 생각해보자.

 

파이프라인을 실행시키면 먼저 AWS 환경 구축을 수행하게 된다. API 서버를 띄운다던지, nGrinder agent를 생성한다던지, PinPoint 서버를 띄운다던지 등의 일을 자동으로 진행하게 된다.

 

이렇게 환경이 다 구축이 되면 nGrinder의 REST API를 통해서 새로운 테스트를 생성하고 수행하는 일을 시작하게 한다. 그러면 nGrinder agent에서 실제로 요청이 생성 돼서 API 서버에 부하가 생기기 시작한다. 성능 테스트가 진행하는 동안 Jenkins는 테스트가 진행된 시간을 기록하게 된다.

 

테스트가 마무리되면 nGrinder로 부터 테스트 결과를 조회하고 그 다음에 결과 레포트를 만들어 slack으로 전송해 준다. 이렇게 하면 테스트가 한번 완료가되는 것이다.

 

모든 테스트가 완료되면 불필요한 AWS 자원들을 삭제하거나 종료하는 작업들을 진행하게 된다.

 

이런식으로 동작하도록 자동화된 파이프라인을 구축해보았다.

 

(1) AWS 환경 구축 파이프라인

Pipeline Overview

 

원래 모니터링 도구는 aws상에 미리 구축해 두고 있어야 하지만 조금이라도 비용을 아끼기 위해 이것 또한 해당 파이프라인이 수행될 때마다 만들게 구성해 주었다. 다음은 groovy script중 일부이다.

 

api 서버를 구성하는 job, pinpoint server를 구성하는 job, nGrinder controller를 구성하는 job을 병렬적으로 수행한다. 이때의 환경 구성은 단지 ec2를 새로 만들거나 종료된 ec2를 시작하는 일을 하게 된다.

다음은 api server의 ec2를 만드는 job의 일부이다.

 

위 사진과 같이 AWS CLI를 이용하여 ec2를 생성하고 ec2가 running 상태가 될 때까지 대기하게 된다. API 서버의 스팩이 변경될 수 있기 때문에 스팩과 관련된 부분은 변수화하여 넘겨주었다. 나머지 job도 위와 비슷하거나 같다.

 

이전 버전에서는 Terraform으로 AWS 자원을 구축하였지만 단지 AWS 자원을 생성하고 종료하는데 Terraform을 사용하기엔 무거운 감이 있어 AWS CLI로 구현하였다.

 

이렇게 job이 수행되면 다음과 같이 AWS상에서 ec2가 생성된걸 볼 수 있다.

 

서버 설치 및 실행

 

환경이 모두 구축되고 나면, 해당 환경에 맞는 서버를 설치하거나 시작하는 작업이 필요하다. 이러한 서버 설치 및 시작 작업은 쉘 스크립트로 자동화하였다. 구체적으로, 필요한 작업을 담은 쉘 스크립트 파일을 작성한 후, scp를 이용해 해당 스크립트를 서버로 전송하고, ssh를 통해 스크립트를 실행하는 방식으로 서버를 설치하거나 시작할 수 있도록 구성하였다.

pinpoint 예시

(2) 성능 테스트 생성 및 수행

위와 같은 방식으로 nGrinder, pinpoint, API 서버 모두 실행이 되면 nGrinder controller에 REST API를 이용하여 성능 테스트 생성 및 수행을 하게된다.

nGrinder의 REST API는 다음 문서를 참고하였습니다.
https://github.com/naver/ngrinder/wiki/REST-API-PerfTest 

Home

 

다음은 성능 테스트를 생성하고 수행하기 위해 REST API를 요청하는 groovy script중 일부이다.

위 요청을 통해 nGrinder는 테스트를 생성하고 수행하게 된다.

nGrinder controller에서 테스트가 수행된 모습

(3) 성능 테스트 결과 지표 관측 및 기록

완료된 성능 테스트 결과는 nGrinder REST API를 이용하여 조회한 후, 이를 바탕으로 Slack 메시지를 구성하였다. 이렇게 생성된 메시지에는 성능 테스트의 주요 결과(TPS, MTT)가 포함되며, 팀원들에게 신속하게 공유될 수 있도록 설정하였다.

 

또한, 성능 테스트 동안 PinPoint로 모니터링한 지표도 Slack 메시지에 포함시켰다. 이 지표는 테스트가 진행된 시간에 맞춰 필요한 구간만 잘라내어 URL 형식으로 제공함으로써, 성능 테스트 결과와 관련된 모니터링 데이터를 함께 확인할 수 있게 구성하였다.

slack 메시지

위 사진에서 PinPoint URL을 클릭하면 다음과 같은 화면이 보이게 된다.

 

또한 Inspector URL 을 클릭하면 성능 테스트 동안 서버 자원을 얼마나 사용했는지 볼 수 있다.

job 연결

위에서 만든 여러 작업(Job)을 이제 하나의 Groovy 스크립트에서 연결함으로써, 파이프라인을 실행하기만 하면 모든 과정이 한 번에 자동으로 수행되도록 구성하였다.

 

아래 이미지는, 앞서 만든 다양한 작업들을 하나의 파이프라인으로 이어붙여 "성능_테스트_시작" 이라는 이름의 파이프라인으로 만든 모습이다. 이제 실행 버튼만 클릭하면 성능 테스트 환경 구축부터 테스트 실행, 결과 조회까지 모든 과정이 자동으로 처리된다.

또한, 성능 테스트 후 테스트 환경을 정리하는 기능도 제공된다. 이 기능은 AWS CLI를 이용해 성능 테스트 중에 구축한 AWS 자원들을 정리하는 역할을 한다. 이 과정도 "성능_테스트_시작" 파이프라인에 포함시킬 수 있으나, 나의 경우에는 성능 테스트 환경을 구축한 뒤 여러 번의 추가 테스트를 진행할 가능성이 있어, 환경 정리 작업은 별도의 스크립트로 분리해 관리하였다.

 

자동화를 통해 얻을 수 있었던 이점들

사람이 직접 성능 테스트를 수행할 경우, 실수가 발생하기 쉽다. 하지만 성능 테스트를 자동화하면서, 실수 없이 동일한 테스트를 여러 번 재현할 수 있게 되었다. 이로 인해 테스트의 정확성과 일관성이 크게 향상되었다.

 

또한, 성능 테스트 자동화를 통해 불필요한 자원 낭비를 줄일 수 있었다. 수동으로 성능 테스트를 진행하면 자원을 계속해서 구축하고 종료하는 과정이 번거로워서 자원을 지속적으로 사용하게 되는 경우가 많다. 하지만 자동화를 통해 성능 테스트가 진행되는 동안에만 AWS 자원을 사용하고, 테스트가 끝난 후에는 자동으로 자원을 정리할 수 있어, 불필요한 자원 사용을 최소화할 수 있었다. 이로써 비용 절감과 자원 효율성을 높이는 데 기여했다.

 

 

 

 

참고 자료

nGrinder 자동화
nGrinder REST API DOCS
nGrinder param
우아한 형제들 - 서버 성능테스트, 클릭 한 번으로 끝내볼 수 있을까?