1. 사용하게 된 이유
NGINX의 마이크로 캐싱을 통한 API 서버 성능 개선 작업을 진행하고 있다.
이미 사용 중인 기능의 DB 스키마와 로직 개선에 대한 기능 테스트야 하던 대로 진행 했지만, 기존 방식으로는 확인하기 힘든 테스트가 생겨버렸다.
NGINX 마이크로 캐싱을 통한 API 대량 요청에 대한 기대 성능을 측정해봐야 하는데, 기존의 부하 테스트는 테스트 할 때마다 외부에서 호출해주기 위한 배치 프로세스를 별도로 개발/배포하여 사용해야 했다.
개발하고 정리하는 것만 해도 시간 모자른데, 부하 테스트용 코드를 또 개발해야 하는 것은 너무 비효율적이었다.
그러던 중 팀장님의 권유로 nGrinder에 대해 알게 되어 적용해보기로 했다.
2. nGrinder란
부하 테스트용 오픈 소스 grinder를 Naver에서 가다듬은 버전이다.
Web GUI를 제공하며 가상 유저 수와 API 호출 횟수, 그리고 테스트 결과에 대한 시각화를 제공한다.
그런데 생각보다 제대로 정리된 글이 없다. 구버전 대상 설명이거나, 끝까지 설명하지 않은 경우가 많아서 정리한다.
3. 구성
GUI를 제공하는 nGrinder-Controller
테스트 대상 API를 호출하여 부하를 발생 시키는 nGrinder-Agent
테스트 대상 API가 실행되는 Target 서버의 실시간 리소스(CPU, Memory, Network) 정보를 수집하는 nGrinder-Monitor
세 개로 구성되어있다.
4. nGrinder 실행 파일
github.com/naver/ngrinder/tags
naver/ngrinder
enterprise level performance testing solution. Contribute to naver/ngrinder development by creating an account on GitHub.
github.com
nGrinder 또한 github에 공개되어 있고, 단독 실행 가능한 war 파일로 버전 별로 공개되어있다.
5. nGrinder 설정
5-1. nGrinder-Controller
제일 먼저 실행할 것은 nGrinder-Controller이다.
* Controller에서 제공하는 Web 페이지에서 Controller와 버전이 맞는 Agent와 Monitor의 실행 파일을 다운받을 수 있고, Agent의 경우 Controller가 실행되어있지 않다면 실행 되지 않는다.
4번의 링크에서 원하는 버전의 ngrinder-controller-(버전).war 파일을 다운받아서 실행할 서버로 업로드를 해준다.
(아니면 wget으로 해당 서버에서 직접 다운로드를 받아줘도 된다. - 다운로드 링크 우클릭해서 주소 복사 -)
* 원하는 서버의 원하는 경로에 다운로드를 끝냈다면 실행만 시켜주면 된다. 별도의 톰캣 설정 없이 단독으로 실행 가능하도록 빌드 되어있다.
사진 3의 하단에 ngrinder-controller.war 파일을 다운받으면 된다.
실행 파일을 받았으니 실행을 시켜보자.
* 실행 스크립트는 아래와 같다.
nohup java -XX:MaxPermSize=200m -jar ngrinder-controller-(버전).war --port (원하는 포트) &
예시) nohup java -XX:MaxPermSize=200m -jar ngrinder-controller-3.5.3.war --port 8080 &
기본 계정은
아이디 : admin
비밀번호 : admin
이다
그리고 이하 설명은 한국어 베이스로 진행할 것이기 때문에 언어는 한국어로 설정할 것이다.
5-2. nGrinder-Agent
Controller가 준비됐으니, 부하 발생기인 Agent를 준비해보자.
Agent의 실행 파일은 Controller를 실행시키면 얻을 수 있다.
사진 8을 따라 우측 상단의 계정을 클릭하면, 플로팅 메뉴가 나오는 것을 알 수 있다.
해당 메뉴에서 "에이전트 다운로드"를 클릭하면, ngrinder-agent-(Controller의 IP).tar 압축 파일이 다운로드 되는 것을 알 수 있다.
* 해당 압축 파일은 실행 가능한 자바 프로젝트의 압축 파일이기 때문에, 사용할 위치에서 압축만 풀어주면 된다.
사진 10과 11을 보면 압축을 풀었을 때 nGrinder-agent 폴더가 생성된 것과 폴더 하위 경로에 실행 스크립트/실행 파일/__agent.conf 파일이 있는 것을 확인할 수 있다.
여기서 먼저 해야할 것은 __agent.conf 파일의 수정이다.
하단에 주석이 되어있는 것은 사용하지 않는다. (추가적인 기능이 있는 것이겠지만, 기본적으로 사용하지 않았다. 자료도 적고 테스트 진행에 있어서 필요하지 않았다.)
필요한 것은 상단의 agent.controller_host 이다.
현재 작성하고 있는 예시는 시험용 예시이기 때문에 Controller와 Agent가 하나의 기기(노트북)에서 함께 실행하지만,
본래의 목적 달성을 위해서는 Controller와 Agent는 다른 서버 머신에 있어야 한다. 이 때 실행되는 Agent가 Controller를 바라보게 되는데 그것을 위해 Controller_host, 즉 Controller의 IP와 Controller_port를 필요로 하게 된다.
* Controller가 설정 수정 없이 디폴트로 수정되었다면, Web 접근용 포트 이외에 Agent 접근용 16001 포트와 부하 테스트 사용을 위한 12000~12009 포트가 함께 개방된다.
지금 예시에서는 localhost로 실행되기 때문에 그냥 실행하겠다.
실행 방법은 윈도우의 경우 run_agent.bat 혹은 run_agent_bg.bat을 실행하고, 리눅스의 경우 run_agent.sh 혹은 run_agent_bg.sh를 실행하면 된다. (_bg는 백그라운드로 실행하겠다는 의미이다. 실제 동작 확인을 하고 싶다면 run_agent를, 아니면 run_agent_bg를 실행시키면 된다.)
예시에서는 _bg파일로 스크립트를 실행하였고, Agent 자바 프로세스가 정상적으로 실행된 것을 확인할 수 있다.
그럼 Controller에서 정상적으로 인식했는지 확인해보자
우측 상단 계정 클릭 후, 에이전트 관리로 들어가보자
Agent의 정보가 등록된 것을 확인할 수 있다.
주의) 내 경우 실무 적용 시 aws subnet 환경에서 해당 작업을 진행했는데, Controller의 외부 접근용 IP를 __agent.conf에 설정 후 실행 시 Connection refused 에러가 발생했었다. 정확한 이유는 모르겠지만 내부 IP로 재설정 후 실행했더니 해결되었다.
여기까지만 해도 부하 테스트를 충분히 진행할 수 있기 때문에 보통 여기서 설명이 끊긴 경우가 대부분이었다.
하지만 어림도 없지. 팀장님께선 리소스의 모니터링도 볼 수 있어야 한다고 하셨다.
팀장님은 모니터가 좋다고 하셨어
5-3. nGrinder-Monitor
마지막 Monitor를 보자.
Monitor는 nGrinder-architecture 구성 중에서 target server, 부하를 받을 서버에 설치되어야 한다.
Agent에 의해 부하를 받는 동안에 부하 대상의 CPU, Memory, Network receive/send Queue를 시각화하여 함께 볼 수 있기 때문에 적용하여 손해보는 것은 단 하나도 없다.
하지만 개인적으로 처음 설정할 때 가장 고통 받았던 것이 Monitor다.
설정 이전에 이해를 돕기 위한 설명!
Agent는 Agent가 Controller를 보는 것이다. 그렇기에 Agent에 Controller를 등록했다.
그렇다면 Monitor는 어떨까? 사진 1의 nGrinder architecture를 보면 알 수 있듯이, Controller가 Monitor를 본다고 되어있다.
그럼 이제 Monitor 설치를 해보자
* 사진은 위에 올려보기 싫으니까 똑같은거 다시 올렸다.
플로팅 메뉴에서 모니터 다운로드를 확인할 수 있다. 다운받자.
이후 Agent와 동일하게 tar -xvf 명령어로 압축을 풀어서 생성되는 ngrinder-monitor 폴더로 들어가보자.
Agent와 거의 비슷해보이고 __agent.conf 파일이 있어 잘못들어왔나 싶겠지만, Monitor경로로 제대로 들어온 것이 맞다!
수정하지 않은 __agent.conf의 내용이다.
실행 모드는 monitor로 되어있는데, 이것은 Monitor가 원래 Agent와 동일한 프로젝트였던 것으로 추측한다.
* 증거 없이 이렇게 추측하는 이유는, 구버전의 설정을 설명한 다른 글들에서 볼 때 Monitor의 __agent.conf 포맷이 사진 18과는 다르게 Agent의 그것과 포맷이 동일하기 때문이다. 뻘소리니 그냥 Monitor설정이구나 하고 넘어가자
그 아래 주석 처리 되어있는 monitor.binding_ip는 리소스 모니터링을 할 대상 서버 머신의 IP이다. 주석처리가 되어있다면 디폴트로 Monitor가 실행되고 있는 서버 머신의 리소스를 보게된다.
monitor.binding_port는 monitor가 실행될 때 개방하는, nGrinder-Controller가 nGrinder-Monitor로 접근하기 위한 port이다. nGrinder-Controller의 기본 설정으로 지정되어있기 때문에 수정은 하지 않겠다.
그럼 실행을 해보자
여기까지 했으면 거의 다 된 것이다.
마지막으로 남은 Controller에 Monitor를 등록하는 과정을 진행해보자.
Controller 상단의 "성능 테스트" 탭을 클릭하면, 위와 같은 페이지에 진입하게 된다.
우측에 있는 "테스트 생성" 파랑색 버튼을 눌러보자
위와 같은 테스트 설정 페이지가 나오는데, 우리는 여기서 테스트를 하는 방법은 보지 않을 것이다.
사실 작성은 하고 싶은데, 부하 테스트에 사용할 서버를 올려놓은게 없다.
여기서 봐야하는 것은 왼쪽 아래에 "테스트 대상 서버"라고 쓰여진 텍스트 박스이다. 텍스트 박스 오른쪽 아래 "+ 추가"를 눌러보면 도메인과 IP를 추가할 수 있는데, IP만 추가해주면 설정이 끝나게 된다.
여기까지 설정한 후 테스트를 진행하면, 상세 보고서에서 좌측 하단에 타겟 서버 당 시각화된 리소스 모니터 데이터를 확인할 수 있다.
'공부 - 개념, 철학 > 기타' 카테고리의 다른 글
| 비동기 처리를 한 서버에서 하지 말기 (0) | 2021.08.10 |
|---|---|
| [AWS] 멀티에이지 Multi-AZ(Availability Zone) (0) | 2021.01.28 |
| [AWS] 기본적인 구성과 용어 (간단하게) (0) | 2021.01.27 |