애플리케이션 성능 테스트 (1)

성능테스트 이유

내가 운영하고 있는 서비스는 일정한 수의 사용자가 꾸준히 사용하는 서비스가 아니다. 게임과 관련된 서비스이기 때문에 게임이 업데이트 되거나 어떤 유튜버가 서비스를 사용하고 올린 영상에 사이트가 노출되었을 때 조회요청이 올라가는 경향이 있다. 위 차트는 사용자 수를 나타내는 차트이다. 한눈에 봐도 높은 구간이 있는데, 270~80여명 정도의 사용자가 동시에 접속했고 저때 일순간이였지만 응답시간이 굉장히 느려졌다. 피크를 지난 다음에는 조금 완화되었지만 그래도 100여명 정도의 사용자가 동시접속하는 상황이 지속되면서 응답시간이 느려지는 문제가 있었다.

성능테스트를 통해서 최소한 저정도의 트래픽이 들어왔을 때 서버가 다운되지 않고 목표한 만큼의 응답시간을 내고싶었고 그러기 위해서는 웹 애플리케이션 스레드 수를 조절하거나, DB 의 커넥션 수를 조절하거나, 쿼리를 튜닝하는 등의 작업이 필수적이다. 그리고 그 원인을 찾기 위해서 성능테스트를 진행하였다.

성능을 올리는 방법으로는 스레드, 커넥션 수 조절말고도 WAS를 늘리는 Scale-out을 사용할 수 있다. 하지만 또 서버를 늘리기 비용이 부담되어 우선은 Scale-Out은 제쳐두기로 하였다. 여유가 되면 당연히 고려할것이다.

성능테스트 도구

• 성능 테스트 도구에는 nGrinder
• 모니터링에는 Grafana

응답 시간과 TPS, 그리고 CPU, 메모리 사용량 뿐만 아니라 애플리케이션 내부의 병목구간을 더 자세히 알아보기 위해서 PinPoint를 사용하는 것도 고려하였으나 JDK 버전 문제, 로컬 컴퓨터의 공유기 방화벽으로 에이전트와 서버가 원활히 통신하지 못하는 문제에 부딪혀 Grafana로 모니터링하기로 했다. 이번 성능테스트의 목적이 애플리케이션 내부의 병목을 찾거나, 데이터베이스 쿼리를 수정하기위해서가 아니라 애플리케이션 스레드 풀의 스레드 수나 DB 커넥션 수를 조절하기 위해서 이기 때문에 PinPoint에서 제공하는 디테일한 정보까지는 필요하지 않았다.

PinPoint는 애플리케이션의 구성과 각 요소들의 관계를 파악할 수 있도록 보여주고 문제발생 지점과 병목구간을 쉽게 발견하여 문제진단을 더 빠르게할 수 있도록 도와준다.

테스트 계획

튜닝 목표

목표 RPS 계산

사이트의 메인 페이지에 접속하면 사용자의 두개의 요청을 WAS에 전달하게 된다.

• 아이템의 리스트를 가져온다.
• 아이템의 인기랭킹을 가져온다.

두 가지의 요청을 처리하게 되고 지금까지 가장 높은 분당 사용자 수는 240이였다.
따라서 따라서 목표로 하는 초당 요청 수는 240의 두배인 480이 된다.

1. RPS 480일때 각 요청이 150ms 안에 제대로 된 응답을 돌려준다.
2. 문제가 없다면 서버의 최대 성능을 알아보기 위해 트래픽을 넘어서는 부하를 주어 문제가 발생하는 지점을 찾는다.

테스트 도구

성능 테스트 도구에는 K6, nGrinder, JMeter등의 도구가 있습니다.

테스트 환경

테스트 대상 서버

• GCP VM e2-small 인스턴스
  • Intel Broadwell 2코어 2.25GHz
  • 2GB RAM

에이전트 위치

서버가 위치한 망과 같은 망에 에이전트가 위치하게 된다면 네트워크에 부하가 발생했을 때 실제 상황과는 괴리가 있는 결과가 발생할 수 있습니다. 따라서 에이전트는 애플리케이션 서버가 아닌 다른 서버 로컬에 위치시켰습니다.

테스트 스크립트 작성

nGrinder 스크립트를 작성하기 위해서는 다음과 같은 요소들이 필요합니다.

1. 부하를 줄 가상 사용자 수(Vuser)
2. 부하 시간

테스트 실행

일반적으로 성능테스트를 진행할 때는 30분에서 2시간정도 긴 시간을 소요하는 내구성 테스트를 진행한다고 한다. 하지만 내 서비스의 경우에는 10분이상 사용하는 경우가 드물다. 따라서 사용자의 특성을 고려해서 최소 트래픽에서 최대 트래픽까지 10분간 천천히 올리고 5분간 최대 트래픽 상황에서 테스트를 진행했다.

아래의 테스트 결과는 두번 테스트를 진행한 결과이다. 비슷한 경향을 보이는 것을 볼 수 있다.

테스트 결과 분석

부하테스트 시 TPS 그래프는 각 영역이 나누어진다.

• 저부하 구간(Light Load Zone): 사용자가 증가할수록 처리량도 같이 증가하는 구간입니다.
• 포화점/임계점(Saturation Point): 사용자가 증가해도 처리량이 더 이상 증가하지 않는 구간입니다. 시스템의 리소스 부족이나 병목발생으로 인해 나타나는 현상입니다.
• 경합구간(Buckle Zone): 포화점이 지속되어 2차병목이 발생하고 처리량이 오히려 감소하는 구간이다.

테스트 결과를 여러 구간들과 관련지어 분석해보면

• 두 테스트 모두 Vuser가 10쯤 되는 시점에서 포화점이 시작되고 25명쯤일 때 경합구간에 진입한다.
• 경합구간에 들어간 후 응답시간도 160ms 밑으로 내려오지 않아 목표인 150ms에 미치지 못한다.
• 경합구간에 들어간 후 CPU사용량은 최대 70%로 꽤있는 편이지만 아직 사용할 수 있는 리소스가 남아있는 상태.
• WAS의 스레드 풀에서 사용할 수 있는 스레드의 수도 여유가 있음.

테스트 후 문제를 해결하는 과정은 다음 글에서 알아봅시다.