[server] 부하테스트 - 3 + EC2 인스턴스 종료

부하테스트 할 인프라 구성

부하테스트 하기 전에 인프라의 전체 구성(인프라 아키텍처)을 그림으로 그려 놓으면 좋다. 인프라의 전체 구성을 그림으로 그려놓은 상태로 부하테스트를 해야 전체적인 트래픽들이 어떻게 흘러가는지 한눈에 파악할 수 있고, 어디서 성능적으로 문제가 생기는지 진단을 내리기 쉽다. 

 

 

구성한 시스템이 1초당 몇 개의 요청을 견딜 수 있는지 알아보려면, 점진적으로 트래픽을 늘려가게끔 부하테스트를 세팅해야 한다. 

 

 

k6 이용한 부하테스트 

 

k6-server의 ec2 인스턴스에 파일을 만들어준다. 백엔드 서버에 부하를 주기 위해 k6 스크립트를 작성한다. 

 

vi script.js

 

stages : 부하를 생성하는 여러 스텝을 만든다.
10분에 걸쳐 target(사용자 수 / 가상 유저 수)를 만든다. 가상 유저 수가 6000에 도달하도록 만든다. 실제 6000명인 사용자가 요청을 보내는 것처럼 세팅을 한다. 

esc를 누르고 :wq 명령어로 저장 후 나온다.

cat 명령어로 스크립트가 잘 작성되었는지 확인한다. 

 

명령어를 입력하여 k6로 부하테스트를 시작한다.

K6_WEB_DASHBOARD=true k6 run script.js 

요청수가 늘어나면서 부하가 발생한다.

VUs -> virture users

(k6-server 의 아이피주소):5665 를 입력하면 대시보드로 테스트 화면을 확인할 수 있다. 

 

 

가상 유저수가 올라가면서 변하는 수치들을 확인할 수 있다.


10분동안 6000명의 가상 유저수에 도달할 때까지 부하를 늘려나가고 있는 형태를 볼 수 있다.

 

 

HTTP Request Rate : 1초당 처리되는 HTTP 요청 수 (= throughput)

ex) 3.44k/s
해당 시점에서 초당 약 3,440개의 요청을 처리하고 있다는 뜻이다.

 

 

HTTP Request Duration : 평균 응답 시간 (=latency)

ex) 208ms

HTTP Request Failed : 요청 실패

요청이 실패한다면 왜 요청이 실패했는지 체크해보고 디버깅해야 한다.

 

 

 

체크할 점 

1)
그래프의 흐름을 보면 가상 유저수는 계속 증가하나, HTTP 요청 수(throughput)는 더이상 증가하고 있지 않음. 더이상 증가하지 않는 throughput이 현재 시스템의 최대 throughput 이다.

ex. 현재 시스템의 최대 throutput은 3,600 TPS이다. 

2) 
요청당 응답하는 시간이 비이상적으로 높을 경우 문제가 있는 것은 아닌지 체크해야 한다.
가상 유저수가 올라감에 따라 응답시간이 점점 증가한다.
HTTP Request rate (throughput)은 증가하는데 시스템이 처리할 수 있는 한계량은 정해져 있기 때문에 대기 시간이 증가하여 latency가 늘어나는 현상이 나타난다. 

3) 
요청이 실패한다면 왜 요청이 실패했는지 체크해보고 디버깅해야 한다.


throughput이 더이상 증가하지 않는 순간까지만 부하테스트를 진행한다. 그 결과값을 가지고 해석하면 된다. 

 

 

+ 

 

테스트가 끝난 후 비용이 발생할 수 있으니 사용하지 않는 EC2 인스턴스는 종료하도록 한다.

 

 

 

 

 

 

 

 

 

참고

 

https://www.youtube.com/watch?v=X_g0xP5TvZ8&list=PLtUgHNmvcs6qAqWz-UhH-_ploSbK2eHwG&index=8