nGrinder를 이용해 Login API 성능 테스트 후 Scale-Up을 적용하여 성능 개선 - (2)

 

들어가기에 앞서, 이전 글에서는 가상 접속자가 1000명일 때의 상황에서 성능 테스트를 진행하여 보았는데요, Scale-out을 적용한 뒤 로드밸런싱에 의해 트레픽 부하가 분산되어 더 좋은 성능을 가진 서버로 개선된 것을 확인할 수 있었습니다.  

 

하지만 본 프로젝트는 접속자 수를 최대 1000명으로만 한정지어 놓은것이 아니기 떄문에, 가상 접속자가 3000명일 때의 환경에서도 성능 테스트를 진행하였는데요,

 

가상 접속자가 3000명인 상황을 대비하여 성능 테스트를 통해 사전에 시스템 장애를 확인하고 서버의 성능 튜닝하였습니다. 아래에서 확인해보도록 하겠습니다.

🔍 가상 접속자가 3000명일 때의 성능 테스트 후 성능 개선

1. 부족한 worker_connection으로 인해 CPU 사용률이 낮아 테스트 실패

현재는 Scale-out 적용된 상태이고 이전 글에서 확인했던 가상 접속자 1000명인 경우와 비교하여 3000명일 때는 어떤 테스트 결과가 나오는지 성능 테스트를 진행하여 보았습니다.

 

nginx 서버 공인 IP로 진행한 성능 테스트

가상 접속자 3000명으로 테스트 했을때, 정말 많은 오류가 발생하여 테스트에 실패하였습니다. 하지만 nginx 서버의 공인 IP가 아닌 그냥 단일 WAS 서버 한 대의 공인 IP로만 테스트를 진행 하였을때는 아래처럼 테스트에 성공을 하였엇는데요,

단일 WAS 서버 공인 IP로 진행한 성능 테스트

그래서 저는 nginx 서버에서 부하를 감당하지 못하고 있다고 생각하여 nginx 서버의 cpu 사용률을 확인해보았는데 8% ~ 10% 밖에 안되는 사용률 확인할 수 있었습니다. 따라서 CPU 사용률을 올려서 위의 문제를 해결 해야겠다는 생각이 들었습니다.

1-2. worker_connection의 수를 늘리는 튜닝을 진행하여 CPU 사용률을 높힘으로써 테스트 성공

문제를 해결하기 위해 nginx 공식 문서를 살펴보았는데요, 

 

 

worker_connection 값을 튜닝해서 CPU 사용률을 높여 위의 문제를 해결해봐야 겠다는 생각이 들었습니다.

 

위의 공식 문서를 보면 worker_connection의 기본 값은 512라고 적혀있었습니다. 그리고 현재 제 nginx 서버는 두 배 큰 1024로 worker_connection이 설정되어 있습니다. 공식 문서에서 언급한 것보다 2배 더 큰 값으로 설정이 되어있었지만, 위의 문제가 발생했던 것이죠.

 

하지만 위의 공식 문서에 설명되어 있듯이 "대부분의 시스템에서는 더 많은 수를 지원할 수 있는 충분한 리소스가 있다." 라고 설명이 되어있엇기 때문에 과감히 worker_connection의 값을 2048까지 4배 늘려보았습니다.

sudo vi /etc/nginx/nginx.conf

그리고 다시 테스트를 진행해보았습니다.

테스트는 성공하였고,

가상 접속자 3000명 기준	초당 처리 가능한 요청인 피크 TPS	평균 테스트 시간
로드밸런싱이 적용된 nginx 서버	2670 TPS	1660ms

위와 같은 성능테스트 지표를 확인할 수 있었습니다.

 

또한 worker_connection이 1024 였을 때 nginx 서버의 CPU 사용률은 10%였던 것에 비해 worker_connection을 2048로 올렸을 때, nginx 서버의  CPU 사용률이 20%, 즉 두 배 가량 증가한걸 확인할 수 있었습니다. 

그리고 확실히 가상 사용자 1000명으로 테스트(2700 TPS, 230ms) 했을 때 보다는, 평균 테스트 시간이 훨씬 오래걸린 것을 확인할 수 있섭니다.

 

하지만 저는 여기서 좀 더 실험해보고 싶은것이 생겼습니다. 바로 Scale-Up이였는데요,

 

현재까지는 Scale-out을 적용했을 상황만 실험해보았기 때문에, 이번에는 Scale-Up을 적용하여 더 얼마나 더 좋은 지표를 얻을 수 있을지 확인해보았습니다.

2. Scale-up 적용

현재 nginx 서버의 스펙은 2vCPU, 4GB Mem, 50GB로 구성하였는데요, 기존 보다 CPU 코어 갯수를 두 배로 늘린 4vCPU, 4GB Mem, 50GB로 서버 스펙을 업그레이드 하는 Scale-up을 적용하고 다시 테스트를 진행해보았습니다. 

 

그리고 아래와 같은 Scale-up을 적용하기 전, 후의 차이를 아래와 같이 확인해 볼 수 있엇습니다

 

가상 접속자 3000명 기준	초당 처리 가능한 요청인 피크 TPS	평균 테스트 시간
Scale-up 적용 전 (2코어)	2670 TPS	1660ms
Scale-up 적용 후 (4코어)	3730 TPS	1360ms

 

확실히 Scale-up을 적용했을때 초당 처리 가능한 요청인 피크 TPS는 증가하고, 평균 테스트 시간은 감소한 것을 확인 할 수 있었습니다.

 

따라서 가장 빠른 서비스를 위해서는 서버를 확장하는 방식인 Scale out과 더불어 서버의 스펙을 업그레이드 하는 Scale up 방식을 모두 적용하는 것이 가장 효율적이라는 것을 확인하였습니다.

3. 가상 접속자가 3000명일 때, Scale-out 적용 전, 후 비교

이전 글에서 가상 접속자가 1000명일 때 Scale-out 적용 전 or Scale-out 적용 후의 차이를 비교하여 보았고, Scale-out을 적용했을 때가 조금 더 개선된 성능을 보여주는 것을 확인했었습니다. 하지만 그 성능의 차이가 엄청 크진 않았는데요, 그래서 이번에는 가상 접속자가 3000명일 때의 환경에서 한 번더 비교해보았습니다.

 

Scale-out이 적용되기 전 환경의 성능 테스트 지표입니다.

위의 성능 지표를 토대로 가상 접속자가 3000명일 때의 Scale out 적용 전, 후의 차이를 표로 작성하여 보았습니다.

가상 접속자 3000명 기준	초당 처리 가능한 요청인 피크 TPS	평균 테스트 시간
Scale-out 적용 전	1750 TPS	2190ms
Scale-out 적용 후	3730 TPS	1360ms

가상 접속자가 1000명 일 때의 환경에서 테스트 해보았을 때의 차이보다, 가상 접속자가 3000명 일때의 환경에서의 차이가 더욱 크다는 것을 확인할 수 있었습니다.

🔍 마지막으로

이렇게 nGrinder를 이용해 성능 테스트를 진행해보면서 여러가지 성능 지표를 확인해 보았습니다.

 

배포 전, 미리 부하를 주고 테스트 해본 후, 성능 지표를 활용하여 서버의 성능 튜닝을 함으로써 실제 운영시 많은 사용자의 접속으로 인해 예상하지 못했던 문제들을 사전에 방지할 수 있게 되었습니다. 

 

지금까지 확인한 성능 지표에 더불어, 앞으로 쿼리 실행 계획 및 Pinpoint 서버 구축 후 GC, 힙 메모리 크기 등의 튜닝을 진행하여 더욱 개선된 서버의 성능으로 리팩토링 할 수 있는데요, 

 

다음 글에서는 쿼리 실행 계획 및 Pinpoint를 통해 더욱 개선된 서버의 성능으로 리팩토링 하는 과정을 작성해보도록 하겠습니다.

 

긴 글 읽어주셔서 감사합니다. 전체적인 프로젝트의 상황을 확인해보시려면 아래를 참고해주시면 될 것 같습니다.

https://github.com/f-lab-edu/black-postoffice

GitHub - f-lab-edu/black-postoffice: 익명으로 편하게 고민, 일상을 공유하는 소셜 네트워크 서비스입니