[nGrinder] 서버 부하 테스트 진행 (SpringBoot)

 

 

 

세팅과 스크립트 설정이 모두 끝났으니 테스트를 진행해 보자

📌 서론

이전 포스트를 통해 테스트에 사용할 스크립트까지 작성을 완료했다.

자바 버전 때문에 발생한 오류로 조금 고생했지만 간단하게 해결되었고 JMeter에 비해 훨씬 우수한 UI와 사용성으로 세팅 자체가 너무 즐거웠다.

오늘 포스트에서는 지금까지 열심히 세팅한 nGrinder를 통해 로컬 환경(Mac OS)에 띄운 SpringBoot서버 테스트를 진행해 본 결과를 공유하고자 한다.

 

1.  성능 테스트 생성

상단의 "성능 테스트" 메뉴를 누른다.

• 테스트를 생성하는 페이지로 이동된다.
• 이동된 페이지 우측의 "테스트 생성" 버튼을 클릭한다.

성능 테스트 들어가기

테스트 생성하기

• 아래와 같이 테스트를 세팅하는 화면으로 이동된다.
• 가장 먼저 "테스트명"과 설명을 적어줬다.

테스트 설정하기

이제 테스트의 기본 설정을 한다. 아래와 같이 세팅해 줬다.

• 에이전트: 1대
• 테스트 유저: 99명
• 스크립트: 내가 생성한 "레시피 상세 조회" 스크립트 (이전 포스트에서 작성)
• 테스트 시간: 1분

테스트 기본 설정

다음으로 우측에 있는 "Ramp-up 사용"이라는 메뉴를 설정한다.

• 여기서 설정하는 것은 다음과 같다.
• 테스트 유저를 적게 시작하고 그 수가 점점 늘어나서 테스트 종료에 가까워질수록 유저가 증가하도록 한다.
  (1초마다 테스트 유저를 증가시키도록 주기를 1000ms으로 설정했다.)

Ramp 설정

2.  성능 테스트 진행

작성한 테스트를 저장하고 실행했다. 여기서 2가지의 용어를 알고 결과를 확인하면 이해가 쉽다.

TPS(Transactions Per Second)

• 부하 테스트를 통해 시스템이나 애플리케이션에 동시에 다수의 요청을 보냈을 때, 해당 시스템이나 애플리케이션이 초당 얼마나 많은 요청을 처리할 수 있는지를 나타내는 데 사용된다.
  
• 처리량이 높을수록 더 많은 요청을 효율적으로 처리할 수 있다는 것을 의미하기 때문에, 일반적으로 TPS가 높을수록 시스템의 성능이 좋다고 평가된다.
  
  

Mean Test Time(평균 응답 시간)

• "Mean Test Time"은 부하 테스트에서 평균 응답 시간을 말한다. 이 지표는 시스템이 요청을 처리하고 응답하는 데 걸린 시간의 평균값을 나타낸다. 사용자 경험에 중요하며, 응답 시간이 짧을수록 좋다.

테스트 결과 확인

테스트가 1분 동안 실행된 후 다음과 같은 결과를 보여줬다.

• 요약을 자세히 보면 총 실행 테스트가 약 76000개인데 성공이 51000, 실패가 25000개 정도인 것을 볼 수 있다.
• 70%의 성공률을 보이는데 이것 자체가 문제라고 생각했다. 유저가 10번 요청하면 3번은 실패한다는 의미이기 때문이다.

테스트 완료

보고서 하단에 있는 결과 로그를 다운로드했다.

• 로그는 다운로드하고 압축을 풀면 확인할 수 있다.

결과 로그 다운로드

다운로드한 로그를 열어서 분석했다.

• 로그에 있는 모든 에러가 동일하게 401인 것을 확인할 수 있었다.
• 401은 시큐리티 에러인데 왜 이런 문제가 발생할까?
• 분명 나는 Header에 access토큰을 넣어줬고 토큰의 유효기간은 30분으로 설정되어 있을 텐데 이런 문제가 발생했다.

에러 로그 분석하기

테스트 상세 보고서 확인하기

• 로그만으로는 분석하기에 힘들다는 생각이 들었고 ngrinder에서 제공하는 상세 보고서를 확인했다.
• 상세 보고서는 테스트 결과 그래프 상단에 있는 "상세 보고서" 버튼을 누르면 나온다.

상세 보고서 확인하기

상세 보고서 맨 하단의 "오류" 항목 그래프를 확인했다.

• 그래프 결과에 따르면 48초 이전까지는 오류가 하나도 없다가 50초 정도부터 급격하게 발생한다.
• 이걸 보며 혹시 jwt 인증 시간 설정을 잘못했나? 이런 생각이 크게 들었다. 이전까지는 단 하나의 실패도 없었기 때문이다.

오류 그래프 확인

문제 해결의 핵심은 치솟은 그래프의 시간이었다.

• 역시 시각화가 중요하다. 그래프가 특정 시간이 지난 후 치솟은 것으로 보아 access Token의 유효시간이 문제였을 것이라 판단하고 코드를 확인했는데 로컬 환경에서는 재발급 테스트를 위해 유효시간을 30초로 해뒀던 것을 발견했다. (항상 주의하자)
  
• 다시 토큰 유효시간을 30분으로 수정하고 테스트를 돌렸더니 결과는 대성공이었다. 아래와 같이 모든 요청이 성공했다.

다시 진행한 테스트

100명은 무난히 성공했으니 2000명이 사용한다고 가정하고 테스트를 진행했다.

• 이전까지의 테스트는 100명이었다. 2000명까지 부하를 올려보면 어떻게 될까?
• 새롭게 설정한 에이전트별 가상사용자, 프로세스, 스레드는 다음과 같다. (아래의 계산대로 사용자가 설정된다.)
  • 사용자(2000) = 프로세스(10) * 스레드(200)

2000명으로 부하 설정

2000명으로 테스트해 본 결과는 다음과 같다.

• TPS는 100명일 때와 엄청나게 큰 차이는 나지 않았다.
• 최고 TPS 기준으로 100명일 때는 762였는데 2000명일 때는 815가 나왔다. (M2 Max 성능이 좋아서 그런 것 같다.)
• 신기했던 건 부하가 많아지니 최고 TPS가 약간 높아졌다.(성능이 좋아졌다.) 그리고 아주 적은 비율이지만 오류도 발생했다.
• 작성하면서 생각해 보니 내가 테스트 시간을 동일하게 설정했어야 더 확실한 결과를 얻었을 것이라는 생각이 들었다.
  (테스트의 유의미한 결과를 얻기 위해 시간을 1분보다 길게 설정하는 게 좋을 것이라는 생각도 들었다.)

부하 2000명 테스트 결과

결과를 리스트로 봤을 때는 다음과 같이 보인다.

• 에러율이 거의 0%에 가까운 것을 알 수 있다.

성능 테스트 목록

 

이제부터가 진짜다. AWS에 올린 레시피아 ECS클러스터의 SpringBoot 부하 테스트가 남았다.
로컬 Mac을 통해 사용방법을 간단히 익혀봤으니 이제부터는 AWS에 올린 서버에 있는 모든 api를 테스트해 볼 생각이다.
SNS, SQS를 사용하는 요청과 실패 시 보상처리로 동작할 배치의 로직도 존재하기에 이 모든 것이 제대로 상호작용하여 동작하는지 볼 수 있다는 마음에 더더욱 기대가 된다.

 

 

다음 포스트를 통해 상용 서버의 부하 테스트 결과를 확인해보자

[nGrinder] ECS로 기동중인 SpringBoot 부하 테스트

함께 레시피아를 개발 중인 "평양냉면"님의 블로그도 한번 들려주세요! 좋은 글이 많습니다.

하다보니 재미있는 개발