Нагружаем и отдыхаем: load testing без стресса ч.2 — автоматизация

Привет, Хабр, это снова Валентина, которая отвечает за качество low-code платформы Eftech.Factory в компании Effective Technologies. Представляю вторую статью из серии публикаций о наших практиках нагрузочного тестирования (НТ). Первую, про поиск оптимального процесса НТ, можно прочесть здесь. На этот раз я собираюсь поделиться рекомендациями по автоматизации рутины и отчётности. 

Чтобы провести нагрузочное тестирование без стресса, надо позаботиться о сохранении своего ресурса — времени и нервов. Также мне кажется правильным освободить себя от рутинных и нудных дел, чтобы заниматься интересными и сложными задачами.

Чтобы достичь этих целей, я выработала для себя антистрессовый чек-лист из пяти пунктов:

1. Автоматизируй запуск замеров

2. Делегируй рутину боту

3. Экономь время на отчетах

4. Доверяй, но проверяй результат

5. Заботься о тестовых данных

По ним мы сегодня и пойдём:

Автоматизируй запуск замеров

Если вы новичок в НТ, вероятнее всего, вас устроит создание простых скриптов для скорейшего получения результата. Если замеры проводятся раз в год, то локальный запуск скрипта и черновые заметки о том, как он работает, вполне допустимы.

Напомню, что в моем проекте для НТ используется инструмент k6, который требует или чистого кода JavaScript, или библиотек-плагинов, написанных под k6. 

Пример локального запуска подачи нагрузки и замеров на k6

Но если в вашей команде НТ — регулярная активность, и в анализе замеров участвует команда, то есть повод задуматься об автоматизации.

Напомню, что простейший перенос вашего скрипта в любой сервис CI/CD позволит:

• не тратить мыслетопливо, вспоминая, как запустить скрипт и что подставить во входные параметры;

• отказаться от тонны документации для передачи своих знаний о работе скрипта коллегам.

У нас запуск замеров НТ оформлен в CI/CD:

K6 поднимается в Docker-контейнере и используется на последующих шагах:

build-k6:  stage: build  rules:    - when: always  script:    - |+      docker run --rm -u "$(id -u):$(id -g)" -v "${PWD}:/xk6" grafana/xk6 build v0.54.0 \      --with github.com/GhMartingit/xk6-mongo@v1.0.3 \      --with github.com/avitalique/xk6-file@v1.4.0 \      --with github.com/grafana/xk6-faker@v0.4.0 \      > docker.log 2>&1  cache:    policy: push    key: k6_binary    paths:      - ./k6  artifacts:    paths:      - "*.log"

До запуска замеров проверяем готовность контура для работы:

check:  stage: check  rules:    - when: always  script:    - ./k6 run checkStand.js -e configFile=config/preparation.json -e host="$STAGE.$PROJECT.$DOMEN" -e dbName="${STAGE}_${PROJECT}"   cache:    key: k6_binary    policy: pull    paths:      - ./k6

Файл проверок также реализован с учётом особенностей k6:

import {  expectedCountDocument,  mongoClass, } from "../../methods/base.method.js"; import { Counter } from "k6/metrics";   export const CounterErrors = new Counter("Errors"); export const options = {  iterations: 1,  thresholds: {    "Errors{case:user}": [      { threshold: "count<1", abortOnFail: true }    ],    "Errors{case:load_object_read}": [      { threshold: "count<1", abortOnFail: true },    ],    "Errors{case:load_object_write}": [      { threshold: "count<1", abortOnFail: true },    ],  }, };   export default function () {  const userCount = mongoClass.count("user");  if (userCount < expectedCountUser || userCount === undefined) {    CounterErrors.add(1, { case: "user" });  }  ...   const loadObject1ReadCount = mongoClass.count("load_object_read");  if (loadObject1ReadCount < expectedCountDocument) {    CounterErrors.add(1, { case: "load_object_read" });  }  ...   mongoClass.deleteMany("load_object_write", {});  const loadObject1WriteCount = mongoClass.count("load_object_write");  if (loadObject1WriteCount > 0) {    CounterErrors.add(1, { case: "load_object_write" });  } }

Скрипт проверяет достаточность данных — например, количество учётных записей для разнообразия авторизации или объём данных в коллекции MongoDB для замера чтения крупных реестров.

Кстати, достаточность — это не только про наличие, но и про отсутствие. Например, для скриптов, которые создают записи в базе, в нашем проекте обязательным условием является чистая коллекция до старта замеров.

Также в шаг проверки можно включить сверку конфигурации, параметров контура и т.д.

Функции k6 позволяют добавить обработку результатов для выполненных шагов скрипта.

Так если какая-либо из проверок «упадёт», то шаг pipeline также не выполнится, и замер не будет запущен.

Запуск НТ у нас конфигурируемый:

При запуске pipeline можно выбрать:

• Сценарий нагрузки

• Профиль нагрузки

variables:  STAGE:    value: "15-0-x-autotest"    description: "Название контура"  SCRIPT:    description: "Сценарий нагрузки"    value: "scripts/all"    options:      - "scripts/all"      - "scripts/auth-api"      - "scripts/featureN"      - "scripts/websocket"  CONFIG:    description: "Профиль нагрузки"    value: "config/smoke"    options:      - "config/smoke"      - "config/rampRate"      - "config/stability"

Профиль нагрузки определяет, как долго и какой поток нагрузки будет идти на контур.

• smoke — этот профиль используется для проверки контура и работоспособности скриптов. Выполняется 5 повторов каждого скрипта.

• rampRate — целевой профиль для замеров. Нагрузка подается в несколько этапов с постепенным увеличением потока.

• stability — при выборе этого профиля нагрузка подается на протяжении нескольких часов (обычно 6—8 часов) с постоянным показателем RPS.

Сценарий нагрузки позволяет выбрать набор скриптов для подачи нагрузки.

• all — этот сценарий запускает регрессионное НТ; будет выполнен каждый скрипт в репозитории.

• auth-api — сценарий, при выборе которого запускаются только скрипты для подачи нагрузки на сервис авторизации.

• feautureN — это пример; можно запустить НТ даже для отдельной функцинальности!

У Grafana Labs есть хороший пост, в котором разъясняются отличия между разными типами профилей (правда, в статье они обозначены как Types of load testing).

Уверена, что у вас возник закономерный вопрос: а как же определить, какая нагрузка стрессовая, а какая — нормальная?
И это чертовски хороший вопрос, ответа на который у меня нет)

Для каждого сервиса, функциональности или системы эти показатели индивидуальны. Они выясняются опытным путем через сопоставление поведения тестируемого объекта при определённых выделенных ресурсах и поэтапно растущей нагрузке.

Но вернёмся к коду)

Запуск замеров у нас обёрнут в bash-скрипт. Возможно, это излишне и является рудиментом. Ранее для запуска требовалась подготовка переменных, которыми не хотелось мусорить в gitlab-ci.yml.

run:  stage: measure  rules:    - if: $CI_PIPELINE_SOURCE == "pipeline"    - if: $CI_PIPELINE_SOURCE == "schedule"    - if: $CI_PIPELINE_SOURCE == "push"      when: never    - when: on_success  script:    - npm i    - start=$(date +%s)    - echo run.sh -h $STAGE -p $PROJECT -s $SCRIPT -d $DOMEN -c $CONFIG    - ./run.sh -h $STAGE -p $PROJECT -s $SCRIPT -d $DOMEN -c $CONFIG    - end=$(date +%s)    - echo $start > start    - echo $end > end  after_script:    - dashboardLT="${URL_GRAFANA_K6_FOR_QA}&from=$(cat start)000&to=$(cat end)000"    - dashboardServices="${URL_GRAFANA_FACTORY_SERVICES}&from=$(cat start)000&to=$(cat end)000"    - node tools/scripts/notification.js $STAGE $CI_COMMIT_BRANCH $CI_TELEGRAM_CHAT $CI_TELEGRAM_TOKEN $CI_JOB_ID $SCRIPT "$dashboardLT" "$dashboardServices" $CONFIG  cache:    key: k6_binary    policy: pull    paths:      - ./k6  artifacts:    paths:      - ./report    expire_in: 2 week    name: ${STAGE}

И сам bash-скрипт…

#!/bin/bash while getopts h:p:s:d:c: flag do    case "${flag}" in        h)          STAGE=${OPTARG}          ;;        p)          PROJECT=${OPTARG}          ;;        s)          SCRIPT=${OPTARG}          ;;        d)          DOMEN=${OPTARG}          ;;        c)          CONFIG=${OPTARG}          ;;        *)         echo "Не корректный ключ. Проверьте введенные ключи $OPTARG";;    esac done   [ -z "$STAGE" ] && STAGE="15-0-x-autotest" [ -z "$PROJECT" ] && PROJECT="factory" [ -z "$SCRIPT" ] && SCRIPT="scripts/all" [ -z "$DOMEN" ] && DOMEN="lowcode" [ -z "$CONFIG" ] && CONFIG="config/smoke"   if [[ $SCRIPT == "scripts/all" ]]; then  folderPath=$(find scripts/* -type d ) else  folderPath="$SCRIPT" fi   for path in $folderPath; do    for script in "$path"/*.js; do        ./k6 run "$script" -e configFile="$CONFIG" -e host="$STAGE.$PROJECT.$DOMEN" -e dbName="${STAGE}_${PROJECT}" --insecure-skip-tls-verify -o experimental-prometheus-rw        echo "$script", "$?" >>exitCode.txt    done done 

В зависимости от значения, переданного для сценария нагрузки, будут последовательно запущены скрипты из указанной папки.

После выполнения каждого скрипта в файл exitCode.txt записывается код выполнения. 

Мы фиксируем как время старта, так и время окончания общего замера — эти показатели подставляются в ссылку Grafana, которую бот отправит после завершения замеров.

Про бота и использование файла exitCode.txt я подробно расскажу ниже.

Какими могут быть следующие шаги развития автозапуска и конфигурирования?

• Встраивание запуска замеров при средней нагрузке в регулярный запуск проверки релиза.

• Проведение НТ при динамическом масштабировании.

• Перспективы тестирования выносливости, стресса и восстановления системы или продукта.

Делегируй рутину боту

Как не дёргаться, проверяя, завершились ли замеры НТ?

Нотификация нам в помощь! В Интернете много документации и примеров по реализации ботов для различных мессенджеров.

Рассмотрим реализацию нотификации в Telegram. Обязательным условием является предварительная подготовка бота.

В силу использования k6, нам потребуется или чистый код на Javascript, или библиотека-плагин, написанная под k6.

Поэтому у нас несколько вариантов:

• реализовать нотификацию через API Telegram;

• использовать плагин k6 — xk6-telegram.

Второй вариант кажется проще, начнём с него.

На странице документации к k6 есть раздел с расширениями.

Расширения создаются и поддерживаются как разработчиками k6, так и сообществом вокруг проекта.

xk6-telegram является одним из таких расширений. Оно разработано сообществом и упоминается в списке официально предлагаемых от k6, но его поддержка не гарантируется. Тем не менее, для старта можно использовать и его)

За основу кода берем пример из документации:

import http from "k6/http"; import telegram from "k6/x/telegram";   const conn = telegram.connect(`${__ENV.TOKEN}`, false); const chatID = 123456789;   const environment = 'load_stand'; const link = 'https://grafana.com/';   export default function () {    http.get('http://test.k6.io'); }   export function teardown() {    const body =  `<b>Load testing</b> ${environment} \r\n`+        `<b>Dashboard</b>: <a href="${link}">K6 Result</a>`;      telegram.send(conn, chatID, body); }

Что мы получаем?

Инструмент k6 выполняет код в скрипте последовательно: setup (пред-подготовка), function (основной код), teardown (пост-подготовка).

Как только замеры завершатся, с ошибкой или без неё, на финальном этапе (teardown) будет отправлено сообщение по указанному chatID.

Код отправки сообщения можно унифицировать для всех скриптов и вынести в отдельный наследуемый метод.

Для моего проекта простого уведомления о завершении расчетов мало.

Я бы хотела получать минимально необходимую информацию о выполненном замере.

Чтобы это стало возможным, мне потребовалось реализовать логику обработки результатов и сбор данных. А отправка уведомления реализована через вызов API Telegram.

В нашем проекте нотификация вынесена на уровень всего запуска замеров. 

В .gitlab-ci.yml в блоке after_script вызывается 

node tools/scripts/notification.js args

tools/scripts/notification.js содержит всю логику по подготовке и отправке сообщения боту.

Полный текст кода вы можете просмотреть по ссылке.

На вход скрипту передаются данные, объявленные в job pipeline: 

• название контура, на котором запускались замеры (у нас для каждого релиза готовится свой контур — для сценария, когда требуется сделать замеры в текущем и прошлом релизах);

• ветка со скриптами, которые выполнялись;

• название профиля нагрузки;

• jobID (чтобы отправить в сообщении ссылку на артефакты Gitlab).

Далее выполняется подготовка данных для сообщения.

Стоит отметить, что exitCode от выполнения k6 у нас записывается в отдельный файл.

Для каждого скрипта вызывается k6 run script.js, и результат записывается в файл exitCode.txt.

На этапе подготовки данных для сообщения файл обрабатывается, строится цветовая градация успешности выполнения. Это не обязательно, но позволяет сразу сориентироваться в результате.

Только после этого вызывается отправка сообщения.

Экономь время на отчётах

Итак, у нас есть автоматизированный запуск в 2 клика, и бот своевременно уведомляет нас о завершении замеров. Это значит, что следующий этап — автоматизация отчётности.

Какой бы сервис для подачи нагрузки вы ни выбрали, в нём почти всегда есть стандартный отчёт с минимально необходимыми метриками.

В k6 вывод результатов выглядит так:

Такого среза достаточно, чтобы сделать выводы о замере и спланировать следующие действия.

А теперь представим, что необходимо сделать несколько разноплановых замеров и свести их результаты в удобно читаемый отчёт для руководства.

Failure story: раньше я, засучив рукава, погружалась в океан цифр и сводила их вручную. И хорошенько выгорала на этом!

Антиcтресс рекомендация: не поленитесь настроить простую интеграцию Prometheus-Grafana.

В нашем проекте k6 собирает метрики нагрузки, передаёт в Prometheus, а Grafana на основе этих данных строит графики и сводки таблиц.

В итоге мы получаем единое хранилище результатов и динамическую визуализацию:

• Контроль показателей машины с тестируемым сервисом:

  

• Показатели состояния тестируемого сервиса:

  

• Метрики нагрузки:

Если вы только стартуете в НТ или присматриваетесь к сервисам нагрузки, то платные Enterprise-решения вам не доступны. Но какие же у них интересные возможности!

Например, Grafana Cloud предлагает обработать результаты замеров и показать их в сравнении между несколькими итерациями.

Когда очень хочется, но дорого, единственный выход — создать свой «велосипед».

Наши DevOps подготовили свой Grafana дашборд для анализа метрик нагрузки, в том числе с возможностью сравнения между несколькими замерами:

Разберёмся, как это работает.

Представьте себе ситуацию, когда НТ выполнялось в несколько итераций в течение ночи.

Нагрузка росла этапами — и так для каждого из скриптов.

{  "summaryTrendStats": ["avg", "p(90)", "p(95)", "p(99)", "count"],  "scenarios": {    "rampRate": {      "executor": "ramping-arrival-rate",      "maxVUs": 400,      "preAllocatedVUs": 1,      "timeUnit": "1s",      "stages": [        { "target": 5, "duration": "1m" },        { "target": 5, "duration": "5m" },        { "target": 10, "duration": "1m" },        { "target": 10, "duration": "5m" },        { "target": 20, "duration": "1m" },        { "target": 20, "duration": "5m" },        { "target": 40, "duration": "1m" },        { "target": 40, "duration": "5m" }      ]    }  } } 

Что делает такой профиль?

• stage0: минутный рост нагрузки до 5 RPS 

• stage1: стабильная нагрузка в 5 RPS

• stage2: минутный рост нагрузки до 10 RPS

• stage3: стабильная нагрузка в 10 RPS

• stage4: минутный рост нагрузки до 20 RPS

• stage5: стабильная нагрузка в 20 RPS

• stage6: минутный рост нагрузки до 40 RPS

• stage7: стабильная нагрузка в 40 RPS

С утра вы садитесь за анализ результатов.

Общая сводка позволяет сделать предварительные выводы, но для заключения о качестве нужны более точные сравнения.

Идеальным было бы точечное сравнение показаний по каждому сценарию.

Например, вот такой сводной таблицей:

Но и такое решение не идеально, ведь нагрузка подавалась этапами с возрастанием потока!

Такой у нас получается визуализация выполнения скрипта «Login» с градацией по этапам нагрузки:

Код плитки: https://disk.yandex.ru/d/j80WalY5BAqZ8g

Мне как создателю скриптов понятно, что при росте нагрузки до 20 RPS (stage4) начинается деградация в работе авторизации.

А если заглянуть ещё на уровень глубже, то можно узнать, что проблема конкретно в запросе logout.

Но есть одно «но»…

Отчетом пользуюсь не я одна, и надо, чтобы графики читались легко и не вызывали вопросов.

Поэтому думаем, как сравнить графики на основе подаваемой нагрузки в RPS.

У нас начинает получаться что-то такое:

Выводы те же: до определенной нагрузки API сервиса справляется с потоком, а после начинается «расколбас».

Далее можно настроить такой же график для каждого API внутри сценария или оставить вывод в таблице.

Код плиток в обеих вариациях можно найти по ссылке.

Доверяй, но проверяй результат

Теперь нас не отвлекает механика замера, а наглядный отчёт позволяет быстрее проанализировать результаты. А значит, можно заняться проблемой качества кода в скриптах нагрузки.

Failure story

Мне достаточно вспомнить этот эпический провал, а вы представьте ситуацию.

Допустим, есть задача — протестировать скорость ответа API для запроса авторизации в сравнении между двумя релизами.

Ниже приведён код. У нас в скрипте всего 1 запрос, который выполняется для различных учётных записей:

import http from "k6/http"; import { scenario } from "k6/execution";  … export default function (loginArray) {  const body = {    login: loginArray[scenario.iterationInTest % loginArray.length],    password: commonPassword,  };  http.post(`${host}/api/auth/login`, body); } 

Результат прошлого релиза у нас уже был, а замеры на новой версии выдают потрясающий результат. Ускорение в 2 раза! 

Мы с командой празднуем победу, а я начинаю готовить отчет о проделанной работе… И тут замечаю по логам, что все 100% запросов вернули ошибку.

Больно, обидно, познавательно.

Теория НТ не рекомендует усложнять скрипты нагрузки генерацией данных и функциональными проверками. Но минимально необходимые проверки результата нужны!

Часто сервисы генерации нагрузки предоставляют функции для проверок данных и результатов, которые не отъедают ресурсы.

А после можно задуматься о выставлении порогов (критериев успеха или провала).

Например, если запрос выполняется дольше 200 мс, мы получим цветовую нотификацию о пересечении выставленной границы.

Также можно настроить остановку выполнения скрипта, если показатели вышли за заданный порог.

Согласитесь, удобнее получить сообщение от бота с предупреждением о неожиданном поведении сервиса, чем «красный»‎ отчет после 2-х часов ожидания.

Как ещё можно развить проверки?

• Комбинировать проверки и пороги (с возможностью остановки скрипта).

• Настроить пороги для каждого из этапов нагрузки.

• Настроить разные уровни реагирования (приемлемо / тревожно / неправильно).

Заботься о тестовых данных

Failure story

Представим ситуацию, когда вы по наитию решаете выполнить один и тот же скрипт несколько раз подряд. (Реальная история, которую я снова вспоминаю с красными щеками!)

Вы сводите результаты в одну таблицу и получаете радугу, как у меня на картинке:

Первая же мысль у нас с командой: «Допустили утечку ресурсов!»

Но, как оказалось, проблема крылась в другом)

При запуске регрессионного НТ запускались скрипты не только на чтение данных, но и на запись! Из-за этого коллекции в базе данных «пухли» с каждой итерацией.

Теория НТ настаивает на выполнении нескольких однотипных замеров друг за другом.

Какие же выводы мы сделали из этой глупейшей ошибки?

Перед стартом замеров рекомендуется: 

• проверять наличие, достаточность и соответствие ожидаемому объему данных
  (в том числе — их отсутствие);

• подготовить генерацию однотипных данных.

Что ещё можно улучшить?

• Автоматизировать проверки наличия настроек и других конфигураций данных.

• Автоматически очищать отдельные коллекции или даже запускать сброс БД в исходное состояние.

• Оценить возможность импорта БД перед замерами при потребности в большом срезе данных.

Послесловие

Повторю свою мысль из первой статьи: ошибаться — это нормально. Ошибки — это опыт, который учит нас расширять горизонты и становиться лучше.

Путь в НТ тернист, но жутко интересен! Проблем, с которыми вы можете столкнуться, гораздо больше, чем упомянуто в статье. Но это повод пересмотреть свой опыт и подумать об автоматизации. 

Также хочу порекомендовать Телеграм-канал «QA — Load & Performance». С ним я познакомилась, когда готовилась к выступлению на конференции Heisenbug, и была приятно удивлена, найдя там отзывчивое сообщество специалистов в нагрузочном тестировании.