Ngrinder를 이용하여 성능 테스트 하기

회사의 무궁한 발전을 기원하며! 100만 동접을 대비하기 위해 서버의 성능을 측정해 보았다.

구성

• 인스턴스 구성

  • aws에 구성하였다.
  • core 1대 * agent 5대

• 테스트 스크립트

  • groovy gradle project를 이용하여 스크립트를 작성하였다.
    • 테스트 할때 필요한 의존성 라이브러리를 추가할 수 있다.

• 테스트 서버

  • dev zone에 있는 테스트 서버를 대상으로 하였다.
  • 테스트 서버는 라이브와 동일한 스팩으로 구성하였다.
  • 테스트서버는 load balancer에 연결 되어 있고, 서버 인스턴스 10대, db, redis에 연결되어 있다.

테스트 결과

• tps 17000정도 나왔다.
  • 생각보다 낮은 tps에 당황
• 테스트 도중 예상하지 못했던 에러가 발생 하여 서버 튜닝을 함께 진행하였다.

해결한 이슈

• 파일 open 개수 예외 발생

  • file open limit 을 4096 에서 300000개로 증가하였다.(라이브 서비스 하는데 4096개라니...)
  • 검색 해 보니 서버 다운 없이 설정할 수 있었다.

• spring boot async threadpool 예외 발생

  • 테스트 시작 후 1분 후 쯤 부터 thread pool 예외가 발생하여 threadpool 개수를 증가시켰다.

• redis 입력 시 병목 현상

  • redis 에 item을 생성하는 부분에서 딜레이가 발생하여(단순히 주석 처리 후비교하였다.) redis shard를 증가시켰다.
  • 2 shard * 3 node 에서 3shard * 3 node로 증가
  • 전체 tps에 미치는 영향은 미미하였다.(10프로 남짓 증가)
  • elasticache를 사용하고 있는데 버전 3.10.2부턴가 무중단 shard 증가가 가능하다고 한다.(테스트 중 샤드 늘려봤는데 tps에 영향 안줌)
  • redis connector 라이브러리를 변경해보려 했으나 spring boot 버전이 낮아 적용하지 못하였다.

• CUSTOM_EXCEPTION 예외 발생(팀 내부에서 정의한 예외)

  • 가끔 게임이 점검에서 풀려 요청이 몰릴 때 에러가 급증하는 현상이 있었는데, 지금까지는 잘못된 요청으로 취급(해왔다고) 했으나
  • 정상적으로 파라미터 세팅해서요청 했을 때도 동일하게 발생함.
  • 원인을 분석 해보니 request 처리 할 때 사용하는 라이브러리에서 동시성 이슈가 발생하고 있었다.
  • 필요한 객체를 함수 내부에서 생성하도록 변경하여 해결
    • 아주 나이스한 해결방법은 아닌것 같지만
    • single thread로 동시성 이슈 발생하지 않도록 설정한 후 테스트 해본 결과 10만회 수행 시 기존 방식과 10ms 차이로 미미한 차이를 보였음

정리

• tps 17000정도면 1분당 request를 102만개 처리할 수 있는 수준인데... 서버 인스턴스나 여타 인프라의 스팩을 고려해보면 생각보나 낮은것 같다.
• 테스트 스크립트를 groovy gradle project를 이용하면 의존성 라이브러리를 추가하여 사용할 수 있다.(삽질 너무많이 함 ㅠ)
• 빨리 쿠베 도입하고 msa구조로 변경하고 싶다