О микросервисах
Большинство IT-компаний сейчас используют микросервисную архитектуру (по некоторым данным, до 80-85% и более).
При микросервисном подходе каждый программный компонент выделяется в отдельный «независимый сервис». Поскольку каждый компонент-микросервис «не зависит» от других микросервисов, добавление новых функциональных возможностей или масштабирование этих сервисов проще по сравнению с традиционными монолитными моделями.
Хотя микросервисы имеют очевидные преимущества при развертывании и масштабировании приложений, существует ряд серьезных ограничений; это касается и подходов к нагрузочному тестированию микросервисов.
Что собой представляет нагрузочное тестирование микросервисов? В первую очередь, это изолированное тестирование, с целью проверить масштабируемость, надежность и отзывчивость/респонсивность.
Полноценно функционирующее программное приложение обычно состоит из множества микросервисов. Нагрузочного тестирования изолированных микросервисов недостаточно для верификации, что приложение будет работать в соответствии с ожидаемыми стандартами, поэтому необходима целостная стратегия нагрузочного тестирования микросервисов (далее МС).
Как планировать и выполнять нагрузочное тестирование микросервисов в стандартном проекте — рассмотрим в данной статье.
Характерные свойства микросервисов
Прежде чем рассмотреть best practices, напомним ключевые характеристики и преимущества микросервисов:
- Одновременная разработка — благодаря распределенной разработке отдельных частей приложения (то есть микросервисов) можно создавать много микросервисов одновременно, что существенно ускоряет время разработки и позволяет командам быстрее получать рабочую версию приложения.
- Более четко описываемая архитектура — если «разукрупнить» крупные приложения на небольшие микросервисы, то многим участникам команд легче понимать их предназначение МС и работать над ними. Преимущество такого «модульного» подхода в том, что он делает имплементацию приложения проще и эффективнее.
- Повышение отказоустойчивости — если приложение построено на микросервисной архитектуре, сбой в работе одного микросервиса вряд ли приведет к отказу всего приложения. Поскольку каждый микросервис работает изолированно, приложение может оставаться работоспособным, даже если отказали один или несколько связанных микросервисов.
- Масштабируемость — если в процессе работы приложения на проде отдельные микросервисы становятся проблемными и/или требуют дополнительных ресурсов, эти микросервисы можно масштабировать и настраивать соответствующим образом. Такие узкие места сложнее устранять в монолитных приложениях.
Уровни тестирования
Чтобы воспользоваться описанными выше преимуществами микросервисов, необходимо внедрить надежную стратегию тестирования. По традиционной модели пирамиды могут быть выделены три типа тестов микросервисов:
- Юнит-тесты; относящиеся к этой категории тесты связаны с тестированием микросервиса в изоляции от других микросервисов. Эти тесты выполняются на ранних этапах жизненного цикла разработки и, как правило, выполняются разработчиками автоматически в CI/CD-пайплайне.
- Интеграционные — этот этап охватывает проверку того, что микросервис успешно взаимодействует с другими связанными с ним микросервисами. Для этого можно использовать утилизацию сервисов (то есть их имитацию, подробнее об этом ниже в статье) или, если есть развернутые и работающие в тестовом окружении реальные версии связанных сервисов, они вызываются в процессе.
- E2E — эти тесты охватывают весь путь пользователя по приложению, то есть задействуя все микросервисы «на пути». Сквозные тесты обычно выполняются через пользовательский интерфейс или через вызов API по пользовательским путям.
Подходы и стратегии
Нужно учитывать следующее.
Обеспечить тщательный мониторинг
Первое, о чем нужно позаботиться — обеспечить качественный мониторинг тестового окружения, в котором размещен тестируемый микросервис. Инструменты нагрузочного тестирования способны предоставлять достаточно подробную информацию о тайминге запросов/ответов к транзакциям тестируемого микросервиса; но не исключено, что понадобится более подробная информация о том как приложение работает и сколько ресурсов потребляет.
Для этого необходимо подобрать и настроить инструмент мониторинга производительности приложений (APM). Измеряется производительность микросервиса, настроив APM-инструмент на мониторинг показателей использования ресурсов, таких как процессор, память и дисковый ввод-вывод, пропуская нагрузку через микросервис. Кроме того, может понадобиться отслеживать другие показатели, например скорость чтения/записи в очередях сообщений и работа кэша памяти.
Измерение производительности микросервисов может выходить за рамки обычного анализа времени запросов/ответов на HTTP-вызовы к сервису. Важна полная видимость (прослеживаемость) использования ресурсов в окружении, в котором работают приложение и микросервисы.
Фокус на самых важных МС
Несмотря на необходимость проведения нагрузочного тестирования всех микросервисов приложения в его целостности, лучше избегать ситуаций, когда длительное выполнение «необязательных» тестов замедляет процесс разработки. Для этого лучше определить микросервисы с наибольшими рисками, и начинать их нагрузочное тестирование на ранних этапах цикла разработки. Тестирование микросервисов с меньшими рисками можно оставить «на потом».
Например, если создаем приложение электронной коммерции, один из микросервисов отвечает за процесс оформления заказа и покупку. Если этот микросервис нерабочий, то это помешает клиентам успешно завершить оформление заказа и приведет к потере дохода компании. Поэтому, возможно, стоит потратить время на нагрузочное тестирование критически важных микросервисов на ранних этапах разработки, даже если это повлечет более длительное выполнение тестов или время сборки в CI/CD.
Виртуализация МС
Любой микросервис, как правило, зависит от нескольких других микросервисов. На ранних этапах разработки, когда несколько микросервисов создаются параллельно, один или несколько из этих связанных микросервисов, скорее всего, окажутся недоступными или неполными.
Можно преодолеть это препятствие, воспользовавшись виртуализацией сервисов. Это можно назвать имитацией (мокингом) вызовов другого микросервиса. Виртуализация микросервисов позволяет сосредоточить усилия на тестировании микросервиса, интересующего в данный момент, не полагаясь на доступность других зависимых МС в тестовом окружении.
Окружения
Если зависеть от одного тестового окружения, можно создать себе «проблемное место» при нагрузочном тестировании. Во-первых, выполнение нагрузочных тестов может занять много времени. Не стоит замедлять или откладывать разработку только потому, что нам предстоит выполнить несколько нагрузочных тестов, а окружение для их выполнения существует лишь одно.
Во-вторых, нередко производительность приложения меняется при его развертывании в разных географических локациях. Например, приложение, развернутое в дата-центре в США, может значительно отличаться по времени отклика на запрос транзакции по сравнению с тем же приложением, развернутым в дата-центре в Азии. В идеале нужно убедиться, что геолокация тестового окружения соответствует региону ожидаемого развертывания.
Также необходимо убедиться, что трафик, который направляется в тестируемое приложение, примерно соответствует ожидаемым направлениям трафика пользователей. Например, если создается приложение «глобального» типа, то оно, скорее всего, будет получать трафик со всего мира. Чтобы точнее смоделировать нагрузку, следует использовать распределенное окружение, с инжекторами нагрузочного тестирования, расположенными в различных геолокациях.
SLA
Нередко нагрузочное тестирование микросервисов и приложений, на них построенных, начинается без каких-либо соглашений об уровне обслуживания (SLA). Без этих соглашений QA-команда будет вынуждена полагаться на догадки, приемлемо ли время отклика транзакций в данном случае.
Очень легко избежать этой проблемы, если собрать вместе разработчиков микросервисов и продакт-менеджмент для согласования целевых уровней производительности. Обычно заключается SLA с указанием ожидаемого времени отклика транзакций и частоты ошибок.
SLA не обязательно должны быть очень жесткими и точными. Они просто дают всем, кто участвует в разработке и тестировании приложения и соответствующих МС, представление о приемлемом уровне производительности.
О метриках
Разработка небольших микросервисов как правило идет быстрыми темпами, и за короткий период времени создается несколько различных сборок и версий микросервиса. Важно отслеживать уровень производительности МС в процессе разработки, чтобы определить, не привели ли последние изменения кода к снижению производительности.
Для этого лучше начинать нагрузочное тестирование критически важных микросервисов на ранней стадии, и интегрировать нагрузочное тестирование в CI/CD-пайплайн. Также может понадобиться быстро оценивать и сравнивать производительность различных сборок и версий тестируемого микросервиса.
Группирование МС
Хотя микросервисы by design создаются работающими независимо, функциональность всего приложения обеспечивается совместной работой многих МС. Поэтому может быть полезным одновременное нагрузочное тестирование сгруппированных микросервисов.
Этого можно достичь путем параллельного выполнения реалистичных нагрузочных тестов нескольких микросервисов. Современные инструменты поддерживают одновременное выполнение различных сценариев нагрузочного тестирования в рамках одного тестового набора. Во время выполнения теста можно проанализировать производительность микросервисов с помощью инструментов мониторинга, описанных ниже.
Инструменты
Качественное нагрузочное тестирование МС зависит от правильных инструментов. Понадобятся инструменты, способные эффективно моделировать реальные сценарии нагрузки. Предположим, что тестируется приложение, которое будет получать трафик из нескольких географических регионов, тогда инструмент должен поддерживать распределенную генерацию нагрузки. Он должен легко интегрироваться в CI/CD-пайплайн.
Один из таких инструментов — Gatling (здесь вводный гайд). Он может генерировать огромные объемы HTTP-трафика с минимальными ресурсами инжектора нагрузки.
Помимо инструментов-генераторов нагрузки, также нужен инструмент APM-мониторинга микросервисов, предоставляющий подробную информацию о времени отклика транзакций в тестируемых микросервисах. APM-мониторинг необходим для анализа метрик ресурсов аппаратного обеспечения, на котором работает приложение, чтобы выявить любые проблемы и узкие места.
Несколько популярных инструментов мониторинга:
