[주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 12. 성능 테스트

1. 성능 테스트

성능 테스트를 통해 서버가 특정 작업 부하 상태에서 응답 시간, 처리량, 자원 사용량(CPU, 메모리 등) 측면에서 시스템이 어떻게 작동하는지 확인하기 위한 작업을 의미한다.

 

테스트 종류

부하(load) 테스트	특정한 예상 부하에서 시스템이 어떻게 동작하는지 확인한다. 효과 : 주요 기능의 성능 지표(응답시간, 처리량) 확인 가능, 병목 파악
스트레스(stress) 테스트	시스템의 최대 성능을 확인하기 위한 테스트이다. 예상을 뛰어넘는 부하가 발생했을 때, 시스템이 어디까지 성능을 낼 수 있는 지를 확인한다.
지속 부하(soak) 테스트	시스템이 지속적인 부하를 견딜 수 있는지를 검증한다. 장시간 동안 일정 수준의 부하를 주어 성능 저하가 발생하는지 확인하며 메모리 누수도 탐지 할 수 있다.
스파이크(spike) 테스트	급격하게 트래픽이 변화할 때 시스템의 반응성과 안정성을 검증하는 테스트이다. 순간적으로 트래픽이 급증했을 때, 성능 저하나 실패가 발생하는지를 확인한다.

 

2. 포화점과 버클존

성능 테스트를 진행하는 일반적인 방식은 낮은 부하에서 시작해서 점진적으로 부하를 높이는 것이다. 이렇게 부하를 증가시키면 초기에 처리량이 같이 증가하다 일정 부하 구간에 도달하면 처리량과 응답 시간이 급격히 저하된다. 이때 저하되기 직전 최대 지점을 포화점이라 한다.

 

포화점(saturation point, tipping point)

• 성능이 저하되기 전의 최대 처리량
• 시스템이 감당할 수 있는 성능의 한계 지점

버클존은 포화점을 지나 성능이 꺾이기 시작하는 구간을 의미한다.

 

• 포화점 > 목표 성능 : 만족스러운 성능 테스트
• 포화점 <= 목표 성능 : 병목 지점을 찾아 제거 필요

 

일반적으로 웹 서버의 병목 지점은 호출 비중이 높으면서도 응답 시간이 긴 기능과 관련되어 있다.

응답 시간에 영향을 주는 요인은 다음과 같다.

• DB 연동(쿼리 실행 시간)
• 외부 연동 시간
• 트래픽 대비 부족한 커넥션 풀 크기

어떤 지점에서 병목이 발생하는지 확인한 뒤 서버 확장, 캐시 적용, 비동기 연동과 같은 수단을 강구해서 응답 시간을 줄이려 하면 줄어든 응답 시간만큼 포화점을 높일 수 있을 것이다.

 

3. 주요 측정 지표

성능 테스트 시 주로 측정하는 지표에 대한 설명이다.

 

응답 시간

성능 테스트에서 응답 시간은 중요한 지표이다. 응답 시간은 다음과 같이 여러 값을 측정한다.

• 평균
• 최대
• 최소
• 중앙
• 99%나 95% 백분위

 

• 응답 시간의 평균과 최대값의 차
  • 이 차이값이 크다면 99%나 95% 백분위 값을 함께 확인해야 한다.
  • 이 백분위 값이 최대 응답 시간보다 평균 값에 가깝다면 최대 값은 이상치일 수 있다.

 

• 응답시간의 중앙값과 평균값의 차이
  • 응답 시간이 중앙값보다 평균값이 더 큰 좌편향 분포를 보인다면 이는 평균값보다 느린 응답시간이 더 많이 분포해있다는 것을 의미한다.

 

위는 응답시간 중앙값이 응답시간 평균값보다 큰 우편향 그래프이다

 

처리량

처리량은 TPS(Transaction Per Second, 초당 트랜잭션 건수)처럼 초 단위로 얼마나 많은 요청을 처리했는지를 나타낸다. 테스트를 진행하는 동안 처리량은 변화하므로 최대, 평균, 최소 값을 함께 구한다.

 

에러율

에러율은 전체 요청 중에서 에러가 발생한 비율을 의미한다. 부하 테스트를 하다 보면 처리량은 높은데 에러도 함께 증가하는 상황이 발생한다. 에러가 발생한다는 건 시스템이 부하를 감당하지 못하고 있다는 신호일 수 있다. 에러가 증가하기 시작하는 지점이 시스템의 한계일 가능성이 높다.

 

CPU 사용률

부하 테스트 중에는 대상 시스템의 CPU 사용률도 함께 모니터링해야 한다. 일반적으로 웹 서버의 성능 문제는 DB나 외부 연동에서 발생하지만 높은 CPU 사용률로 인해 문제가 생기는 경우도 있다. CPU 사용률을 측정하면 문제 원인을 분석할 때 범위를 좁히는 데 도움이 된다.

 

4. 성능 테스트 설계 시 고려 사항

성능 테스트를 설계할 때는 다음 사항들을 고려해야 한다.

• 시스템 트래픽 패턴
• 사용자규모(동시 요청자 수, 트래픽 규모)
• 기능별 트래픽 비율
• 데이터 크기
• 워밍업
• 적절한 목표치 설정

 

시스템 트래픽 패턴

시스템은 보통 일정한 트래픽 패턴을 가진다. 콜센터 업무 시스템은 업무 시작 시간부터 종료 시간까지 비교적 고른 트래픽 패턴을 보이는 반면, 학원 관련 서비스는 주중 오후 시간대에 트래픽이 급증하는 패턴을 보인다. 이처럼 서비스의 특성에 따른 트래픽 상황을 가정해 성능 테스트 진행이 필요하다. 만약 트래픽이 짧은 시간에 증가하는 패턴을 보인다면 그에 맞춰 성능 테스트도 짧은 시간 간격으로 부하를 늘리는 방식으로 설계하는 것처럼 말이다.

 

사용자 규모

50명이 사용하는 내부 시스템과 1천만이 사용하는 온라인 서비스는 처리해야 하는 트래픽 규모가 다르다. 트래픽 규모가 작으면 한 대의 부하 발생기로도 충분하지만 트래픽 규모가 큰 서비스는 여러 대의 부하 발생기를 사용해야 할 수 있다.

 

또한 부하에 사용할 사용자 수도 중요하다. 예를 들어 한 사용자의 인증 토큰을 사용해서 모든 요청을 생성한다면 DB의 캐싱을 통해 시스템은 실제보다 더 좋은 성능을 낼 수 있기 때문에 정확한 테스트가 어려울 수 있다. 따라서 사용자에 따라 조회하는 데이터가 다르다면 목표로 하는 동시 사용자 수에 맞춰 요청을 발생시킬 수 있도록 테스트를 설계해야 한다.

 

기능별 트래픽 비율

자주 불리는 API 목록을 추리고 최대한 실제 호출되는 비율에 맞게 부하가 발생하도록 테스트를 설계한다. 실제 불리는 비율을 고려하지 않고 1개 API에 대해서만 부하를 발생시키면 캐시 효과와 같은 이유로 결과가 실제보다 잘 나올 수 있다.

 

데이터 크기

데이터 크기도 고려해야한다. 실제 상황과 유사한 데이터 양으로 테스트를 하는 것이 중요하다. 데이터가 100만 건이 예상되는 서비스에 대해 부하 테스트를 하는데 DB에 데이터를 50건만 넣으면 의미가 없다. 왜냐하면 데이터 규모가 작으면 성능이 잘 나오고 실제 상황에 적용했을 때는 더 많은 데이터 때문에 문제가 발생할 수 있다. 반대로 데이터가 많아야 1년에 2천 개밖에 생성되지 않는 기능에 대해 스트레스 테스트 목적으로 50만 개의 데이터를 만들면 안 된다는 뜻이기도 하다. 예상되는 규모에 맞게 테스트 데이터를 만들어야 실제에 근접한 성능 테스트 결과를 얻을 수 있다.

 

워밍업

테스트를 진행하기에 앞서 레디스를 캐시로 사용하는 경우 캐시를 어느정도 채우는 준비과정이 필요하다. 만약 캐시를 비운 상태에서 진행해야하는 테스트가 아닌 이상 실제 서비스에서는 캐시가 어느정도 채워진 상태라 가정할 경우엔 그 상황에 맞춰 미리 세팅을 해둬야 올바른 테스트 결과를 얻을 수 있다.

 

부하 테스트 시 점진적으로 트래픽을 늘려서 워밍업을 하기도 한다. 예를 들어 첫 30초 동안은 20명의 동시 사용자로 부하를 발생시키고 이후 15초마다 동시 사용자를 20명씩 늘리는 식으로 시스템에 가해진느 부하를 조금씩 증가시키는 방법이 있다. 이는 시스템이 안정화된 상태에서 본격적인 부하 테스트를 진행할 수 있도록 한다.

 

적절한 목표치

실제 예상 되는 사용자 수와 요청 건수를 감안해서 성능 목표치를 설정하자. 

 

5. 성능 테스트 도구

부하 테스트 도구로 nGrinder와 k6가 있다.

 

nGrinder

nGrinder는 네이버에서 개발한 부하 테스트 도구로 네이버에서 검증된 기술로 grinder를 기반의 더 편리한 버전이라고 할 수 있다.

nGrinder는 Groovy나 Jython을 이용해서 테스트용 스크립트를 작성한다.

 

nGrinder는 1개의 컨트롤러와 다수의 에이전트로 구성되어 있다.

• 컨트롤러
  • 웹 UI를 제공하고 있어 사용이 쉽다는 이점이 있다. 
• 에이전트
  • 실제로 부하를 발생시킴
  • 테스트 대상 서버의 시스템 지표(CPU와 메모리)를 모니터링
  • 2개 이상의 에이전트를 사용할 수 있기 때문에 여러 장비를 활용해서 대량의 부하를 발생시킬 수 있다.

 

k6

k6는 Grafana로 유명한 Grafana Labs에서 개발한 부하 테스트 도구이다. 비교적 최근에 나온 도구로 설치가 쉽고, 고 언어로 개발됐지만 테스트 스크립트는 자바 스크립트를 이용해 작성한다.

 

k6는 고루틴을 사용해서 부하를 발생시키기 때문에 스레드를 사용하는 도구 대비 더 적은 자원으로 더 많은 부하를 발생할 수 있다. 동시에 여러 장비에서 부하를 발생시키고 싶다면 유료 버전인 k6 클라우드를 사용하면 된다. 쿠버네티스 클러스터가 있다면 k6 Operator를 사용해서 분산 환경에서 부하를 발생할 수 있다.

 

k6는 CLI로 실행한다. 그래서 CI/CD 환경에 통합이 용이하다. 부하 테스트 결과도 콘솔에 출력한다. Prometheus나 InfluxDB 같은 곳에 결과를 저장해서 실시간 테스트 상황을 모니터링할 수 있다. 또한 별도의 리포트 플러그인을 사용해서 HTML과 같은 형식으로 생성할 수도 있다.

 

그 외의 부하 테스트 도구로는 

• Locust
  • 파이썬 코드를 사용해서 테스트를 정의하며 명령행과 웹기반 UI로 테스트를 실행할 수 있다. 분산 환경에서 부하를 발생하는 기능을 제공하며 클라우드 버전도 제공한다.
• Gatling
  • 자바, 스칼라, 코틀린, 자바스크립트를 이용해서 테스트 스크립트를 작성한다. 웹 요청 외에 AMQP나 카프카 등 다양한 프로토콜을 지원한다. 엔터프라이즈 버전을 사용하면 분산 환경에서 부하를 발생할 수 있다.
• JMeter
  • 오랜 기간 명맥을 유지하고 있는 부하 테스트 도구로 GUI 환경과 CLI 환경을 지원한다. 웹 요청 외에 FTP, DB, TCP 등 다양한 어플리케이션과 프로토콜에 대한 테스트를 지원한다. 분산 환경에서 부하를 발생할 수 있다.

 

각자 상황에 맞추어 테스트 도구를 선택하고, 자바를 포함한 JVM 환경에 익숙하다면 nGrinder나 Gatling을, 자바스크립트가 익숙하다면 k6를 시도해보자.

 

6. 성능 테스트 실행 시 주의 사항

 

동일 서버에서 부하기와 테스트 대상 시스템 동시 실행

성능 테스트를 진행할 때 흔히 하는 실수 중 하나가 테스트 대상 시스템과 부하기를 한 장비에서 실행하는 것이다.

 

위처럼 부하기와 테스트 대상 시스템을 한 곳에서 실행하면 안된다. 왜냐하면 부하 생성은 그 자체로 많은 자원을 사용하는데, 테스트 대상 시스템과 부하기를 한 장비에서 실행하면 테스트 대상 시스템이 자원을 온전히 활용하지 못해 실제 성능보다 낮은 결과가 나온다.

=> 성능 테스트를 진행할 때는 반드시 부하 발생기와 테스트 대상 시스템을 분리해야 한다. 또 부하를 발생할 장비의 성능도 신경 써야 한다.

 

서버 설정 제한

초당 요청 개수나 스레드 풀 개수, DB 커넥션 풀 크기 설정 등 서버 설정에 제한을 걸고 부하 테스트를 실행하는 것도 자주 하는 실수다.

 

예를 들어 Nginx를 사용하는데 DDoS 공격을 막기 위해 limit_req_zone 설정을 사용해서 IP당 초당 요청 개수를 10개로 제한했다고 하자. 부하기는 1대 장비에서 다량의 요청을 발생하므로 초당 10개 제한에 걸리게 된다. 이러면 많은 요청에 대해 오류 응답이 발생하므로 제대로 된 부하 테스트를 할 수 없다. 

 

비슷하게 서버의 스레드 풀 개수나 DB 커넥션 풀의 크기가 작으면 부하 테스트가 제대로 이루어지지 않으니 테스트할 부하 규모에 맞게 풀의 크기를 미리 설정해야 한다.

 

운영 시스템과 동일한 네트워크 환경에서 테스트

스트레스 테스트처럼 대량의 요청을 발생시킬 때는 테스트 대상 시스템에 많은 네트워크 트래픽이 발생한다. 실 운영 시스템과 테스트 대상 시스템을 동일 네트워크에 넣고 테스트를 실행하면 테스트가 발생시키는 트래픽이 실 운영 환경에 영향을 줄 수 있다. 

 

실제 외부 서비스 사용

외부 서비스를 연동하는 기능을 테스트할 때는 실제 외부 서비스를 사용하지 않게 주의해야 한다. 테스트하고 싶은 대상은 우리 시스템이지 외부 시스템이 아니기 때문이다. 외부 시스템 연동을 그대로 둔 채로 부하 테스트를 진행하면 외부 시스템이 트래픽을 견디지 못하고 장애가 발생할 수 있다. 만약 외부 서비스 연동이 포함된 기능에 대해 부하 테스트를 진행해야 한다면 실제 외부 서비스 대신에 가짜 외부 서비스로 대체해야 한다.

 

실제 운영환경과 다른 테스트 대상 시스템 환경

테스트 대상 시스템은 최대한 실제 운영 환경과 동일하게 구성해야 한다. 간혹 실제 운영 환경 대비 저사양 환경을 사용해서 테스트 대상을 구성할 때가 있다. 예시로 실제 운영 서버는 8코어 CPU 16GB 메모리를 사용하는데 ㅔ테스트 환경은 2코어 2GB 메모리를 사용하는 식이다. 이렇게 되면 실제 환경에서 얼마나 성능을 낼 수 있는지 확인 할 수 없다. 따라서 최대한 실 환경에 맞춰 테스트를 실행해야 유효한 성능 지표를 구할 수 있다.