성능 테스트 시 고려할 점

성능테스트는 알면 알수록 끝이 없지만 오늘은 기본적인 것만 정리하려고 합니다.

성능테스트에 어떻게 접근할지 모르겠는 분들에게 도움이 되었으면 좋겠습니다.

 

성능테스트 목적

성능 테스트의 목적은 목표를 어떻게 잡느냐에 따라 애플리케이션의 수정 정도와 인프라적 요소들의 범위가 달라지는 것 같습니다.

내가 만든 애플리케이션이 얼마나 버티느냐, 어느정도의 성능을 낼 수 있을까. 라는 너프한 목적으로 할 수도 있고

이러한 목적을 베이스로 하고 좀 더 뚜렷한 목표가 있다면 난 5000명의 유저를 수용할 수 있는 성능을 목표로 하고

이 목표에 맞춰서 내 애플리케이션 성능을 수정해나갈거야. 라고 목적을 잡을 수도 있습니다.

첫번째는 성능테스트를 진행하면서 어느정도 성능을 높이기 위해 코드 수정, DB Connection조정, 로그 레벨 조정, 인프라 장비의 크기 조정등을 어느정도 모두 진행하였을 때 인프라 스펙 어느정도에 동시접속자수 몇 명을 수용할 수 있고, TPS성능은 어느정도 나옵니다. 라고 할 수 있고

두번째는 성능테스트를 진행하면서 위의 내용들을 모두 진행한 뒤에도 목표점이 나오지 않는다면 코드구현을 다시 하거나 캐시를 쓰거나 좀 더 구조적인 변경이 필요할 수 있습니다.

하고자 하는 말은 애플리케이션의 성격에 따라 필요로 하는 성능이 있을 수 있고, 애플리케이션의 성격과 목적을 정하고 성능테스트를 진행하면 성능을 보완하고 성능의 목표점을 찾는데 더 도움이 되지 않을까 하는 것입니다.

그러므로 성능테스트의 목적을 정하고 성능테스트를 진행한다면 더 좋을 것입니다.

 

성능테스트 도구

성능테스트를 위한 도구로는 많은 개발자가 사용중인 JMeter, Ngrinder가 있고 최근 많이 사용중인 Locust가 있습니다.

좀 더 다양한 성능테스트 도구들이 있겠지만 제가 써본 것은 이 세가지입니다.

저의 경우는 초반에 JMeter를 사용했고, 근 4년간은 Ngrinder를 사용했고, 최근에는 Locust를 사용했습니다.

JMeter와 Ngrinder는 분명 많은 개발자들이 사용하는 도구이므로 장점들이 많습니다.

Locust의 경우에도 설치가 간편하고 사용법도 쉽기 때문에 러닝커브가 적은 장점이 있는 것 같습니다.

 

• JMeter: https://jmeter.apache.org
• Ngrinder: https://naver.github.io/ngrinder
• Locust: https://locust.io

 

- 성능테스트 도구와 함께 사용하면 좋은 것.

: 성능 테스트 시, 배포 서버의 터미널 화면만 보기에는 한계가 있기 때문에 모니터링 도구를 함께 사용하면 어느 부분에서 에러가 발생하고 문제가 있는지 쉽게 확인 할 수 있습니다.

• Pinpoint, Datadog과 같은 모니터링 도구

 

Application

성능테스트를 진행하면서 Application에서 아래 부분을 개선하면 성능향상에 도움이 됩니다.

• 불필요한 코드 제거 및 개선
• 로그 레벨 조정 ex) DEBUG -> INFO
• DB Connection 수 조정
• 필요하다면 캐시 추가 ex) Redis
• 이미지나 파일 관련 로직을 사용할 경우 불필요한 temp파일이 서버에 쌓이지 않도록 처리 후 꼭 제거해주도록 로직 구현
• 대량 정보를 DB에 넣거나 변경하는 로직이 있다면 개선이 필요한 부분은 없는지 꼭 확인
  • ex) 1000건의 데이터를 넣어야 할 경우 건 별로 db connection을 맺고 insert하고 다시 맺고 insert하고.. 하는 방식 보다 한 번 db connection을 맺고 데이터를 bulk insert 하는 방법이 좋음
    • 하지만 너무 많은 건수의 데이터는 너무 한 번에 처리하기보다 감당할 수준의 범위로 나뉘어 처리하는게 더 좋을 수 있음

DB

DB Table의 데이터의 양이 충분한지 확인합니다. 데이터가 충분하지 않은 경우 실 Live환경에서 성능이 달라질 수 있습니다. 예측되는 Live환경의 데이터양을 어느정도 넣어놓고 테스트를 진행해야 합니다.

 

- 성능 개선을 위해 DB Index를 생성합니다. 너무 많은 DB Index는 오히려 성능을 낮출 수 있으므로 주 사용되는 로직과 중요도에 따라 Index를 생성합니다.

 

- DB쿼리의 JOIN이 필요 목적에 따라 걸려 있는 것인지 실행계획을 확인합니다. -> DB JOIN Query (EXPLAIN)

 

Infra 환경

애플리케이션 서버 장비의 스펙과 DB 장비의 스펙 그리고 기타 외부 솔루션(ex. zookepper, redis등) 장비의 스펙 확인합니다.

ex) CPU, MEMORY, DISK, NETWORK

 

- Kubernetes 환경의 경우

• Node의 가용 스펙을 확인하고 Pod의 CPU, MEMORY가 꽉 차는지 확인. 
  request를 넘어 limit까지 차는지 확인. 
• 부하가 많을 경우 pods가 정상적으로 늘어나는지 확인. 
  replicaset늘려서 확인. (min replica / max replica) 
  
  

- Azure Kubernetes 환경의 경우

• Application Gateway 수를 늘려 확인.

 

- 서버 Auto Scaling을 사용할 경우

• Scale Out, Scale Up, Scale In이 정상적으로 이뤄지는지 확인.

 

기타

- 시나리오 step 늘려서 테스트

: 처음엔 healthcheck로 테스트 진행하다가 API 단일로 테스트 하다가 애플리케이션의 목적에 맞는 시나리오 API 호출로 테스트를 진행합니다. 유저가 주로 사용하는 패턴을 시나리오로 테스트 스크립트를 만들어 테스트 진행합니다.

ex) 로그인 -> 내정보 조회 -> 로그아웃