Новая эра: нагрузочное тестирование UI-микросервисов

Привет, Хабр! Я Эдуард, в команде РСХБ.Цифра занимаюсь организацией проведения нагрузочного тестирования. В нашей команде инженеры НТ занимаются проверкой производительности как монолитных, так и микросервисных решений. Одно из больших направлений — это мобильное приложение «Свои финансы» от РСХБ. В этой статье расскажу о том, как мы проводим нагрузочное тестирование UI-микросервисов и поделюсь ценными выводами на тему.

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

Но без frontend бэки не начнут работать. Так как backend микросервисы начинают действовать после активизации фронтов, именно фронтенд выступает интерфейсом диалога пользователя с системой. Фронтенд запускается первым, предоставляя графический интерфейс, формы ввода данных, кнопки и другие элементы управления, необходимые для начала процесса взаимодействия с серверной частью.

Именно фронтенд передаёт дальнейшее управление бэку на стороне сервера, инициируя обработку данных и выполнение операций. 

Эта последовательность обеспечивает коммуникации между клиентом и сервером, позволяя пользователям получать доступ ко всем возможностям приложения через понятный интерфейс. Таким образом, frontend играет важную роль в активации и координации работы backend-микросервисов, создавая целостную экосистему обмена информацией пользователя с приложением.

А что покрывает классическое нагрузочное тестирование?

Классическое НТ — это тестирование бэкенда. Анализируется скорость отклика системы, расход ресурсов (процессор, память, диски, сеть), способность быстро реагировать на запросы. Одним словом — измеряется производительность. Задача – обеспечить комфортное использование даже при больших нагрузках.

Боль: инцидент на проде и беспомощность классических подходов

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

С одной стороны, может показаться, что проблема не в коде, а в инфраструктуре, исследование производительности frontend-микросервисов поможет с этим разобраться.

🔥 CRITICAL: Тротлинг процессора пода payments‑ui‑d5 прикладного контейнера больше 35% on SYS Web checks PROD.
Ошибка троттлинга на ПРОДе.

По всей вероятности, проще простого пойти к фронт-разработчику и запросить у него API. А также запросить у службы поддержки ПРОДа статистику по интенсивности работы данного МС.

Но выяснилось, что у фронтовых микросервисов нашего приложения нет API. Да и поддержка не собирает необходимую нам статистику. Кроме того, на нагрузочном стенде нет даже фронтовой части, только бэк. Словом, сложность НТ микрофронта состоит в том, что его невозможно вызвать ничем, что применяется в случае НТ бэка, так как у фронта нет «ручек» (endpoints). Отсюда возникает необходимость в построении иных подходов тестирования производительности. 

Как работает микрофронтенд (блок-схема)

① При обращении к микрофронту, микрофронт отдает статику в виде файла-манифеста

../payments/asset-manifest.json
Манифест — это специальный файл (обычно manifest.json, assets.json или подобный), содержащий список статических ресурсов (CSS, JavaScript файлы, изображения и другие активы), необходимых для работы UI-микросервиса. Скачивание этих активов часто бывает критичным фактором в скорости реакции клиента и восприятии производительности.

② Манифест содержит ссылки на статику.

③ Клиент (обычно это мобильное устройство) забирает эти файлы статики. 

④ Рендеринг (отрисовка страницы) происходит полностью на стороне клиента.

⑤ Далее передаётся управление в бэкенд часть.

Инструменты. Почему k6 browser не подошел, а JMeter — идеальный вариант

Мы начали с k6 browser. Именно потому, что k6 имеет дополнительное расширение для запуска реальных экземпляров браузера. Открытие большого числа (несколько тысяч) экземпляров браузера требует значительного объёма ресурсов нагрузочной станции. 

Однако нагрузочным тестированием целесообразно покрывать только серверную часть — скачивание файлов статики. Работу приложения на стороне клиента тестировать не имеет смысла из-за многочисленного разнообразия моделей смартфонов, браузеров и их версий. Мы резонно посчитали, что тестирование производительности клиентской части выходит за рамки нашей задачи, так как не покрывает серверную часть и никак не влияет на полученную ошибку троттлинга процессора. Да и проверять скорость работы множества вариантов — это работа команды автотестирования, поэтому отдали на откуп их команде ☺.

Но от k6 мы все же отказались. В нашей команде НТ наибольшую популярность получил JMeter и подавляющее большинство проектов тестируются именно этим инструментом. Соответственно все инженеры обладают навыками JMeter. В угоду универсализма решено было отдать предпочтение JMeter с расчётом на то, чтобы любой мог без труда переключиться на задачу тестирования фронта.

JMeter вполне пригоден для эффективного тестирования производительности UI микросервисов в разрезе скачивания статического контента. Используя парсинг манифеста и параллельную загрузку ресурсов, можно создавать точные и производительные тесты, позволяющие оценить реальный отклик наших микросервисов.

Методика: как мы тестировали

Получить манифест

При обращении к микрофронту, он отдает статику в виде файла-манифеста

../asset-manifest.json

{  "files": {    "main.css": "/files/web/payments/static/css/main.56d.css",    "main.js": "/files/web/payments/static/js/main.fc.js",    "static/css/785.36.chunk.css": "/files/web/payments/static/css/785.36.chunk.css",    "static/js/785.8a.chunk.js": "/files/web/payments/static/js/785.8a.chunk.js",    "static/js/715.8a.chunk.js": "/files/web/payments/static/js/715.8a.chunk.js",    "static/js/133.10.chunk.js": "/files/web/payments/static/js/133.10.chunk.js",    "static/js/194.b8.chunk.js": "/files/web/payments/static/js/194.b8.chunk.js",    "static/js/426.6c.chunk.js": "/files/web/payments/static/js/426.6c.chunk.js",    "static/js/776.69.chunk.js": "/files/web/payments/static/js/776.69e.chunk.js",    "static/js/992.1c.chunk.js": "/files/web/payments/static/js/992.1c.chunk.js",    "static/js/174.39.chunk.js": "/files/web/payments/static/js/174.39.chunk.js",    "static/js/294.88.chunk.js": "/files/web/payments/static/js/294.88.chunk.js",    "static/css/914.20.chunk.css": "/files/web/payments/static/css/914.20.chunk.css",    "static/js/914.47.chunk.js": "/files/web/payments/static/js/914.47.chunk.js",    "static/content/4.png": "/files/web/payments/static/content/4.86..png",    "static/content/3.png": "/files/web/payments/static/content/3.a2..png",    "static/content/2.png": "/files/web/payments/static/content/2.84..png",    "static/content/3.webp": "/files/web/payments/static/content/3.2ca..webp",    "static/content/onest-semiBold.woff": "/files/web/payments/static/content/onest-semiBold.1d..woff",    "static/content/onest-medium.woff": "/files/web/payments/static/content/onest-medium.00..woff",    "static/content/receipt_base.png": "/files/web/payments/static/content/receipt_base.dd..png",    "static/content/2.webp": "/files/web/payments/static/content/2.d8..webp",    "static/content/onest-regular.woff": "/files/web/payments/static/content/onest-reg..woff",    "static/content/gosusl.png": "/files/web/payments/static/content/gosusl.f9..png",    "static/content/1.png": "/files/web/payments/static/content/1.79..png",    "static/content/onest-bold.woff2": "/files/web/payments/static/content/onest-bold.fe..woff2",    "static/content/onest-medium.woff2": "/files/web/payments/static/content/onest-medium.e5..woff2",    "static/content/1.webp": "/files/web/payments/static/content/1.1f..webp",    "static/content/more-about.png": "/files/web/payments/static/content/more-about.05..png",    "favicon.ico": "/files/web/payments/favicon.ab.ico",    "index.html": "/files/web/payments/index.html",    "cache-service-worker.js": "/files/web/payments/cache-sw.js",    "manifest.json": "/files/web/payments/manifest.f1740835.json",    "715.8a.chunk.js.map": "/files/web/payments/static/js/715.8a.chunk.js.map",    "133.10.chunk.js.map": "/files/web/payments/static/js/133.10.chunk.js.map",    "194.b8.chunk.js.map": "/files/web/payments/static/js/194.b8.chunk.js.map",    "426.6c.chunk.js.map": "/files/web/payments/static/js/426.6c.chunk.js.map",    "992.1c.chunk.js.map": "/files/web/payments/static/js/992.1c.chunk.js.map",    },  "entrypoints": [    "static/css/main.56abc.css",    "static/js/main.fccba.js"  ]}

Распарсить

Для нашего случая парсинг манифеста мы организовали через регулярное выражение (regular expression extractor):

/\/files\/web\/payments\/((?:(?!\.map»)[^»])*)»/gi

Регулярное выражение ищет строки, которые:

1. Начинаются с /files/web/payments/

2. Содержат любой путь к файлу после базового пути

3. Заканчиваются кавычкой

4. Исключают файлы с расширением .map

Примеры совпадений:

✅ /files/web/payments/static/css/main.56d.css»
✅ /files/web/payments/static/js/main.fc.js»
❌ /files/web/payments/static/js/715.8a.chunk.js.map» (исключается)

Используется для извлечения путей к JavaScript/CSS файлам веб-модулей, исключая source map файлы (.map), которые обычно не нужны в продакшене.

Загрузить ассеты

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

Результаты

Набор самих тестов, как и при классическом НТ: «Поиск Максимальной производительности» и длительный «Тест Стабильности».

Напомню, что нашей первейшей задачей было воспроизвести троттлинг процессора. Получить троттлинг, как выяснилось, можно легко. Однако на поиск реального «Максимума» может уйти приличное количество времени. Подход такой:

1. запускаем тест со ступенчатым профилем нагрузки;

2. определяем время начала троттлинга;

3. отмечаем, на какой ступени начался троттлинг;

4. резонно предполагаем, что это и есть искомая ступень для «Теста Стабильности» (в реальности потребуется тест «Подтверждения Найденного Максимума», потому что троттлинг снова может возникнуть, об этом ниже);

5. запускаем «Тест Стабильности» на найденной ступени.

На скриншоте виден 100% троттлинг (время на графике серверное UTC+0)

В данном тесте троттлинг был получен на пятой ступени поиска максимума (на графике Total Throughput указано время генератора нагрузки UTC+3)

Казалось бы, всё сделано «по книжке» и можно считать, что «Максимум» найден, и уже можно запускать «Стабильность». Но советую не торопиться, так как на ступени, где не было троттлинга при поиске «Максимума», мы через какой-то промежуток времени можем опять увидеть повышенный троттлинг, но на «тесте Стабильности».

Всё дело в том, что отслеживание троттлинга доступно лишь по графику. А он, бывает, серьёзно запаздывает. Поскольку процесс троттлинга — это механизм защиты процессора от перегрева путем пропуска части машинных тактов. И график по сути отражает момент, когда процессор уже нагрелся. В нашей работе мы это замечаем понижением производительности. Поэтому при «тесте Стабильности» опять появляется троттлинг ЦПУ, так как сам троттлинг начался раньше, но на графике мы увидели его с опозданием. В этом случае нужно искать более точный максимум путём увеличения длительности ступеней, либо уменьшая их высоту. Другими словами, перед запуском «теста Стабильности» наверняка потребуется проведение теста «Подтверждения найденного Максимума». И таких запусков может потребоваться несколько. Следует определить, на какой ступени троттлинг составляет менее 10%.

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

Редкий троттлинг допускается, как, например, на нашем примере:

Основной параметр производительности — это естественно интенсивность запросов, которая чаще всего измеряется в rps (request per second). Скачивание каждого отдельного файла равнозначно 1 rps. Поскольку один клиент скачивает набор всех файлов из манифеста, то для удобства подсчета следует указать суммирующую транзакцию «All», которая объединяет загрузку всех необходимых файлов одним пользователем за одну сессию. В таком случае мы сразу увидим количество одновременно работающих клиентов в секунду. А разбивка по файлам покажет, какие файлы загружались дольше остальных.

Главные выводы

Что же мы получили, проведя тестирование UI Микросервисов?

Технический вывод. Во-первых, на некоторых микрофронтах было обнаружено избыточное количество ассетов, в основном картинок, которые в дальнейшем подверглись оптимизации. Мы доказали, что инцидент может быть вызван не только недостатком ресурсов (которые просто добавили), а неоптимальной работой самого микросервиса.

Методологический вывод. Во-вторых, команды UI разработки стали обращаться за повторным, читай, регрессионным тестированием своих микросервисов. Мы разработали и опробовали методику нагрузочного тестирования серверной части UI-микросервиса, которая раньше была «черным ящиком». Теперь мы можем измерять её производительность.

Процессный вывод. Ну и в-третьих, в процессе разработки UI МС прочно поселилось НТ. Изначально мы уперлись в организационную проблему: команды были не готовы потреблять эти новые данные. В дальнейшем нужно встраивать НТ UI в процесс CI/CD и иметь базовые метрики для последующего сравнения (например, время отклика не должно деградировать более, чем на 5% после нового коммита). Это не сложно внедрить в рамках нашего НТ, поскольку не требуется дополнительных настроек стенда, не используется БД, нет интеграций и зависимостей от других сервисов.

Современный фронтенд, особенно в виде микросервисов, — это не просто «верстка». Его серверная часть, отдающая статику, является полноценным объектом для нагрузочного тестирования. Игнорирование этого факта приводит к невоспроизводимым инцидентам на проде и хаотичным попыткам «добавить памяти». Методика такого тестирования строится на понимании механизма работы микрофронтенда (парсинг манифеста и последующая загрузка ассетов) и может быть реализована на привычных инструментах, таких как JMeter. Главный вызов — не технический, а организационный: заставить команды включить эту практику в регулярный процесс разработки.