일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Real MySQL
- gradle
- SpringBoot
- jvm
- mysql
- 보조스트림
- IntellJ
- 스프링
- thread
- 자바
- 자바 ORM 표준 JPA 프로그래밍
- list
- Stack
- 토비의 스프링 정리
- spring
- 백준
- redis
- 토비의 스프링
- OS
- JPA
- Collection
- 쿠버네티스
- Java
- 스트림
- K8s
- Stream
- Kotlin
- 이스티오
- MSA
- GC
- Today
- Total
인생을 코딩하다.
nGrinder를 이용해 Login API 성능 테스트 후 scale-out을 적용하여 성능 개선 - (1) 본문
이 글을 읽기 전, 리눅스 서버에 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
'Infra' 카테고리의 다른 글
nGrinder를 이용해 Login API 성능 테스트 후 Scale-Up을 적용하여 성능 개선 - (2) (0) | 2021.08.26 |
---|---|
리눅스 서버에 ngrinder 설치하기 (0) | 2021.08.09 |
[Infra] 젠킨스와 슬랙 연동하여 알림받기 (0) | 2021.07.12 |
[Infra] 젠킨스란? 젠킨스를 이용해 CI 자동화하기 (3) | 2021.07.11 |
[Infra] CI란?, 어떤 CI 도구를 사용할까? (0) | 2021.07.09 |