부하테스트 (1) - 부하테스트의 종류와 목적

안녕하세요. 이번 글에서는 부하테스트의 종류에 대해서 설명해보겠습니다.

앞선 포스팅에서 작성했 듯 부하테스트에는 여러가지 목적이 있습니다.

1. 시스템이 잘 돌아가는 지 확인할 수 있다.
2. 성능 지표를 확인할 수 있다.
3. 부하 상황에서 잘 견딜 수 있는지, 자동으로 회복이 되는지 확인할 수 있다.

위 내용과 같이 다양한 목적을 달성하기 위해 부하테스트에는 각 목적을 달성하기 위한 테스트가 있습니다.

0. 부하테스트의 종류

출처 : k6

위 사진과 같이 부하테스트는 크게 4가지로 분류됩니다.

1. Smoke Test
2. Load Test
3. Stress Test
4. Soak Test

하지만 이번 포스팅에서는 1, 2, 3번 부하테스트 방식에 대해 설명해보고자 합니다. ( 4번은 학습 경험이 없습니다.. ) 지금부터 차례대로 3가지 부하테스트 방식에 대해 설명해보도록 하겠습니다.

1. Smoke Test

Smoke Test는 시스템이 아무 문제 없이 작은 부하를 견딜 수 있는지 확인하는 작업입니다. 조금 더 풀어서 설명하자면, 최소한의 부하로 테스트를 구성하여, 최소한의 부하가 존재하는 상태에서 서비스가 잘 작동하는지 확인하는 작업이라고 할 수 있겠네요. 또, 앞으로 실행 할 부하테스트 script가 에러가 발생하지 않고 잘 구동되는지 확인할 수 있는 테스트입니다.

 

Smoke Test의 목적을 정리하자면, 아래와 같습니다.

1. 테스트 스크립트에 에러가 존재하지 않아 이후 테스트에도 적용할 수 있는지 확인한다.
2. 최소한의 부하 상황에 서비스가 에러를 발생시키지 않는지 확인한다.

1번 목표를 달성하기 위해서 저는 일반적으로 Smoke Test 를 부하 테스트의 가장 첫 단계에서 진행했습니다. Smoke Test를 실행시키고 WS, WAS 각 시스템의 로그를 확인하여 작성자가 예상한 대로 HTTP 요청이 전달되는지 확인하여 Script의 오류를 확인 / 수정할 수 있었습니다. Smoke Test가 원하는 대로 잘 진행되면, 웹 요청에 대한 Script는 그대로 유지하고 다른 테스트를 위한 환경(VUser 수, Duration 등)만 수정해주면 간단하게 다음 테스트를 이어갈 수 있었습니다.

 

2번 목표는 Smoke Test 결과 에러가 전혀 발생하지 않았는지 정도 확인하는 것으로 달성할 수 있었습니다.

이처럼 두 가지 목표를 달성하면 다음 부하 테스트 방법인 Load Test로 넘어갈 수 있습니다.

2. Load Test

Load Test는 시스템의 평소 트래픽부터 피크타임 트래픽까지의 상황에서 성능을 확인하는 테스트 기법입니다. 즉, 시스템이 내가 기대하는 성능에 잘 도달하는지 확인하는 작업이라고 할 수 있죠. 기대하는 성능에 잘 도달하는지 확인하기 위해 반복적으로 테스트 / 수정 과정을 거쳐야 하는 것이 특징입니다.

 

Load Test의 목적을 정리하자면, 아래와 같습니다.

1. 평소 트래픽부터 피크타임의 트래픽 사이의 시스템 성능을 측정한다.
2. 성능 기준을 만족하기 위해 계속해서 테스트 / 수정 (code, infra)을 거듭한다.

1번 목표를 달성하기 위해 가장 중요한 것은 평소 트래픽과 피크타임 트래픽을 아는 것입니다. 혹, 운영 중에 발생하는 트래픽 수준을 과대평가하여 시스템 성능을 현재 서비스 수준보다 과하게 업그레이드하면 Resource의 낭비가 발생할 수 있습니다. 따라서 현재 트래픽을 기반으로 명확한 시나리오를 작성하는 것이 중요했습니다. 물론, 미래에 대비한 설계를 하는 것이 나쁘다고 생각하지는 않습니다. 하지만 미래 대비 또한 과하게 하는 것은 문제가 있겠죠.

 

저는 아래와 같은 방법으로 평소 트래픽, 피크타임 트래픽을 산정합니다.

2-1 트래픽 계산하기

용어 : MAU (월간 활성 유저) , DAU (일별 활성 유저), RPS (Request Per Second)

시나리오 : MAU : 10만명, 1명당 하루 평균 접속 수 = 5회, 주로 하는 일 = 전체 조회, 단건 조회 (Request 2회) , 피크타임엔 평소 10배

계산하기

DAU = 100,000(MAU) / 30 (Days per Month) = 3,333명
평균 RPS = 일간 총 접속 회수 / 초 = 3,333(DAU) * 5 (평균 접속 수) / 86,400 (Seconds per Day) = 0.192
피크 RPS = 0.192 * 10 = 2
VUser 상호작용 시간 = 2 (Request) * 0.2 (기대하는 요청, 응답 시간) + 1 (사용자 고민 보정 계수) = 1.4
일반 VUser = 0.192 (일반 RPS) * 1.4 (VUser 상호작용 시간) / 2 (Request) = 0.1344
피크 VUser = 1.344 = 1 or 2

위 방법과 같이 일반적으로 사용하는 계산 방법을 이용하여 현재 기대치에 맞게 Load Test를 하는 것이 이 테스트의 목적과 일치합니다. 하지만 계산 방법이 익숙하지 않은 사람에겐 어렵기도 하고, 트래픽이 적은 경우에는 크게 유의미한 결과를 얻지 못하기 때문에 (현재 t4g.micro를 쓰는데, VUser가 약 15 ~ 20 정도 갈 때 서비스가 버거워 한다. 이정도 수치는 쉽게 견딜 수 있다는 뜻) 저는 다른 방법을 선택했습니다.

 

바로 가능한 적게 시작하기인데요. 이 방법은 부하테스트 툴인 K6도 공식 문서에서 권유하고 있는 방법입니다.

출처 : k6

2번 목표를 달성하기 위해서는 반복적인 테스트가 중요합니다. 기대하는 성능에 도달할 때까지 테스트 / 수정을 반복하는 방법밖에 없는 것 같습니다. 다만 테스트를 할 때 조금 신경써야 하는 부분이 있는데요, 바로 ramp-up / down입니다. Ramp-up / down은 Load Test의 시작부터 VUser를 크게 두고 하는 것이 아니라 0 ~ 일반 VUser ~ 피크 VUser ~ 일반 VUser ~ 0 의 과정으로 Load Test를 진행하는 방법이라고 생각하면 좋습니다. 이런 방식을 채택하면 시스템의 웜업 / 오토 스케일링을 돕고, 일반 / 피크 시 응답 시간을 비교할 수 있는 장점이 있습니다.

 

Load Test를 통해 두 가지 목적을 달성했다면 이제 Stress Test를 진행하게 됩니다.

3. Stress Test

Stress Test는 과부하 상태에서 시스템의 안정성과 가용성을 테스트하는 방법입니다. Load Test를 통해 시스템이 기대한 성능을 잘 내고, 어느정도 부하 수준을 견뎌내는지 확인할 수 있었을텐데요. Stress Test단계에서 그 부하를 넘어서도 서비스가 안정적으로 auto scaling 하는지, 그 과정에서 에러는 없는지, 다시 회복은 잘 하는지 확인할 수 있습니다.

 

Stress Test의 목적을 정리하자면, 아래와 같습니다.

1. 극한의 부하 상황에서 시스템이 어떻게 작동하는지 확인한다.
2. 사용자, TPS 측면에서 시스템의 최대 가용성을 확인한다.
3. 시스템이 터지는 지점을 확인한다.
4. 스트레스 테스트가 끝나고 수동 개입없이 시스템이 자동 복구를 잘 해내는지 확인한다.

사실 스트레스 테스트를 실제 서비스에 적용해 본 경험이 없어 각 목적을 달성하기 위해 무언가 경험한 것은 없는데요. 학습하며 느낀 부분은 Stress Test 에서는 인프라 구조의 안정성, 확장성이 정말 중요하다는 생각이 들었습니다. 또한 대규모 트래픽이 발생하는 이벤트 등의 특별한 일이 있다면 Stress Test를 통해 서비스의 최대 부하 지점을 확인하고 이에 대한 장애 대응 전략이나 장애를 맞이하지 않기 위한 노력이 필수적이라는 생각이 드네요.

4. 결론

부하테스트에는 여러가지 방법이 있습니다. Smoke, Load, Stress 등이 있는데요. 각 테스트의 목적을 잘 이해하고 시나리오를 작성하여 고가용성의 서비스를 운영하기 위한 적절한 노력을 경험해보면 정말 좋을 것 같습니다.

 

이번 포스팅을 통해 부하테스트 종류와 목적 그리고 대충의 방법을 확인해 봤으니, 다음 포스팅에서는 부하테스트 적용하기에 대해 작성해보겠습니다. 읽어주셔서 감사합니다.

 

출처 

책 - 아마존 웹 서비스 부하 테스트 입문 : 다양한 부하 테스트 상황에 맞춘 실전 노하우

https://k6.io/docs/test-types/introduction/

Introduction