Devops Day 65 (6.8) 성능 테스트_부하 테스트 도구와 활용

Latency에 중점을 둔 SLO 예시
- GET 호출의 90%는 1ms 이내에 완료해야 합니다.

- GET 호출의 99%는 10ms 이내에 완료해야 합니다.

- GET 호출의 99.9%는 100ms 이내에 완료해야 합니다.

 

Throughput에 중점을 둔 SLO 예시
결국 Throughput은 순간적으로 요청이 치솟는 피크(peak) 트래픽에서의 처리량을 바탕으로 합니다. 예를 들어, 1일 기준으로 RPS를 계산하고자 할 때, 다음과 같은 시나리오를 생각해 볼 수 있습니다.

- DAU(Daily Active User: 1일 접속자 수): 5만 명

- 1명당 평균 접속 횟수: 20회

- 1일 평균 접속 수에 대한 피크 트래픽 배율: 3배 (보통 평균의 2~3배를 곱합니다)

- 안전 계수 (얼마만큼 넉넉하게 프로비저닝 할 것인가): 3배

이 경우 하루가 총 86400초이므로, 다음과 같이 RPS를 생각해 볼 수 있습니다.
50000 x 20 / 86400 x 3 x 3 = 104RPS (약 100RPS) 따라서 서비스는 100RPS를 달성해야 합니다.

 

부하 테스트 도구
사용자가 이용하고 있는 온라인 서비스로부터 예상치 못한 느려짐을 겪거나, 접속 불가로 인해 서비스 이용 조차 할 수 없다면, 서비스에 중요한 재방문율(Retention Rate)과 유료 전환율(Conversation Rate)을 하락 시켜 비지니스에 큰 손실을 야기 할 수 있습니다.

부하 테스트 전 고려되어야 할 점

실제 성능 테스트 시, 부하 테스트를 비중 있게 여기지 않는 경우가 많으며, ApacheBench 나 JMeter 와 같은 도구를 다운로드 한 뒤, 특정 시나리오를 기반으로 하여 도구를 실행하는 것만으로 충분하다고 생각하는 경우가 있습니다. 하지만, 실제 워크로드는 다양한 변수와 시나리오를 가지고 있기 때문에, 부하 테스트를 진행할 때 충분히 이점을 반영 하여 야지만 실제 서비스에서 예상 가능한 결과를 가져올 수 있다는 것은 분명한 사실 입니다.

- 충분한 테스트용 서버 자원 확보: 최대의 트래픽을 생성하여 테스트 하기 위해서는 충분한 서버 자원이 요구되며, 부족할 경우 적절한 테스트가 이루어지기 힘듭니다.

- 테스트 시, 블랙박스 혹은 격리된 환경 제어: 부하 테스트는 많은 요청과 패킷을 생성하기 때문에 사내 인프라의 많은 부분을 포화 상태로 만들기 쉽습니다.
- 글로벌 기반의 부하 생성: 글로벌 서비스의 경우, 전 세계 각 지역에서 부하를 생성하여 테스트를 진행하여야만 실제 사용 패턴에 가까운 시나리오가 될 수 있습니다. 이를 통해 글로벌 커버리지를 확인할 수 있으며, 실제 워크로드에서 얻을 수 있는 유사한 각종 성능 관련 지표도 얻을 수 있습니다.
- 높은 비용과 불규칙적인 사용성에 대한 주의: 격리된 환경과 더불어 여러 리전을 커버하기 위한 테스트 환경은 때로 높은 비용을 요구합니다.
- 높은 아키텍처 복잡성에 대한 주의: 상기 언급된 부분들을 고려하여 부하 테스트 환경을 구성한다면 꽤나 높은 복잡성이 요구 됩니다. 나아가 반복적인 테스트를 위해, 가상의 가짜(Dummy) 데이터 등에 의해 지저분해진 환경을 초기화 시켜줄 수 있는 방안도 필요 합니다.

 

AWS 클라우드 기반 부하 테스트의 장점

AWS 클라우드는 부하 테스트를 진행하기 위해 고려할 사항에 대한 적절한 해답을 가지고 있습니다.
- 사용한 만큼 지불하는 비용 효율성: Amazon EC2 인스턴스는 사용한 만큼만 비용이 발생하기 때문에, 테스트 조건에 맞는 인스턴스 타입을 선택하여 비용 효율성을 높일 수 있습니다.
- 충분하고 유연한 컴퓨팅 자원 제공: AWS가 제공하는 컴퓨팅 자원을 활용한다면, 필요한 규모의 부하에 대해 자유롭게 테스트를 수행할 수 있습니다. 또한, 오토스케일링(Auto Scaling)을 통해 부하 테스트 시 자원을 자동으로 증설 혹은 감소 시킬 수 있습니다.
- 글로벌 리전(Region)으로부터의 부하 생성: AWS가 제공하는 글로벌 인프라를 통해 전 세계 각 리전으로부터의 부하 생성을 손쉽게 할 수 있습니다.
- 쉽고 단순한 아키텍처 구성 및 관리: AWS CloudFormation 을 비롯한 다양한 배포 자동화 서비스 및 기능을 통해 프로덕션과 테스트 용 환경을 동일한 방법으로 손 쉽게 구성할 수 있습니다.

 

부하 테스트의 단계

부하 테스트는 서비스 전체 스택을 대상으로 진행할 수도 있지만, 최근에는 마이크로서비스(Microservices) 나 서비스 지향 구조(Service-Oriented Architecture) 등의 형태로 서비스를 디자인하는 경우가 많아, 전체 스택을 구성하고 있는 작은 컴포넌트들부터 진행되는 경우가 많아지고 있습니다.

아래는 일반적으로 수행할 수 있는 부하 테스트 단계 입니다.

- 비결합(Loosely Coupled)된 개별 컴포넌트에 대한 부하 테스트: 이를 통해 각 컴포넌트 별 병목 현상을 보다 빠르게 발견하고 수정할 수 있습니다.

- 내부 서비스에 대한 부하 테스트: 로그 기록 서비스와 같이 높은 처리량이 요구되는 서비스나, 결제 서비스와 같이 전체 서비스 품질에 있어 중요한 내부 서비스를 대상으로 테스트를 진행 합니다.

- 외부 서비스에 대한 부하 테스트: Facebook, Twitter 등의 소셜 서비스나 Google 등의 플랫폼에 대한 서비스들, 또는 푸시 알림 서비스 등의 외부 서비스를 대상으로 테스트를 진행 합니다.

- 전체 스택에 대해 부하 테스트: 개별 컴포넌트들에 대한 테스트를 완료한 뒤, 컴포넌트간의 상호작용을 알기 위해 처음부터 끝까지 전체 스택에 대해서 테스트 진행 합니다.

 

단계별 부하 테스트 수행 방법

앞서 언급한 것처럼, 부하 테스트는 전체 스택에 대해서도 수행 가능하지만, 작은 비결합된 컴포넌트나 기능 단위로도 수행 가능합니다. 그리고 작은 단위로 수행될 수록 더 분명하게 병목 지점을 파악하기에 수월 합니다. 다음은 전형적인 3단계(3-tier) 웹 서비스에 대해 단계별로 부하 테스트를 진행하는 것을 설명하고 있습니다.

 

부하 테스트 관련 도구 및 서비스

부하 테스트를 위해 사용할 수 있는 다양한 툴과 서비스들이 존재 합니다. 간단한 소개와 함께 특징들을 살펴보겠습니다.
- ApacheBench (http://httpd.apache.org/docs/2.2/en/programs/ab.html): 일반적으로 HTTP 웹 서버의 성능을 측정하기 위해서 자주 사용되는 툴입니다.
- Siege (https://www.joedog.org/siege-home/): HTTP 부하 테스트와 벤치마킹 유틸리티 입니다. 한번에 복수개의 URL 로 테스트가 가능하고, Basic 인증을 지원하며 HTTP와 HTTPS 프로토콜로 테스트가 가능하는 등 ApacheBench 의 제한을 어느정도 해소 해 줍니다.
- JMeter (http://jmeter.apache.org/): 1998 년 부터 시작된 프로젝트로서 오랫동안 기능 강화를 지속해오고 있는 Java 기반의 부하 테스트 툴 입니다. HTTP 뿐만 아니라 다양한 프로토콜을 지원하며, 많은 기능을 가진 GUI 를 제공 합니다. 실제 워크로드를 시뮬레이션 하기 위해 다양한 방법으로 커스터마이징이 가능합니다. 하지만 앞서 언급한것처럼 Thread 기반으로 구현되어 있어 성능과 동시성에 대해서 제한이 있습니다.
- The Grinder (http://grinder.sourceforge.net/): Java 기반의 부하 테스트 프레임워크 입니다. Agent 가 지정한 값을 기반으로 부하를 생성하며, IDE 형태의 콘솔에서 Agent 들을 제어 및 결과 모니터링이 가능합니다.

참조 : https://aws.amazon.com/ko/blogs/korea/how-to-loading-test-based-on-aws/

AWS 기반 웹 및 애플리케이션 서버 부하 테스트: A to Z | Amazon Web Services

 

K6
K6는 웹 애플리케이션의 성능과 확장성을 테스트하기 위해 사용되는 오픈 소스 기반의 개발자 중심 부하 테스트 도구입니다. 실제 트래픽 시나리오를 시뮬레이션하고 다양한 부하 하에서 시스템의 응답을 측정하는 것이 가능합니다. 다음은 K6 사용의 장점과 단점, 그리고 사람들이 왜 사용하며 어떻게 사용하는지에 대한 설명입니다:

 

K6의 장점:

1. 사용이 쉬움: K6는 사용자 친화적이고 직관적인 커맨드 라인 인터페이스를 제공하여 테스트 스크립트 작성 및 부하 테스트 실행이 간단합니다.

2. JavaScript 기반: K6는 자바스크립트를 스크립팅 언어로 사용하여 자바스크립트에 익숙한 개발자들에게 친숙하며, 학습 곡선을 낮출 수 있습니다.

3. 높은 확장성: K6는 고부하를 처리하고 손쉽게 확장할 수 있도록 설계되었습니다. 수천 개의 동시 사용자를 시뮬레이션하여 성능 병목 현상을 식별하고 애플리케이션을 최적화할 수 있습니다.

4. 실제적인 부하 테스트: K6를 사용하면 복잡한 시나리오를 시뮬레이션하고 실제 사용자 동작을 모방할 수 있으며, API 요청, 웹 소켓 연결, 데이터 기반 테스트 등을 포함하여 정확한 애플리케이션 성능 정보를 제공합니다.

5. 상세한 메트릭과 인사이트: K6는 응답 시간, 처리량, 오류율, 사용자 정의 메트릭 등 포괄적인 성능 데이터를 제공합니다. 이 정보는 성능 문제를 식별하고 애플리케이션을 최적화하는 데 도움이 됩니다.

K6의 단점:

1. 그래픽 사용자 인터페이스(GUI) 부재: K6는 주로 명령줄 도구로 제공되므로, 부하 테스트에 그래픽 인터페이스를 선호하는 사용자에게는 적합하지 않을 수 있습니다.

2. 프로그래머가 아닌 사람들에게는 학습 곡선이 높음: K6는 간단한 스크립팅 언어를 제공하지만, 프로그래밍 경험이 없는 사람들은 복잡한 테스트 시나리오 작성이나 스크립트 사용자 정의가 어려울 수 있습니다.

3. 제한된 보고서 생성 기능: K6는 상세한 성능 메트릭을 생성하지만, 고급 보고 기능이 부족합니다. 사용자들은 종종 외부 도구와 통합하거나 사용자 정의 스크립트를 작성하여 더 포괄적인 보고서를 생성해야 합니다.

K6를 사용하는 이유와 사용 방법:

1. 부하 테스트: K6는 웹 애플리케이션의 성능, 확장성, 신뢰성을 다양한 트래픽 하에서 평가하기 위해 일반적으로 사용됩니다.

2. 지속적인 통합 및 전달 (CI/CD): 개발자들은 종종 K6를 CI/CD 파이프라인에 통합하여 부하 테스트를 자동화합니다. 이를 통해 성능 하락을 개발 주기 초기에 감지할 수 있습니다.

3. 성능 최적화: K6를 사용하여 부하 테스트를 실행함으로써 애플리케이션 내의 성능 병목 현상을 식별하고 수정할 수 있으며, 더 빠르고 효율적인 애플리케이션을 구축할 수 있습니다.

4. 용량 계획: K6를 사용하여 예상 트래픽 부하를 처리하는 데 필요한 자원을 추정하고, 이를 기반으로 인프라를 계획할 수 있습니다.

5. 벤치마킹: 개발자들은 K6를 사용하여 다른 웹 애플리케이션 버전, 인프라 구성, 제3자 서비스의 성능을 비교하여 최적화 또는 벤더 선택에 대한 정보를 얻을 수 있습니다.

종합적으로, K6는 개발자들이 효율적인 부하 테스트를 수행하고 성능을 최적화하며 웹 애플리케이션의 신뢰성과 확장성을 보장하기 위한 강력한 도구입니다.

Artillery
Artillery는 K6와 비슷한 목적으로 사용되는 모니터링 애플리케이션입니다. 웹 애플리케이션의 성능 및 확장성을 테스트하고 모니터링하기 위해 사용됩니다. 아래는 Artillery의 사용 목적과 사용 방법에 대한 설명입니다:

 

Artillery의 사용 목적:

1. 성능 테스트: Artillery는 웹 애플리케이션의 성능을 테스트하기 위해 사용됩니다. 특히 애플리케이션의 부하 처리 능력을 확인하고 병목 현상을 식별할 수 있습니다.

2. 스트레스 테스트: Artillery를 사용하여 애플리케이션을 고부하 상태에서 테스트함으로써 시스템의 견딜 수 있는 한계를 확인하고 응답 시간과 성능 문제를 식별할 수 있습니다.

3. 확장성 테스트: Artillery를 사용하여 애플리케이션의 확장성을 테스트할 수 있습니다. 여러 대의 서버를 사용하여 부하를 분산하고 시스템이 확장할 때의 성능을 확인할 수 있습니다.

4. 실시간 모니터링: Artillery는 실시간으로 애플리케이션의 성능을 모니터링할 수 있습니다. 트래픽 및 성능 메트릭을 모니터링하여 문제를 신속하게 파악하고 대응할 수 있습니다.

Artillery의 사용 방법:

1. 테스트 시나리오 작성: Artillery는 YAML 또는 JavaScript를 사용하여 테스트 시나리오를 작성합니다. 사용자가 원하는 부하 테스트 시나리오를 정의하고, 요청의 종류, 동시 사용자 수, 부하 시간 등을 설정합니다.

2. 부하 테스트 실행: 작성한 테스트 시나리오를 기반으로 Artillery를 실행하여 애플리케이션에 부하를 가합니다. 다수의 가상 사용자를 시뮬레이션하고 요청을 보내며 애플리케이션의 성능을 측정합니다.

3. 결과 분석: Artillery는 성능 메트릭, 응답 시간, 오류율 등의 상세한 결과를 제공합니다. 이 정보를 분석하여 성능 문제를 식별하고 최적화 및 개선 작업을 수행할 수 있습니다.

실시간 모니터링: Artillery는 웹 대시보드를 통해 실시간으로 성능 데이터를 모니터링할 수 있습니다. 대시보드에서 트래픽 패턴, 부하 상태, 응답 시간 등의 정보를 실시간으로 확인할 수 있습니다.

4. CI/CD 파이프라인 통합: Artillery는 CI/CD 파이프라인에 통합하여 자동화된 성능 테스트를 수행할 수 있습니다. 애플리케이션의 성능 변화를 지속적으로 모니터링하고 이상 현상을 감지할 수 있습니다.

장점:

1. 강력한 성능 테스트: Artillery는 다양한 시나리오를 작성하여 웹 애플리케이션의 성능을 테스트할 수 있습니다. 복잡한 시나리오, 다양한 부하 조건, 사용자 행동 모델링 등을 지원하여 실제 사용자와 유사한 부하를 생성할 수 있습니다.

2. 실시간 모니터링: Artillery는 실시간으로 성능 데이터를 모니터링할 수 있는 웹 대시보드를 제공합니다. 이를 통해 테스트 중인 애플리케이션의 상태와 성능을 실시간으로 확인할 수 있습니다.

3. 유연한 설정 및 확장성: Artillery는 YAML 또는 JavaScript를 사용하여 테스트 시나리오를 설정할 수 있습니다. 이를 통해 사용자는 테스트 요구사항에 맞게 유연하게 확장할 수 있습니다.

4. 다양한 프로토콜 지원: Artillery는 HTTP, WebSocket 등 다양한 프로토콜을 지원하여 다양한 유형의 애플리케이션에 대한 테스트를 수행할 수 있습니다.

5. 개발자 중심 접근: Artillery는 개발자를 위한 도구로 설계되어 있으며, JavaScript를 사용하여 테스트 시나리오를 작성할 수 있습니다. 개발자들은 친숙한 환경에서 성능 테스트를 수행할 수 있습니다.

단점:

1. 학습 곡선: Artillery는 일부 사용자들에게는 학습 곡선이 높을 수 있습니다. 테스트 시나리오를 작성하고 설정하는 데에는 일정한 이해와 경험이 필요할 수 있습니다.

2. 부족한 GUI: Artillery는 주로 커맨드 라인 도구로 사용되며, 그래픽 사용자 인터페이스(GUI)가 제공되지 않습니다. GUI를 선호하는 사용자들에게는 다소 불편할 수 있습니다.

3. 보고서 기능의 한정성: Artillery는 기본적인 결과 및 성능 메트릭을 제공하지만, 고급 보고서 작성이나 다양한 시각화 기능은 제한적일 수 있습니다. 사용자는 외부 도구나 사용자 정의 스크립트를 활용하여 더 상세한 보고서를 생성해야 할 수 있습니다.

Artillery는 웹 애플리케이션의 성능 및 확장성을 테스트하고 모니터링하는 데에 사용되는 강력한 도구입니다. 부하 테스트, 스트레스 테스트, 확장성 테스트 및 실시간 모니터링을 통해 애플리케이션의 성능 문제를 발견하고 최적화하는 데 도움을 줍니다.