인생을 코딩하다.

nGrinder를 이용해 Login API 성능 테스트 후 scale-out을 적용하여 성능 개선 - (1) 본문

Infra

nGrinder를 이용해 Login API 성능 테스트 후 scale-out을 적용하여 성능 개선 - (1)

Hyung1 2021. 8. 9. 01:21
728x90
반응형

 

이 글을 읽기 전, 리눅스 서버에 ngrinder 설치하기를 참고해주시면 좋을 것 같습니다.

🔍 내가 만든 서비스는 얼마나 많은 사용자가 이용할 수 있을까?

저는 Black-postoffice가 실제 서비스로 출시되었다고 가정했을때, 지속적인 수익 창출을 원하고 그러기 위해서는 사용자들에게 서버가 멈추지 않고, 더욱 빠른 서비스를 제공해드려야 한다고 생각합니다. 따라서 성능 테스트가 꼭 필요한데요,

nGrinder는 서버에 대한 부하를 테스트 하는 것이므로 서버의 성능 측정이라고도 할 수 있습니다. 성능 측정이란 것은 실제 서비스에 투입되기 전, 실제와 같은 환경을 만들어 놓고 서버가 사용자를 얼만큼 수용할 수 있는지를 실험할 때 사용됩니다.

성능 테스트를 하지 않았을 떄의 큰 위험을 한 예로 들어보면,

제가 동시 접속자를 1000명 정도로 예상하고 이에 맞는 설정을 구성하는데 예상에 넘는 동시 접속자가 발생해버리면 서버가 죽어버려 서비스를 할 수 없는 문제가 생길 것 입니다. 이것은 지속적인 수익 창출을 보장할 수 없는 일이겠죠

이를 방지하기 위해 본 서비스에 앞서 테스트를 해 서버의 성능을 테스트 하는 것 입니다.

따라서 현재 프로젝트의 성능 지표가 있어야하고, 성능 지표를 확인한 후 병목 지점을 찾아 지속적으로 리팩토링을 해야한다고 생각하는데요, 이번 글에서는 서비스의 성능 지표를 확인하기 위해서 부하를 발생시키는 방법과 또한 Black-postoffice 서비스의 로그인 API에 실제 부하를 발생시켜서 단위 성능 테스트를 진행하고 Black-postoffice 서비스의 로그인 API의 현재 성능을 분석해보도록 하겠습니다.

🔍 가장 먼저 성능테스트를 위한 스크립트를 작성해야 합니다. ngrinder 메인 화면에서 스크립트 생성 화면으로 이동합니다.

1. Create 버튼을 누른 후 Create a Script를 눌러줍니다.



2. 성능 테스트를 원하는 URL 입력하고, 아래 사진처럼 body에 데이터를 넣어서 보낼수도 있습니다.

 

3. 자동으로 만들어진 groovy 코드를 환경에 맞게 적절히 수정하고 오른쪽 상단에 [검증] 버튼을 눌러 정상적으로 작동하는지 확인하고 저장버튼을 클릭합니다.

 

4. 스크립트문 작성이 완료되었으면 성능 테스트 페이지로 이동해 테스트 생성 버튼을 클릭합니다. 가장 먼저 로그인 테스트를 진행을 해보도록 하겠습니다

5. 에이전트 수를 입력하고, 몇 명의 가상 접속자로 부하 테스트를 진행할지 선택합니다. 또한 비교적 정확한 평균 수치를 산출해내기 위해 테스트 기간은 10분 이상으로 잡는 걸 추천드립니다.

모든 설정을 완료하고 오른쪽 상단에 [save and start] 버튼을 클릭하면 테스트가 시작됩니다.

 

6. 여기서 잠깐 주의사항이 있습니다. nGrinder는 agent간 통신을 위해 여러 포트를 사용합니다. 아래의 포트들이 방화벽에 걸리지 않는지 확인하고, 걸린다면 해당 포트들을 사전에 열어놓습니다.

  • Agent: Any ==> Controller: 16001
  • Agent: Any ==> Controller: 12000 ~ 12000+(동시 테스트 허용수만큼)
  • Controller: Any ==> Monitor: 13243
  • Controller ==> Public user: 톰캣 설정에 따르지만 기본은 8080입니다.

이제 본격적으로 성능테스트를 진행해보겠습니다. 현재 서버들은 아래와 같이 구성되어 있습니다.

  • WAS 1 : [Compact] 2vCPU, 2GB Mem, 50GB Disk
  • WAS 2 : [Compact] 2vCPU, 2GB Mem, 50GB Disk
  • Nginx : [Standard] 4vCPU, 4GB Mem, 50GB Disk [g1]
  • MySQL Master : [Compact] 1vCPU, 2GB Mem, 50GB Disk
  • MySQL Slave : [Compact] 1vCPU, 2GB Mem, 50GB Disk
  • Login Session 저장소(Redis) : [Compact] 1vCPU, 2GB Mem, 50GB Disk
  • Controller Server : [Standard] 2vCPU, 4GB Mem, 50GB Disk [g1]
  • Agent Server : [Standard] 4vCPU, 8GB Mem, 50GB Disk [g1]
  • Jenkins : [Compact] 1vCPU, 2GB Mem, 50GB Disk
  • AWS S3 : AWS 프리 티어 (이미지 저장 기본 50GB)

저는 현재 진행하고 있는 멘토링 F-Lab에서 성능 테스트를 위해 네이버 클라우드 플랫폼에서 사용할 수 있는 크레딧을 제공받았기 때문에 네이버 클라우드 플랫폼에서 위 서버들을 생성하였습니다.

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

1. Scale-out 적용 전

nginx 서버를 띄우고 한 대의 WAS 서버로만 구성된 환경이였을 때의 성능 테스트 지표입니다.

전체적인 결과도 중요하지만 저에게 가장 필요한 데이터는 초당 처리 가능한 요청인 피크 TPS 평균 테스트 시간였습니다. Black-postoffice 서비스가 한대의 WAS 서버만으로 구성된 환경일 때, 서비스는 가상 접속자 1000명 기준, 2100 TPS 처리량을 갖고, 테스트 요청당 370ms의 지연시간이 걸린다는 것을 알 수 있습니다. 오류는 0으로써 테스트는 100%의 성공률을 기록하였습니다.

 

테스트 진행 중 약 5분이 흘렀을때, WAS 서버의 cpu 사용률도 한 번 확인해 보았습니다. 현재 WAS 서버는 2개의 코어를 가진 스펙을 가지고 있는 상태구요, CPU도 (2개의 코어 = 200) 184, 즉 92% ~ 100% 사이의 CPU 사용률을 보여줌으로써 CPU 활용을 잘 하고 있다는 것을 확인하였습니다.

2. Scale-out 적용 후

nginx 서버에서  대의 WAS 서버로 적용된 로드밸런싱 환경일 때의 성능 테스트 지표입니다. 저는 위의 상황보다 더 빠른 서비스를 사용자들에게 제공하기 위해, 이번엔 nginx 서버에서 두 대의 WAS 서버로 로드밸런싱을 통해 적절하게 부하를 분산시키도록 Scale-out 방식으로 서버 확장을 진행하였습니다.

이렇게 확장된 서버의 환경에서 가상 접속자 1000명으로 테스트를 진행해보았습니다.


가상 접속자 1000명 기준으로 테스트 하였을때, 약 2700 TPS 처리량을 갖고, 스트 요청당 230ms의 지연시간이 걸린다는 것을 알 수 있습니다. 오류는 0으로써 테스트는 100%의 성공률을 기록하였습니다.

 

이 또한 WAS 1, 2 서버 둘 다 100%의 CPU 사용률이 확인되었고 CPU를 잘 사용하고 있다는 것을 확인하였습니다.

3. 위의 두 상황 즉, Scale-out 적용 전, 후의 차이를 비교하여 보도록 하겠습니다.

현재, 두 대의 WAS 서버 모두 동일한 스펙을 가지고 있습니다.

가상 접속자 1000명 기준 초당 처리 가능한 요청인 피크 TPS 평균 테스트 시간
Scale-out 적용 전 2100 TPS 370ms
Scale-out 적용 후 2700 TPS 230ms

두 대의 was 서버를 두고 요청을 로드밸런싱한 환경이, 한 대의 서버를 둔 환경에 비해 더 빠른 것을 볼 수 있는데요,

이렇게 실제로 가상 접속자 1000명의 부하를 주는 테스트를 해봄으로써 한 대의 서버를 둔 환경보다 서버를 확장하는 Scale-out 방식을 적용할 때, 좀 더 많은 처리량과 빠른 속도를 직접 확인할 수 있었고, 대용량 트레픽 환경에서 더 좋은 서비스로 리팩토링 할 수 있게 되었습니다.

 

하지만 위는 가상 사용자 1000명만을 기준으로만 비교한 수치이기 때문에 현재보다 더 많은 트레픽의 부하를 주고 장애 발생여부를 테스트 해봐야 될 것 같습니다.  다음 글(nGrinder를 이용해 Login API 성능 테스트 후 Scale-Up을 적용하여 성능 개선 - (2))은 가상 사용자 3000명 기준으로 성능 테스트를 진행해보고, 더 나은 성능으로 개선하는 과정을 작성해보도록 하겠습니다.   

 

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

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

 

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

익명으로 편하게 고민, 일상을 공유하는 소셜 네트워크 서비스입니다. Contribute to f-lab-edu/black-postoffice development by creating an account on GitHub.

github.com

 

 

 

 

728x90
반응형
Comments