부하테스트(feat. Ngrinder)

자연스럽게 고가용성의 정의는 거의 항상 서비스를 정상적으로 제공할 수 있는 상태를 뜻한다고 봐도 좋을 것 같네요. 서비스 운영에서 고가용성의 중요성이 계속해서 강조되다 보니 높은 가용성을 가진 다양한 시스템 설계 방법이 많은 글, 영상에서 소개되고 있습니다. 그 중 두 가지 대표적인 방법에 대해 경험을 기반으로 간단하게 소개하겠습니다.

이제 막 첫 걸음을 떼는 서비스는 트래픽이 그리 많지 않아 시스템 확장을 해야하는 상황 자체가 오지 않습니다. 실제로 그런 상황이 오지 않으니 내 서버가 어느 시점에 시스템을 확장해야 하는지, 어느 정도의 트래픽을 견디는지 판단하는 것이 어렵습니다. 이러한 어려움 때문에 고가용성 서비스 운영을 위한 대비가 전혀 불가능한 것이죠.

이 문제를 해결하기 위해 부하테스트가 존재합니다. 부하테스트는 가용성과 확장성 높은 시스템 구축을 위한 하나의 방법인 것이죠.

부하테스트의 목적은 시스템 처리 능력 (어느 정도의 부하를 견디는지)을 계산하여 가용성을 높이고, 서비스의 장애상황에 대비하는 것입니다.

다양한 시나리오의 부하테스트를 통해 WS, WAS, DB 시스템의 응답 성능을 예측해보고 원하는 성능을 만들기 위해 서버를 확장한다거나, 언어 차원의 성능을 개선할 수 있고. 혹은 장애 상황에 빠르게 대처하는 안정적인 인프라 구조를 가질 수 도 있습니다. 부하테스트를 통해 어떤 지점을 더 개선해야하는지 고민하고 실제로 개선하여 안정적인 서비스 운영을 대비할 수 있는 것이죠.

0. 부하테스트의 종류

1. 부하테스트 도구 선정

2. 무엇을 테스트 할 것인가?

부하테스트를 하기에 앞서 무엇을 테스트 할 것인지 결정하는 것이 정말 중요합니다.

•

서버에서 정적 리소스를 잘 서빙해주는지?

외부의 영향 전혀 없이 서비스를 제공하는 프레임워크, 서비스 환경 자체에 대한 검증이 필요하다면 로컬호스트에서 정적 리소스를 원하는 기대치만큼의 성능으로 잘 반환하는지 확인해보면 좋을 것 같습니다. 혹은 "Hello World" 정도를 찍어보고 검증을 해볼 수도 있을 것 같습니다.

•

DB 연결 + 조회에 대한 검증 (DB 사용, 네트워크 요청 or 로컬호스트)

DB에 연결하고 조회에 대한 부하를 주고 검증을 하려면 운영 환경만큼 더미 데이터를 쌓아두고 반복적으로 조회에 대한 성능을 테스트할 수 있습니다. 이전 테스트인 서버의 리소스만을 사용할 때와는 얼마나 다른 결과를 발생시키는 지, 그 결과의 차이가 유의미하게 크다면 인덱스를 적용해보거나 DB 커넥션 풀을 조정해 볼 수 있을 것 같습니다. 혹은 query를 수정해 볼 수도 있을 것 같습니다. 데이터 갱신보다 조회가 훨씬 많은 서비스라면 캐시 적용까지 고려하여 조회에 대한 성능 개선을 기대해 볼 수 있습니다.

•

DB 연결 + CUD에 대한 검증

앞선 테스트와 유사하게 DB에 연결하고 CUD 작업을 진행합니다. 쓰기 작업이 거의 없는 서비스보다, 쓰기 작업이 매우 많거나 종종 쓰기에 대한 부하가 몰리는 서비스를 운영하는 개발자들에게 필수적인 테스트 같습니다. 쓰기 행동을 하기 위한 디스크 I/O 병목을 잘 살피고, 데이터가 잘 갱신되었는지 확인하여 어느정도 성능 / 안정성을 낼 수 있는지 점검할 수 있습니다.

•

외부서비스 연동

외부서비스를 연동 (Oauth, 결제 등)을 테스트 하고 싶다면, 실제 요청 시간과 가깝게 실행되는 임의의 가짜 인스턴스를 띄워 네트워크 요청 / 응답을 위한 리소스를 사용하게끔 만드는 것이 중요합니다. Keep-Alive를 제거하여 반복적인 테스트에서 연결 유지를 하지 않게끔 설정하고, 외부 네트워크를 태우는 것이 필요합니다.

•

사용자 시나리오

앞선 테스트를 통해 병목지점을 발견하고 일부 성능이 개선되었다면 이제 사용자 시나리오를 기반으로 부하테스트를 진행합니다. 일반적으로 사용자가 1회 접속당 어떤 요청들을 보내는지 로그를 통해 확인하고, 사용자 시나리오대로 시스템에 부하를 걸어 사용자가 사용할 때 성능이 잘 나오고 안정적인지 확인할 수 있습니다.

3. 어떻게 테스트할 것인가

부하테스트를 실제 운영 환경에 진행할 수는 없습니다. 부하테스트 자체가 최대 부하지점 혹은 목표 성능 유지 등을 점검하면서 서비스에 많은 부하를 주기 때문에 사용자의 서비스 이용에 큰 불편함을 줄 수 있기 때문입니다.

그래서, 테스트 하기위해 운영환경과 동일한 인프라에 동일한 데이터를 가지고 동일한 외부 요청을 보내는 서비스를 통째로 하나 생성하여 부하테스트를 진행합니다. 하지만 인스턴스를 실제 운영환경만큼 띄워서 유지해야하는 것은 그 비용이 어마어마하게 책정될 것입니다. 이런 부분은 다양한 방법으로 개선할 수 있으니 알아보면 좋을 것 같습니다.

고려해야 할 사항

•

서버의 메모리

•

최대 이벤트 수

•

서비스가 얼마나 빠른지(Time), 

•

일정 시간 동안 얼마나 많이 처리할 수 있는지(TPS), 

•

그리고 얼마나 많은 사람들이 동시에 사용할 수 있는지(Users)에 대해

테스트 할 목록

내가 만든 이 시스템은 실제 장비에서

•

어느 정도의 부하 를 견딜 수 있는가?

•

시스템(데이터베이스, 서버), 자원(cpu, disk, memory 등)에서 병목 이 생기진 않는가?

•

자원을 효율적 으로 사용하는가?

•

메모리 누수, 오류, 오버플로우 는 발생하지 않는가?

•

최악의 상황 에선 어떤 동작을 하는가? (예측하고 대비하기 위하여)

•

장애 조치와 복구 가 잘 동작을 하는가?

성능 테스트

•

실제 트래픽 상황에서의 정상 동작

•

기존 시스템 대비 BenchMarking

부하 테스트

•

리소스 병목 탐색, 어플리케이션 버그 탐색

•

이벤트 상황과 같은 순간 트래픽 최대치, 한계치를 탐색

•

신규 스펙 장비에서 MYSQL 설정 최적화 탐색

스트레스 테스트

•

장기간 부하 발생에 대한 한계치를 탐색, 예외 동작 상황 확인

•

Graceful Shutdown 정상 동작 확인

•

데이터베이스 failover 상황, 자동 복구, 예외 동작 상황 확인

•

외부 요인(PG사)의 밀릴, 예외 상황 동작 확인

•

어느 정도의 부하 를 견딜 수 있는지 알고 있다.

•

한계치에서 병목 이 생기는 지점을 알고 있다.

•

자원을 효율적 으로 사용한다.

•

메모리 누수, 오류, 오버플로우 는 발생하지 않는다.

•

최악의 상황 에서 어떤 동작을 하는지 직접 확인하였다.

•

장애 조치와 복구 의 동작을 직접 확인하였다.

nGrinder

•

The Grinder라는 오픈소스 기반으로 네이버에서 개발

•

테스트 프로세스를 제공

•

부하를 줄 수 있는 웹 인터페이스를 제공

•

테스트 결과를 수집하여 통계로 제공

•

Groovy 로 스크립트 작성 가능

JMeter

•

Apache에서 개발한 순수 자바로 개발된 성능 테스트 도구

•

플러그인을 이용하여 테스트 케이스를 XML 형식으로 작성

•

Load Test, Distributed Test, Functional Test 등을 지원

•

멀티 스레드를 사용하여 다양한 사용자를 시뮬레이션하고 target에 대한 load를 생성

•

웹 응용 프로그램, 데이터베이스, 서버 테스트에서 작동하며 HTTP, JDBC, LDAP, SOAP, JMS 및 FTP와 같은 다양한 프로토콜도 지원

Controller

•

웹 기반의 GUI 시스템

•

유저 관리 (각자 시나리오 작성 가능)

•

에이전트 관리

•

부하테스트 실시 & 모니터링

•

부하 시나리오 작성 테스트 내역을 저장하고 재활용 가능

agent

•

부하를 발생시키는 대상(주체)

•

controller의 지휘를 받는다.

•

여러 머신에 설치해서 controller의 신호에 따라 일시에 부하를 발생가능

•

테스트하려는 머신에 agent 설치

VUser

•

가상의 사용자

설치

공식 설치 가이드 영어로 되어있음

WAR 또는 소스 코드 설치 받는 곳

실행

서버(컨트롤러) 실행

java -XX:MaxPermSize=200m -jar  ngrinder-controller-3.4.war
Shell
복사

•

-XX:MaxPermSize 옵션이 들어가야 하는 이유

◦

nGrinder 는 SVNKit, maven, Jetty webserver, groovy, python 등을 포함하고 있기때문에 거대한 PermGen 메모리를 요구한다.

•

--port 80 설정으로 포트를 설정할 수 있다.

•

localhost:8080 으로 접속 한 뒤 초기 계정 admin/admin 으로 로그인

에이전트, 모니터 실행

•

접속 뒤 계정에서 Agent와 Monitor tar 파일 다운로드

•

untar 뒤 각각의 폴더에서 shell script 실행

•

tar -xvf ngrinder-agent-…war

./run_agent_bg.sh
./run_monitor_bg.sh
Shell
복사

•

Agent: 아까 설치한 agent. 여러개 가능함 나는 로컬에서 하나로만 함

•

Vuser per agent: agent 당 가상 사용자 수

•

Target Host: script 에 나와있어서 굳이 기재하지 않아도 된다.

•

Duration: 테스트 소요 시간

•

run count: 가상 유저당 요청을 실행하는 횟수. 0이면 Duration 시간동안 계속 보냄

 vuser 는 script 하나를 완료하면 run count 가 1이다. 0이면 script 하나를 완료하면 다시 스크립트를 진행한다. 즉 요청이 다 오고 응답을 받고 나야 다시 요청을 보낸다. DDos 처럼 응답이 오지도 않았는데 요청만 보내지 않음!!