개발자를 위한 CI 서비스로서의 부하 테스트

다중 제품 소프트웨어 공급업체가 자주 직면하는 문제 중 하나는 거의 모든 팀에서 엔지니어(개발자, 테스터 및 인프라 관리자)의 역량이 중복된다는 것입니다. 이는 부하 테스트 분야의 전문가인 값비싼 엔지니어에게도 적용됩니다.

직접 업무를 수행하고 고유한 경험을 사용하여 부하 테스트 프로세스를 구축하는 대신 방법론, 최적의 메트릭을 선택하고 부하 프로필에 따라 자동 테스트를 작성하는 대신 엔지니어는 종종 처음부터 테스트 인프라를 배포하고 부하 도구를 구성하고 포함해야 합니다. CI 시스템에서 스스로 보고서의 모니터링 및 게시를 설정합니다.

Positive Technologies에서 사용하는 테스트에서 일부 조직 문제에 대한 솔루션을 찾을 수 있습니다. 다른 기사. 그리고 여기에서는 "서비스로서의 로드 테스트"(서비스로서의 로드 테스트)라는 개념을 사용하여 로드 테스트를 공통 CI 파이프라인에 통합할 수 있는 가능성에 대해 이야기하겠습니다. CI 파이프라인에서 사용할 수 있는 로드 소스의 도커 이미지와 방법을 배웁니다. 빌드 템플릿을 사용하여 로드 소스를 CI 프로젝트에 연결하는 방법 부하 테스트를 실행하고 결과를 게시하기 위한 데모 파이프라인의 모습입니다. 이 기사는 로드 시스템의 아키텍처에 대해 생각하는 CI의 소프트웨어 테스트 엔지니어 및 자동화 엔지니어에게 유용할 수 있습니다.

개념의 본질

서비스로서의 부하 테스트 개념은 부하 도구 Apache JMeter, Yandex.Tank 및 자체 프레임워크를 임의의 연속 통합 시스템에 통합하는 기능을 의미합니다. 데모는 GitLab CI용이지만 원칙은 모든 CI 시스템에 공통입니다.

서비스로서의 부하 테스트는 부하 테스트를 위한 중앙 집중식 서비스입니다. 부하 테스트는 전용 에이전트 풀에서 실행되며 결과는 GitLab Pages, Influx DB 및 Grafana 또는 테스트 보고 시스템(TestRail, ReportPortal 등)에 자동으로 게시됩니다. 자동화 및 확장은 GitLab CI 프로젝트에서 일반적인 gitlab-ci.yml 템플릿을 추가하고 매개변수화하여 가능한 한 간단하게 구현됩니다.

이 접근 방식의 장점은 전체 CI 인프라, 로드 에이전트, 로드 소스의 도커 이미지, 테스트 파이프라인 및 게시 보고서가 중앙 집중식 자동화 부서(DevOps 엔지니어)에 의해 유지 관리되는 반면 로드 테스트 엔지니어는 테스트 개발에 노력을 집중할 수 있다는 것입니다. 인프라 문제를 다루지 않고 결과를 분석합니다.

설명을 간단히 하기 위해 대상 애플리케이션 또는 테스트 중인 서버가 이미 배포되고 미리 구성되었다고 가정합니다(Python, SaltStack, Ansible 등의 자동화된 스크립트를 사용할 수 있음). 그런 다음 서비스로서의 부하 테스트의 전체 개념은 세 단계로 나뉩니다. 준비, 테스트, 보고서 발행. 다이어그램에 대한 자세한 내용(모든 사진을 클릭할 수 있음):

부하 테스트의 기본 개념 및 정의

부하 테스트를 수행할 때 다음을 준수하려고 합니다. ISTQB 표준 및 방법론, 적절한 용어와 권장 메트릭을 사용하십시오. 부하 테스트의 주요 개념과 정의에 대한 간단한 목록을 제공하겠습니다.

로드 에이전트 - 애플리케이션이 실행될 가상 머신 - 로드 소스(Apache JMeter, Yandex.Tank 또는 자체 작성 로드 모듈).

테스트 목표(대상) - 로드 대상이 될 서버 또는 서버에 설치된 애플리케이션.

테스트 시나리오(테스트 케이스) - 일련의 매개변수화된 단계: 지정된 매개변수에 따라 고정된 네트워크 요청 및 응답을 사용하여 사용자 조치 및 이러한 조치에 대한 예상 반응.

프로필 또는 부하 계획(프로필) -에 ISTQB 방법론 (섹션 4.2.4, p. 43) 부하 프로필은 특정 테스트에 중요한 메트릭과 테스트 중에 부하 매개 변수를 변경하기 위한 옵션을 정의합니다. 그림에서 프로필의 예를 볼 수 있습니다.

시험 — 미리 결정된 매개변수 세트가 있는 스크립트.

테스트 계획(테스트 계획) - 일련의 테스트 및 부하 프로필.

테스트런(testrun) - 완전히 실행된 부하 시나리오 및 수신된 보고서로 하나의 테스트를 실행하는 하나의 반복.

네트워크 요청(요청) — 에이전트에서 대상으로 보낸 HTTP 요청입니다.

네트워크 응답(response) — 대상에서 에이전트로 보낸 HTTP 응답입니다.
HTTP 응답 코드(HTTP 응답 상태) - 애플리케이션 서버의 표준 응답 코드입니다.
트랜잭션은 완전한 요청-응답 주기입니다. 트랜잭션은 요청(request) 전송 시작부터 응답(response) 수신 완료까지 카운트됩니다.

거래 상태 - 요청-응답 주기를 성공적으로 완료할 수 있었는지 여부. 이 주기에 오류가 있으면 전체 트랜잭션이 실패한 것으로 간주됩니다.

응답 시간(대기 시간) - 요청(request) 전송의 끝에서 응답(response) 수신 시작까지의 시간.

측정항목 로드 - 로드 테스트 과정에서 결정된 로드된 서비스 및 로드 에이전트의 특성.

부하 매개변수 측정을 위한 기본 메트릭

방법론에서 가장 일반적으로 사용되고 권장되는 일부 ISTQB (p. 36, 52) 메트릭은 아래 표에 나와 있습니다. 에이전트 및 대상에 대한 유사한 메트릭이 같은 줄에 나열됩니다.

로드 에이전트에 대한 지표
로드 상태에서 테스트 중인 대상 시스템 또는 애플리케이션의 지표

수  vCPU 그리고 기억 램,
디스크 - 하중제의 "철" 특성
CPU, 메모리, 디스크 사용량 - CPU, 메모리 및 디스크 로딩의 역학
테스트 과정에서. 일반적으로 백분율로 측정
사용 가능한 최대값

네트워크 처리량 (부하 에이전트에서) - 처리량
서버의 네트워크 인터페이스,
로드 에이전트가 설치된 위치.
일반적으로 초당 바이트(bps)로 측정됩니다.
네트워크 처리량(대상에서) - 네트워크 인터페이스 대역폭
대상 서버에서. 일반적으로 초당 바이트 수(bps)로 측정

가상 사용자- 가상 사용자 수,
부하 시나리오 구현 및
실제 사용자 행동 모방
가상 사용자 상태, Passed/Failed/Total — 성공 횟수 및
가상 사용자의 실패한 상태
부하 시나리오 및 총 수.

일반적으로 모든 사용자가 완료할 수 있을 것으로 예상됩니다.
로드 프로필에 지정된 모든 작업.
모든 오류는 실제 사용자가
시스템 작업 시 문제 해결

초당 요청(분)- 초당(또는 분당) 네트워크 요청 수.

로드 에이전트의 중요한 특성은 생성할 수 있는 요청 수입니다.
사실 이것은 가상 사용자가 응용 프로그램에 액세스하는 것을 모방한 것입니다.
초당 응답(분)
- 초당(또는 분당) 네트워크 응답 수.

대상 서비스의 중요한 특성: 얼마나
다음을 사용하여 쿼리에 대한 응답을 생성하고 보냅니다.
로딩 에이전트

HTTP 응답 상태— 다른 응답 코드의 수
로드 에이전트가 수신한 애플리케이션 서버에서.
예를 들어 200 OK는 성공적인 호출을 의미하고,
및 404 - 리소스를 찾을 수 없음

숨어 있음 (응답 시간) - 끝에서 시간
응답(응답)을 받기 시작하기 전에 요청(요청)을 보냅니다.
일반적으로 밀리초(ms) 단위로 측정

트랜잭션 응답 시간— 하나의 완전한 트랜잭션 시간,
요청-응답 주기 완료.
요청(요청) 전송 시작부터 시간입니다.
응답(응답)을 수신할 때까지.

트랜잭션 시간은 초(또는 분) 단위로 측정할 수 있습니다.
여러 가지 방법으로: 최소값을 고려하고,
최대, 평균 및 예를 들어 90번째 백분위수입니다.
최소 및 최대 판독값이 극단적입니다.
시스템 성능 상태.
XNUMX번째 백분위수가 가장 일반적으로 사용되며,
대부분의 사용자에게 표시되므로
시스템 성능의 임계값에서 편안하게 작동

초당 트랜잭션(분) - 완료 수
초당 트랜잭션(분),
즉, 애플리케이션이 얼마나 수용할 수 있었고
요청을 처리하고 응답을 발행합니다.
실제로 이것은 시스템의 처리량입니다.

거래 상태 , 합격 / 불합격 / 합계 - 숫자
성공, 실패 및 총 거래 수.

실패한 실제 사용자의 경우
거래는 실제로 의미합니다
부하가 걸린 시스템에서 작업할 수 없음

부하 테스트 회로도

부하 테스트의 개념은 매우 간단하며 이미 언급한 세 가지 주요 단계로 구성됩니다. 준비-시험-보고서즉, 테스트 목표를 준비하고 로드 소스에 대한 매개변수를 설정한 다음 로드 테스트를 실행하고 마지막에 테스트 보고서를 생성 및 게시합니다.

개략도:

• QA.Tester는 부하 테스트 전문가이며,
• 대상은 로드 시 동작을 알고자 하는 대상 응용 프로그램입니다.

다이어그램의 엔터티, 단계 및 단계 분류자

단계 및 단계
어떻게 될까?
입구에 있는 것은
출력은 무엇입니까

준비: 테스트를 위한 준비 단계

매개변수 로드
설정 및 초기화
사용자
부하 매개변수,
메트릭 선택 및
테스트 계획 준비
(프로파일 로드)
사용자 지정 옵션
로드 에이전트 초기화
테스트 계획
테스트 목적

VM
클라우드 배포
가상 머신
필수 특성
로드 에이전트에 대한 VM 설정
자동화 스크립트
VM 생성
구성된 VM
구름

환경
OS 설정 및 준비
~을 위한 환경
로드 에이전트 작업
에 대한 환경 설정
로드 에이전트
자동화 스크립트
환경 설정
준비된 환경:
OS, 서비스 및 애플리케이션,
업무에 필요한
로드 에이전트

로드 에이전트
설치, 구성 및 매개변수화
로딩 에이전트.
또는 다음에서 도커 이미지를 다운로드합니다.
미리 구성된 로드 소스
소스 도커 이미지 로드
(YAT, JM 또는 자체 작성 프레임워크)
설정
로드 에이전트
설정 및 준비
작업 부하 에이전트

테스트: 부하 테스트를 실행하는 단계입니다. 소스는 GitLab CI 전용 에이전트 풀에 배포된 로드 에이전트입니다.

하중
로드 에이전트 시작
선택한 테스트 계획으로
및 로드 매개변수
사용자 옵션
초기화를 위해
로드 에이전트
테스트 계획
테스트 목적
실행 로그
부하 테스트
시스템 로그
목표 메트릭 및 부하 에이전트의 변화 역학

에이전트 실행
에이전트 실행
많은 테스트 스크립트
에 따라
로드 프로필
로드 에이전트 상호 작용
테스트 목적으로
테스트 계획
테스트 목적

로그
"원시" 로그 수집
부하 테스트 중:
에이전트 활동 기록 로드,
테스트 대상의 상태
에이전트를 실행하는 VM

실행 로그
부하 테스트
시스템 로그

통계
테스트 중 "원시" 메트릭 수집

목표 지표 변화의 역학
및 부하 에이전트

보고서: 테스트 보고서 준비 단계

발전기
수집된 처리
로딩 시스템 및
모니터링 시스템 "raw"
메트릭 및 로그
보고서 작성
사람이 읽을 수 있는 형식
요소로 가능
분석
실행 로그
부하 테스트
시스템 로그
메트릭 변화의 역학
대상 및 로드 에이전트
처리된 "원시" 로그
에 적합한 형식으로
외부 저장소에 업로드
정적 부하 보고서,
사람이 읽을 수 있는

게시이다.
보고서 발간
부하에 대해
외부에서 테스트
서비스
가공된 "원시"
적절한 형식의 로그
외부로 언로드
금고
외부에 저장됨
스토리지 보고서
하중, 적합
인간 분석을 위해

CI 템플릿에서 로드 소스 연결

실용적인 부분으로 넘어 갑시다. 회사의 일부 프로젝트에서 방법을 보여주고 싶습니다. 긍정적 인 기술 부하 테스트 개념을 서비스로 구현했습니다.

먼저 DevOps 엔지니어의 도움을 받아 부하 테스트를 실행하기 위해 GitLab CI에 전용 에이전트 풀을 만들었습니다. 어셈블리 풀과 같은 다른 템플릿과 혼동하지 않기 위해 이러한 에이전트에 태그를 추가했습니다. 태그: 짐. 다른 이해 가능한 태그를 사용할 수 있습니다. 그들이 묻다 등록 중 GitLab CI 러너.

하드웨어별로 필요한 전력을 찾는 방법은 무엇입니까? 로드 에이전트의 특성(충분한 수의 vCPU, RAM 및 디스크)은 에이전트에서 Docker, Python(Yandex.Tank의 경우), GitLab CI 에이전트, Java(Apache JMeter의 경우)가 실행되어야 한다는 사실을 기반으로 계산할 수 있습니다. . JMeter에서 Java의 경우 최소 512MB의 RAM을 사용하는 것이 좋습니다. 사용 가능한 메모리 80%.

따라서 경험을 바탕으로 로드 에이전트에 최소 4개의 vCPU, 4GB RAM, 60GB SSD를 사용하는 것이 좋습니다. 네트워크 카드의 처리량은 로드 프로필의 요구 사항에 따라 결정됩니다.

우리는 주로 Apache JMeter와 Yandex.Tank 도커 이미지라는 두 가지 로드 소스를 사용합니다.

Yandex.탱크 부하 테스트를 위한 Yandex의 오픈 소스 도구입니다. 모듈식 아키텍처는 Phantom의 고성능 비동기 적중 기반 HTTP 요청 생성기를 기반으로 합니다. 탱크에는 SSH 프로토콜을 통해 테스트 중인 서버의 리소스를 모니터링하는 기능이 내장되어 있으며 지정된 조건에서 테스트를 자동으로 중지할 수 있고 콘솔과 그래프 형식으로 결과를 표시할 수 있으며 모듈을 연결할 수 있습니다. 기능을 확장합니다. 그건 그렇고, 아직 주류가 아니었을 때 탱크를 사용했습니다. 기사에서 "Yandex.Tank 및 부하 테스트 자동화» 2013년에 부하 테스트를 수행한 방법에 대한 이야기를 읽을 수 있습니다. PT 애플리케이션 방화벽 우리 회사의 제품 중 하나입니다.

아파치 JMeter Apache의 오픈 소스 부하 테스트 도구입니다. 정적 및 동적 웹 응용 프로그램을 모두 테스트하는 데 동일하게 사용할 수 있습니다. JMeter는 HTTP, HTTPS(Java, NodeJS, PHP, ASP.NET 등), SOAP / REST 웹 서비스, FTP, TCP, LDAP, SMTP(S), POP3( S) ) 및 IMAP(S), JDBC를 통한 데이터베이스는 쉘 명령을 실행하고 Java 객체와 함께 작동할 수 있습니다. JMeter에는 테스트 계획 생성, 디버깅 및 실행을 위한 IDE가 있습니다. 모든 Java 호환 운영 체제(Linux, Windows, Mac OS X)에서 명령줄 작업을 위한 CLI도 있습니다. 이 도구는 HTML 테스트 보고서를 동적으로 생성할 수 있습니다.

회사 내에서 쉽게 사용할 수 있도록 테스터가 직접 환경을 변경하고 추가할 수 있도록 GitLab CI에서 로드 소스의 도커 이미지 빌드를 만들어 내부에 게시했습니다. Artifactory의 도커 레지스트리. 이렇게 하면 로드 테스트를 위해 파이프라인에서 더 빠르고 쉽게 연결할 수 있습니다. GitLab CI를 통해 레지스트리에 도커 푸시를 수행하는 방법 - 참조 명령.

Yandex.Tank용 기본 도커 파일을 가져왔습니다.

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

그리고 Apache JMeter의 경우 다음과 같습니다.

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

"지속적인 통합 시스템이 어떻게 작동하는지 기사에서 읽을 수 있습니다.개발 프로세스 자동화: Positive Technologies에서 DevOps 아이디어를 구현한 방법".

템플릿 및 파이프라인

부하 테스트를 수행하기 위한 템플릿의 예는 프로젝트에서 사용할 수 있습니다. 데모 로드. 에 읽어보기 파일 템플릿 사용 지침을 읽을 수 있습니다. 템플릿 자체(파일 .gitlab-ci.yml) 각 단계가 담당하는 내용에 대한 메모가 있습니다.

이 템플릿은 매우 간단하며 위의 다이어그램에 설명된 부하 테스트의 세 단계인 보고서 준비, 테스트 및 게시를 보여줍니다. 이에 대한 책임 단계: 준비, 테스트 및 보고.

1. 무대 Prepare 테스트 대상을 미리 구성하거나 가용성을 확인하는 데 사용해야 합니다. 로드 소스에 대한 환경은 구성할 필요가 없으며 도커 이미지로 미리 빌드되어 도커 레지스트리에 게시됩니다. 테스트 단계에서 원하는 버전을 지정하기만 하면 됩니다. 그러나 이를 다시 빌드하고 자신만의 수정된 이미지를 만들 수 있습니다.
2. 무대 Test 로드 소스 지정, 테스트 실행 및 테스트 아티팩트 저장에 사용됩니다. 모든 로드 소스를 선택할 수 있습니다: Yandex.Tank, Apache JMeter, 자체 또는 모두 함께. 불필요한 소스를 비활성화하려면 작업을 주석 처리하거나 삭제하십시오. 로드 소스의 진입점:
   • Yandex.Tank의 실행 매개변수는 ./테스트/yandextank.sh,
   • Apache JMeter 시작 매개변수는 파일에 지정됩니다. ./tests/jmeter.sh.

   참고: 어셈블리 구성 템플릿은 CI 시스템과의 상호 작용을 설정하는 데 사용되며 테스트 로직의 배치를 의미하지는 않습니다. 테스트의 경우 제어 bash 스크립트가 있는 진입점이 지정됩니다. 테스트 실행 방법, 보고서 생성 및 테스트 스크립트 자체는 QA 엔지니어가 구현해야 합니다. 데모에서 두 로드 소스에 대해 Yandex 기본 페이지 요청이 가장 간단한 테스트로 사용됩니다. 스크립트 및 테스트 매개변수는 디렉토리에 있습니다. ./테스트.

3. 무대 위에 Report 테스트 단계에서 얻은 테스트 결과를 외부 저장소(예: GitLab 페이지 또는 특수 보고 시스템)에 게시하는 방법을 설명해야 합니다. GitLab Pages는 ./public 디렉토리가 비어 있지 않아야 하며 테스트가 완료된 후 최소한 index.html 파일을 포함해야 합니다. GitLab Pages 서비스의 뉘앙스에 대해 읽을 수 있습니다. 링크.

   데이터를 내보내는 방법의 예:

   • JMeter에서 GitLab 페이지,
   • Yandex.Tank에서 InfluxDB 및 Grafana.

   설정 지침 게시:

   • HTML 정적 GitLab 페이지,
   • InfluxDB로 이동한 다음 그라 파나.

데모 예제에서 부하 테스트와 두 개의 부하 소스(불필요한 것은 비활성화할 수 있음)가 있는 파이프라인은 다음과 같습니다.

Apache JMeter는 HTML 보고서 자체를 생성할 수 있으므로 표준 도구를 사용하여 GitLab 페이지에 저장하는 것이 더 유리합니다. Apache JMeter 보고서는 다음과 같습니다.

Yandex.Tank의 데모 예시에서는 가짜 문자 신고 GitLab 페이지 섹션에서. 테스트 중에 Tank는 결과를 InfluxDB 데이터베이스에 저장할 수 있으며 여기에서 예를 들어 Grafana에 표시할 수 있습니다(구성은 파일에서 수행됨). ./tests/example-yandextank-test.yml). Tank의 보고서가 Grafana에서 다음과 같이 표시됩니다.

개요

기사에서는 "서비스로서의 부하 테스트"(load testing as a service)의 개념에 대해 이야기했습니다. 기본 아이디어는 미리 구성된 로드 에이전트 풀, 로드 소스의 도커 이미지, 보고 시스템 및 간단한 .gitlab-ci.yml 템플릿(예: 링크). 이 모든 것은 소규모 자동화 엔지니어 팀이 지원하고 제품 팀의 요청에 따라 복제됩니다. 이것이 귀하의 회사에서 유사한 계획을 준비하고 구현하는 데 도움이 되기를 바랍니다. 관심을 가져 주셔서 감사합니다!

PS 우리 회사에서 부하 테스트 개념을 서비스로 구현하는 데 기술 지원을 제공한 동료인 Sergey Kurbanov와 Nikolai Yusev에게 큰 감사를 전하고 싶습니다.

저자: 티무르 길멀린 - 차장 Positive Technologies의 기술 및 개발 프로세스(DevOps) 책임자

출처 : habr.com