Адна з праблем, з якімі часта сутыкаюцца мультыпрадуктовыя вендары ПЗ, гэта дубліраванне кампетэнцый інжынераў - распрацоўшчыкаў, тэсціроўшчыкаў і адміністратараў інфраструктуры - амаль у кожнай камандзе. Гэта датычыцца і дарагіх інжынераў - спецыялістаў у галіне нагрузачнага тэсціравання.
Замест таго, каб займацца сваімі прамымі абавязкамі і выкарыстоўваць свой унікальны вопыт для выбудоўвання працэсу нагрузачнага тэсціравання, выбіраць метадалогію, аптымальныя значэнні метрык і пісаць аўтатэсты ў адпаведнасці з профілямі нагрузкі, інжынерам часта даводзіцца з нуля разгортваць тэставую інфраструктуру, наладжваць інструменты нагрузкі, самім убудоўваць іх у CI-сістэмы, наладжваць маніторынг і публікацыю справаздач.
Рашэнні некаторых арганізацыйных праблем у тэсціраванні, якія мы ўжываем у Positive Technologies, вы можаце знайсці ў . А ў гэтай я распавяду пра магчымасць інтэграцыі нагрузачных тэстаў у агульны CI-канвеер з дапамогай канцэпцыі "нагрузачнае тэсціраванне як сэрвіс" (load testing as a service). Вы даведаецеся, як і якія докер-вобразы крыніц нагрузкі можна выкарыстоўваць у CI-канвееры; як падлучыць крыніцы нагрузкі ў свой CI-праект пры дапамозе зборачнага шаблону; як выглядае дэмапайплайн для запуску нагрузачных тэстаў і публікацыі вынікаў. Артыкул можа быць карыснай інжынерам па тэставанні ПА і інжынерам-аўтаматызатарам у CI, хто задумаўся аб архітэктуры сваёй нагрузачнай сістэмы.
Сутнасць канцэпцыі
Канцэпцыя load testing as a service мае на ўвазе магчымасць інтэграваць прылады нагрузкі Apache JMeter, Yandex.Tank і ўласныя фрэймворкі ў адвольную сістэму continuous integration. Дэмапрыклад будзе для GitLab CI, але прынцыпы выкладзены агульныя для ўсіх CI-сістэм.
Load testing as a service - гэта цэнтралізаваны сэрвіс для правядзення нагрузачнага тэсціравання. Нагрузачныя тэсты запускаюцца ў выдзеленых пулах агентаў, публікацыя вынікаў адбываецца аўтаматычна ў GitLab Pages, Influx DB і Grafana або ў сістэмы тэст-рэпартынгу (TestRail, ReportPortal і т. п.). Аўтаматызацыя і маштабаванне рэалізуюцца максімальна проста - праз даданне і параметрызацыю ў праекце GitLab CI звычайнага шаблону gitlab-ci.yml.
Перавага падыходу заключаецца ў тым, што ўся CI-інфраструктура, нагрузачныя агенты, докер-вобразы крыніц нагрузкі, пайплайны тэсціравання і публікацыя справаздач - падтрымліваюцца сіламі цэнтралізаванага аддзела аўтаматызацыі (DevOps-інжынерамі), а інжынеры па нагрузачным тэсціраванні могуць засяродзіць свае намаганні на распрацоўцы сваіх намаганняў. і аналізе іх вынікаў, не займаючыся інфраструктурнымі пытаннямі.
Для прастаты апісання будзем лічыць, што мэтавае тэставанае прыкладанне або сервер ужо разгорнутыя і наладжаны загадзя (для гэтага могуць быць скарыстаны аўтаматызаваныя сцэнары на Python, SaltStack, Ansible і інш.). Тады ўся канцэпцыя нагрузачнага тэсціравання як сэрвісу ўкладваецца ў тры этапы: падрыхтоўка, тэсціраванне, публікацыя справаздач. Падрабязней на схеме (усе карцінкі клікабельны):
Асноўныя паняцці і вызначэнні ў нагрузачным тэсціраванні
Пры правядзенні нагрузачных выпрабаванняў мы стараемся прытрымлівацца. , выкарыстоўваем адпаведную тэрміналогію і рэкамендуемыя метрыкі. Прывяду кароткі пералік асноўных паняццяў і азначэнняў у нагрузачным тэсціраванні.
Нагрузачны агент (load agent) - Віртуальная машына, на якой будзе запушчана дадатак - крыніца нагрузкі (Apache JMeter, Yandex.Tank або самапісны нагрузачны модуль).
Мэта тэсціравання (target) - сервер або дадатак, устаноўленае на серверы, якое будзе падвяргацца нагрузцы.
Тэставы сцэнар (test case) - Набор параметрызаваных крокаў: дзеянні карыстальнікаў і чаканыя рэакцыі на гэтыя дзеянні, з зафіксаванымі сеткавымі запытамі і адказамі, у залежнасці ад зададзеных параметраў.
Профіль ці план нагрузкі (profile) - у (п. 4.2.4, стар. 43) профілі нагрузкі вызначаюць крытычна важныя для канкрэтнага тэсту метрыкі і варыянты змены параметраў нагрузкі на працягу тэсту. Прыклады профіляў вы можаце бачыць на малюнку.
Тэст (test) - сцэнар з загадзя вызначаным наборам параметраў.
Тэст-план (test-plan) - Набор тэстаў і профіль нагрузкі.
Тэстран (testrun) - адна ітэрацыя запуску аднаго тэсту з цалкам выкананым сцэнарам нагрузкі і атрыманай справаздачай.
Сеткавы запыт (request) - HTTP-запыт, які адпраўляецца ад агента да мэты.
Сеткавы адказ (response) - HTTP-адказ, які адпраўляецца ад мэты да агента.
HTTP-код адказу (HTTP responses status) - стандартны код адказу ад сервера прыкладанняў.
Транзакцыя (transaction) - поўны цыкл "запыт - адказ". Транзакцыя лічыцца ад пачатку адпраўкі запыту (request) да завяршэння прыёму адказу (response).
Статус транзакцыі (transactions status) - Ці атрымалася паспяхова завяршыць цыкл "запыт - адказ". Калі ў гэтым цыкле была любая памылка, то ўся транзакцыя лічыцца няўдалай.
Час водгуку (latency) - Час ад заканчэння адпраўкі запыту (request) да пачатку прыёму адказу (response).
Метрыкі нагрузкі (metrics) - вызначаныя падчас нагрузачнага тэставання характарыстыкі нагружанага сэрвісу і нагрузачнага агента.
Асноўныя метрыкі для вымярэння параметраў нагрузкі
Некаторыя найбольш агульнаўжывальныя і рэкамендуемыя ў метадалогіі (стар. 36, 52) метрыкі прыведзены ў табліцы ніжэй. Падобныя метрыкі для агента і мэты пазначаны ў адным радку.
Метрыкі для нагрузачнага агента
Метрыкі мэтавай сістэмы або прыкладанні, якія тэстуюцца пад нагрузкай
Колькасць vCPU і памяці RAM,
Дыск - «жалезныя» характарыстыкі нагрузачнага агента
CPU, Memory, Disk usage - дынаміка загрузкі працэсара, памяці і дыска
у працэсе тэсціравання. Звычайна вымяраецца ў працэнтах ад
максімальна даступных значэнняў
Прапускная здольнасць сеткі (on load agent) - прапускная здольнасць
сеткавага інтэрфейсу на серверы,
дзе ўсталяваны нагрузачны агент.
Звычайна вымяраецца ў байтах у секунду (bps)
Прапускная здольнасць сеткі(on target) - прапускная здольнасць сеткавага інтэрфейсу
на мэтавым сэрвэры. Звычайна вымяраецца ў байтах у секунду (bps)
Віртуальныя карыстальнікі- колькасць віртуальных карыстальнікаў,
рэалізуюць сцэнары нагрузкі і
якія імітуюць рэальныя дзеянні карыстальнікаў
Virtual users status, Passed/Failed/Total – колькасць паспяховых і
няўдалых статусаў працы віртуальных карыстальнікаў
для сцэнарыяў нагрузкі, а таксама іх агульная колькасць.
Звычайна чакаецца, што ўсе карыстачы змаглі выканаць
усе свае задачы, указаныя ў профілі нагрузкі.
Любая памылка будзе азначаць, што і рэальны карыстач не зможа
вырашыць сваю задачу пры рабоце з сістэмай
Requests per second (minute)- Колькасць сеткавых запытаў у секунду (ці хвіліну).
Важная характарыстыка нагрузачнага агента: колькі ён можа генераваць запытаў.
Фактычна гэта імітацыя звароту да дадатку віртуальнымі карыстальнікамі.
Responses per second (minute)
- Колькасць сеткавых адказаў у секунду (ці хвіліну).
Важная характарыстыка мэтавага сэрвісу: колькі ўдалося
згенераваць і адправіць адказаў на запыты з
нагрузачнага агента
HTTP responses status- колькасць розных кодаў адказу
ад сервера прыкладання, атрыманых нагрузачным агентам.
Напрыклад, 200 OK азначае паспяховы зварот,
а 404 - што рэсурс не знойдзены
латэнтнасьць (час водгуку) - час ад заканчэння
адпраўкі запыту (request) да пачатку прыёму адказу (response).
Звычайна вымяраецца ў мілісекундах (ms)
Transaction response time- час адной поўнай транзакцыі,
завяршэнне цыклу "запыт - адказ".
Гэты час ад пачатку адпраўкі запыту (request)
да завяршэння прыёму адказу (response).
Час транзакцыі можа вымярацца ў секундах (ці хвілінах)
некалькімі спосабамі: лічаць мінімальнае,
максімальнае, сярэдняе і, напрыклад, 90-й перцентиль.
Мінімальныя і максімальныя паказанні - гэта крайнія
стану прадукцыйнасці сістэмы.
Дзевяносты перцентиль выкарыстоўваецца найбольш часта,
паколькі ён паказвае большасць карыстальнікаў,
камфортна якія працуюць на парозе прадукцыйнасці сістэмы
Transactions per second (minute) - колькасць поўных
транзакцый у секунду (хвіліну),
гэта значыць колькі прыкладанне змагло прыняць і
апрацаваць запытаў і выдаць адказаў.
Фактычна гэта прапускная здольнасць сістэмы
Transactions status , Passed / Failed / Total - колькасць
паспяховых, няўдалых і агульная колькасць транзакцый.
Для рэальных карыстальнікаў няўдачная
транзакцыя фактычна будзе азначаць
немагчымасць працаваць з сістэмай пад нагрузкай
Прынцыповая схема нагрузачнага тэсціравання
Прынцыповая схема нагрузачнага тэсціравання вельмі простая і складаецца з трох асноўных этапаў, пра якія я ўжо згадваў: Prepare - Test - Report, гэта значыць падрыхтоўка мэт тэставання і заданне параметраў для крыніц нагрузкі, затым выкананне нагрузачных тэстаў і, у канцы, фарміраванне і публікацыя справаздачы аб тэсціраванні.
Нататкі да схемы:
- QA.Tester - эксперт па нагрузачным тэсціраванні,
- Target - мэтавае дадатак, для якога трэба даведацца яго паводзіны пад нагрузкай.
Класіфікатар сутнасцяў, этапаў і крокаў на схеме
Этапы і крокі
Што адбываецца
Што на ўваходзе
Што на выхадзе
Prepare: этап падрыхтоўкі да тэсціравання
LoadParameters
Заданне і ініцыялізацыя
карыстальнікам
параметраў нагрузкі,
выбар метрык і
падрыхтоўка тэст-плана
(профіля нагрузкі)
Карыстальніцкія параметры для
ініцыялізацыі агента нагрузкі
Тэст-план
Мэта тэсціравання
VM
Разгортванне ў воблаку
віртуальнай машыны з
патрабаванымі характарыстыкамі
Параметры ВМ для агента нагрузкі
Скрыпты аўтаматызацыі для
стварэння ВМ
Настроеная ВМ у
воблаку
Адправіць
Настройка АС і падрыхтоўка
акружэння для
працы нагрузачнага агента
Параметры асяроддзя для
агента нагрузкі
Скрыпты аўтаматызацыі для
налады асяроддзя
Падрыхтаванае асяроддзе:
АС, сэрвісы і прыкладанні,
неабходныя для працы
агента нагрузкі
LoadAgents
Ўстаноўка, настройка і параметрызацыя
нагрузачнага агента.
Або запампоўка докер-выявы з
пераднастроенай крыніцай нагрузкі
Докер-вобраз крыніцы нагрузкі
(ЯТ, JM або самапісны фрэймворк)
Параметры наладкі
агента нагрузкі
Настроены і гатовы
да працы агент нагрузкі
Test: этап выканання нагрузачных тэстаў. Крыніцамі з'яўляюцца агенты нагрузкі, разгорнутыя ў выдзеленых пулах агентаў для GitLab CI
Нагрузка
Запуск агента нагрузкі
з абраным тэст-планам
і параметрамі нагрузкі
Карыстальніцкія параметры
для ініцыялізацыі
агента нагрузкі
Тэст-план
Мэта тэсціравання
Логі выканання
нагрузачных тэстаў
Сістэмныя часопісы
Дынаміка змены метрык мэты і нагрузачнага агента
RunAgents
Выкананне агентам
нагрузкі тэставых сцэнарыяў
у адпаведнасці з
профілем нагрузкі
Узаемадзеянне агента нагрузкі
з мэтай тэсціравання
Тэст-план
Мэта тэсціравання
Logs
Збор "волкіх" логаў
у працэсе нагрузачнага тэсціравання:
запісы аб дзеяннях агента нагрузкі,
стане мэты тэсціравання
і ВМ, на якой запушчаны агент
Логі выканання
нагрузачных тэстаў
Сістэмныя часопісы
Метрыка
Збор «волкіх» метрык падчас тэставанняў
Дынаміка змены метрык мэты
і нагрузачнага агента
Report: этап падрыхтоўкі справаздачы аб тэсціраванні
Генератар
Апрацоўка сабраных
нагрузачнай сістэмай і
сістэмай маніторынгу "волкіх"
метрык і логаў
Фарміраванне справаздачы ў
чалавекачытаемым выглядзе,
магчыма з элементамі
аналітыкі
Логі выканання
нагрузачных тэстаў
Сістэмныя часопісы
Дынаміка змены метрык
мэты і нагрузачнага агента
Апрацаваныя "волкія" логі
у фармаце, прыдатным для
выгрузкі ў вонкавыя сховішчы
Статычны справаздачу аб нагрузцы,
прыдатны для аналізу чалавекам
Апублікаваць
Публікацыя справаздачы
аб нагрузачным
тэсціраванні ў знешнім
сэрвісе
Апрацаваныя "волкія"
логі ў фармаце, прыдатным
для выгрузкі ў вонкавыя
сховішчы
Захаваныя ў вонкавым
сховішча справаздачы аб
нагрузцы, прыдатныя
для аналізу чалавекам
Падлучэнне крыніц нагрузкі ў CI-шаблоне
Пяройдзем да практычнай часткі. Я хачу паказаць, як на некаторых праектах у кампаніі мы рэалізавалі канцэпцыю нагрузачнага тэсціравання як сэрвісу.
Спачатку сіламі нашых DevOps-інжынераў мы стварылі ў GitLab CI выдзелены пул агентаў для запуску нагрузачных тэстаў. Каб не блытаць іх у шаблонах з іншымі, напрыклад зборачнымі, пуламі, мы дадалі тэгі на гэтыя агенты, : load. Можна выкарыстоўваць любыя іншыя зразумелыя тэгі. Яны задаюцца GitLab CI Runners.
Як пазнаць патрабаваную магутнасць па «жалезу»? Характарыстыкі нагрузачных агентаў – дастатковая колькасць vCPU, RAM і Disk – могуць быць разлічаны зыходзячы з таго, што на агенце павінны быць запушчаныя Docker, Python (для Yandex.Tank), агент GitLab CI, Java (для Apache JMeter). Для Java пад JMeter таксама рэкамендуюць выкарыстоўваць мінімум 512 МБ RAM і, у якасці верхняй мяжы, .
Такім чынам, зыходзячы з нашага досведу, мы рэкамендуем выкарыстоўваць для нагрузачных агентаў як мінімум: 4 vCPU, 4 ГБ RAM, 60 ГБ SSD. Прапускная здольнасць сеткавай карты вызначаецца на аснове патрабаванняў профіля нагрузкі.
У нас у асноўным выкарыстоўваюцца дзве крыніцы нагрузкі - докер-вобразы Apache JMeter і Yandex.Tank.
— гэта апенсорсны інструмент кампаніі Yandex для правядзення нагрузачнага тэсціравання. У аснове яго модульнай архітэктуры – высокапрадукцыйны асінхронны hit-based-генератар HTTP-запытаў Phantom. Танк мае ўбудаваны маніторынг рэсурсаў тэстоўванага сервера па пратаколе SSH, можа аўтаматычна спыніць тэст па зададзеных умовах, умее выводзіць вынікі як у кансоль, так і ў выглядзе графікаў, да яго можна падлучыць свае модулі для пашырэння функцыянальнасці. Дарэчы, мы выкарыстоўвалі Танк, калі гэта яшчэ не было мэйнстрымам. У артыкуле «» можна прачытаць гісторыю, як у 2013-ым мы праводзілі з яго дапамогай нагрузачнае тэставанне - Аднаго з прадуктаў нашай кампаніі.
— гэта апенсорсны інструмент для правядзення нагрузачнага тэсціравання кампаніі Apache. Ён можа аднолькава добра выкарыстоўвацца як для тэставання статычных, так і дынамічных вэб-прыкладанняў. JMeter падтрымлівае велізарную колькасць пратаколаў і спосабаў узаемадзеяння з прыкладаннямі: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET і т. д.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3(S ) і IMAP(S), базы дадзеных праз JDBC, умее выконваць shell-каманды і працаваць з Java-аб'ектамі. У JMeter ёсць IDE для стварэння, адладкі і выкананні тэст-планаў. Таксама маецца CLI для працы ў камандным радку любой сумяшчальнай з Java АС (Linux, Windows, Mac OS X). Інструмент умее дынамічна генераваць HTML-справаздачу аб тэставанні.
Для зручнасці выкарыстання ўнутры нашай кампаніі, для магчымасці самім тэсціроўшчыкам змяняць і дадаваць асяроддзе мы зрабілі зборкі докер-вобразаў крыніц нагрузкі на GitLab CI з публікацыяй ва ўнутраны . Так атрымліваецца хутчэй і прасцей падключаць іх у пайплайнах для нагрузачных тэстаў. Як зрабіць docker push у registry праз GitLab CI - глядзіце ў .
Базавы докер-файл для Yandex.Tank мы ўзялі гэты:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]А для Apache JMeter гэты:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Як уладкована наша сістэма continuous integration, вы можаце прачытаць у артыкуле «.
Шаблон і пайплайн
Прыклад шаблону для правядзення нагрузачных тэстаў даступны ў праекце . У можна прачытаць інструкцыю па выкарыстанні шаблона. У самім шаблоне (файл ) ёсць заўвагі аб тым, за што адказвае той ці іншы крок.
Шаблон вельмі просты і дэманструе тры этапы нагрузачнага тэсціравання, апісаных вышэй на схеме: падрыхтоўка, тэсціраванне і публікацыя справаздач. За гэта адказваюць : Prepare, Test і Report.
- этап варта выкарыстоўваць для папярэдняй налады мэт тэставання ці праверкі іх даступнасці. Асяроддзе для крыніц нагрузкі наладжваць не патрабуецца, яны загадзя сабраны як докер-вобразы і выкладзены ў docker registry: досыць пазначыць патрэбную версію на этапе Test. Але можна перасабраць іх і зрабіць свае мадыфікаваныя выявы.
- этап выкарыстоўваецца для ўказання крыніцы нагрузкі, запуску тэстаў і захавання артэфактаў тэсціравання. Можна выбраць любую крыніцу нагрузкі: Yandex.Tank, Apache JMeter, свой ці ўсе разам. Для адключэння непатрэбных крыніц дастаткова закаментаваць або выдаліць job-у. Кропкі ўваходу для крыніц нагрузкі:
- параметры запуску Yandex.Tank паказваюцца ў файле.,
- параметры запуску Apache JMeter паказваюцца ў файле .
Нататка: шаблон зборачнай канфігурацыі выкарыстоўваецца для налады ўзаемадзеяння з CI-сістэмай і не мяркуе месцаванні ў ім логікі тэстаў. Для тэстаў паказваецца кропка ўваходу, дзе знаходзіцца кіраўнік bash-скрыпт. Спосаб запуску тэстаў, фарміраванне справаздач і самі тэставыя сцэнары - павінны быць рэалізаваны QA-інжынерамі. У дэмапрыклады для абедзвюх крыніц нагрузкі ў якасці найпростага тэсту выкарыстоўваецца рэквест асноўнай старонкі Яндэкса. Сцэнары і параметры тэстаў ляжаць у каталогу .
- На этапе трэба апісаць спосабы публікацыі вынікаў тэставання, атрыманых на этапе Test, у вонкавыя сховішчы, напрыклад у GitLab Pages або адмысловыя сістэмы справаздачнасці. Для GitLab Pages патрабуецца, каб пасля канчатка тэстаў каталог ./public быў няпусты і ўтрымоўваў прынамсі файл index.html. Аб нюансах працы сэрвісу GitLab Pages вы можаце прачытаць .
Прыклады, як экспартаваць дадзеныя:
- з JMeter у ,
- з Yandex.Tank у .
Інструкцыі па наладзе публікацыі:
- HTML-статыкі ў ,
- у InfluxDB і затым у .
У дэмапрыклады пайплайн з нагрузачнымі тэстамі і двума крыніцамі нагрузкі (можна адключыць непатрэбны) выглядае так:
Apache JMeter умее сам фармаваць HTML-справаздач, таму яго выгодней захоўваць у GitLab Pages штатнымі сродкамі. Вось так выглядае справаздача Apache JMeter:
У дэмапрыклады для Yandex.Tank вы ўбачыце толькі у раздзеле для GitLab Pages. Падчас тэставанняў Танк умее захоўваць вынікі ў базу InfluxDB, а адтуль іх можна адлюстраваць, напрыклад, у Grafana (налада выконваецца ў файле ). Вось так справаздача Танка выглядае ў Grafana:
Рэзюмэ
У артыкуле я распавёў пра канцэпцыю "нагрузачнае тэсціраванне як сэрвіс" (load testing as a service). Асноўная ідэя складаецца ў выкарыстанні інфраструктуры преднастроенных пулаў нагрузачных агентаў, докер-вобразаў крыніц нагрузкі, сістэм справаздачнасці і які аб'ядноўвае іх пайплайна ў GitLab CI на базе простага шаблону .gitlab-ci.yml (прыклад ). Усё гэта падтрымліваецца сіламі невялікай каманды інжынераў-аўтаматызатараў і тыражуецца па запыце прадуктовых каманд. Спадзяюся, гэта дапаможа вам у падрыхтоўцы і рэалізацыі аналагічнай схемы ў вашай кампаніі. Дзякуй за ўвагу!
PS Хачу сказаць вялікі дзякуй маім калегам, Сяргею Курбанаву і Мікалаю Юсеву, за тэхнічную дапамогу з рэалізацыяй канцэпцыі load testing as a service у нашай кампаніі.
Аўтар: - нам. кіраўніка аддзела тэхналогій і працэсаў распрацоўкі (DevOps) кампаніі Positive Technologies
Крыніца: habr.com