[Infra] nGrinder API 성능테스트 세팅 삽질 기록

사내에서 API 성능 테스트를 위해 ngrinder를 이용했는데, 약간의 삽질로 인해 제대로 된 성능테스트가 진행되지 않았다.

이유는 너무 간단하지만, 그냥 기록 차 블로그에 남겨본다.

 

nGrinder 성능 테스트 진행 방법은 아래 글을 참고하자.

https://kth990303.tistory.com/446

[Infra] nGrinder 성능 테스트 입문일지 (스크립트 추가)

---

nGrinder 성능테스트 진행 과정

상황

• 요청이 순차적으로 매우 빈번하게 호출될 것으로 예상되는 API를 개발하였으며, 운영배포 전에 테스트가 필요해보였음.
  • 따라서 운영환경에 맞게 API 서버 spec up 진행.
• 해당 API에서 사용하는 쿼리 역시 굉장히 오래 걸릴 것으로 예상.
  • 쿼리튜닝 및 인덱스는 최적으로 맞추었다고 가정. 따라서 해당 포스팅에서 쿼리 관련 성능테스트는 제외한다.
    
    • 따라서 DB scale up은 별도로 진행하지 않음.

 

결과

• user 1 * count 10000 과 같이, 가상 사용자 수가 적은 테스트는 tps 및 CPU 부하를 확인할 수 있었음.
• user 1000 * count 10 과 같이, 가상 사용자 수가 많은 테스트는 아래 에러 발생하면서 500 에러 발생
  • 참고로, 예상 수치 상으로 CPU나 메모리가 충분히 견딜 만한 부하이다. 테스트 세팅을 잘못해서 이 결과가 나온 사례를 소개하려 하는 것이다.

 

 

Could not open JPA EntityManager for transaction; nested exception is org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection

Hikari - Connection is not available, request timed out after 3000ms.

---

원인

• 커넥션이 부족하여 발생한 에러이며, DB 커넥션 수 부족으로 인해 발생한 것으로 보임. 서버 scale up 뿐 아니라, DB Scale Up을 진행한 후 성능테스트를 진행해야 할 것으로 보임.
• DB 커넥션 수 조정, 서버 hikari 커넥션풀 설정값 조정 관련 확인이 필요해보임.
  • 성능테스트를 위한 스펙업 시, EC2 RDS 인프라 스펙 변경 뿐 아니라 maxPoolSize, maxThreads 값 등의 조정도 필요해보임. (젠킨스 환경변수로 넘겨주든, 도커 컴포즈 파일을 바꿔주든, yml 파일을 바꿔주든.)

---

대응 결과

영향을 받는 모듈의 maxThreads, maximumPoolSize 값을 조정해주고, ec2 및 rds scale-up을 진행해주었다. 

 

그리고 EC2 수명주기가 spot, 즉 스팟인스턴스인 경우 scale up에 어려움을 겪을 수 있다. 따라서 EC2 수명주기를 정상 (온디맨드) 로 변경하고 scale up 하는 것을 추천한다.

 

• EC2 spot instance인 경우, 사용량이 적을 때 중단될 수 있다. 이를 막기 위해 ASG에서 ec2 spec을 자동으로 관리되게 설정할 수가 있는데 (참고: https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups-instance-weighting.html) 이러한 경우에 scale-up에 어려움을 겪을 수 있다.

Configure an Auto Scaling group to use instance weights - Amazon EC2 Auto Scaling

 

• 따라서 스펙업을 위해선 일시적으로 EC2 설정을 온디맨드로 바꾸는 것을 추천한다. EC2 aws console에서 바꿀 수도 있고, ci/cd 에서 변경할 수도 있다. (jenkinsfile groovy 설정 변경 등)

 

 

성공적으로 진행된 성능테스트

 

 

스펙업 및 설정 조정을 해주고 나니, 커넥션 부족 이슈로 인한 500 에러는 사라졌다.

(물론 진짜 부하가 심한 경우에는 500 에러 발생하고 서버가 뻗는 게 맞지만, 현재 부하는 그 정도는 아닌 것으로 가정한다.)

가끔 커넥션을 못얻었다는 에러가 발생하긴 했지만, 서버가 뻗어버리는 일까진 발생하지 않은 것.

 

운영환경에서 직접 부하테스트를 못하기 때문에, (개발)베타환경의 서버 스펙업 및 데이터 세팅을 진행하는 경우에는 ec2, rds scale-up 뿐 아니라 코드 단의 maxThreads, maximumPoolSize 까지 조정해주자.