Автор: Джулиан Харти (Julian Harty)
Оригинал статьи
Перевод: Ольга Алифанова

Введение

Нам нужно было протестировать производительность мультирегиональных кластеров Kafka. Мы в итоге применяли pepper-box для большинства задач. Вначале нам нужно было понять, а затем использовать и улучшить возможности pepper-box. Ниже – обзор наших действий, связанных с работой с pepper-box. Мы опубликовали наш код и связанные с ним материалы на GitHub, и детали можно увидеть тут: https://github.com/commercetest/pepper-box

Pepper-box и jmeter

Для использования pepper-box нам вначале нужно было разобраться в основах jmeter. Использование jmeter для отличных от web протоколов, то есть Kafka, потребовало значительного времени и усилий – и кучу времени мы потратили на изучение различных аспектов компиляции кода, настройки jmeter и запуска тестов.

К счастью, помимо pepper-box существует и kafkameter, и мы многое узнали из различных статей, а также из исходного кода. Вот ключевые статьи:

• http://codyaray.com/2014/07/custom-jmeter-samplers-and-config-elements
• https://dzone.com/articles/pepper-box-kafka-load-generator
• https://www.blazemeter.com/blog/apache-kafka-how-to-load-test-with-jmeter

Статья в blazemeter даже содержала пример скрипта потребителя, написанного на языке Groovy. Мы в итоге значительно расширили этот скрипт – он доступен в нашей ветке pepper-box (не было смысла создавать отдельный проект только для скрипта): https://github.com/commercetest/pepper-box/blob/master/src/groovyscripts/kafka-consumer-timestamp.groovy

Как всегда, вариантов, чего почитать и с чем поэкспериментировать для возможности систематически создавать надежные jmeter-плагины, было множество. Минусом была необходимость убедить и машину, и maven, что нам правда нужна Java 8.

Расширение pepper-box для поддержки протоколов безопасности

Требования бизнеса обязывали данные быть безопасными во всей системе. Kafka поддерживает ряд механизмов безопасности. SASL позволяет узлам авторизоваться в копиях Kafka. Безопасность соединений обеспечиваются SSL, однако безопасность предоставляется последователем – TLS.

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

Мы столкнулись с рядом проблем, связанным с окружениями, стремлением поддерживать здоровье кластеров Kafka и осуществлением репликации без существенных задержек. Возможно, позже я расскажу об этом подробнее. Мы также поняли, что использование java-сэмплера pepper-box (как это называется в терминологии jmeter) задействует серьезные ресурсы CPU, и нам нужна возможность параллельного запуска генераторов и потребителей нагрузки.

Обособленный pepper-box

В конце концов мы обнаружили, что комбинация jmeter и сэмплера pepper-box достигла своих пределов и потеряла способность генерировать нужную нагрузку, чтобы мы могли протестировать необходимые аспекты производительности и отклика. К счастью, создатели pepper-box предоставили обособленную утилиту генерации нагрузки, которая могла удерживать значительно большую нагрузку. Нам нужно было сбалансировать дополнительную производительность с возможностями jmeter и множеством плагинов, разработанных для jmeter за время его жизни. Нам пришлось самостоятельно справляться с синхронизацией генераторов нагрузки на множестве машин.

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

Разработка потребителя pepper-box

jmeter-groovy-consumer еще не достиг своего максимума, но смысла в применении разноперых подходов (отдельный поставщик на Java при jmeter + Groovy) было мало. К тому же это усложняло и так сложную ситуацию по мере нарастания количества тестов. Поэтому мы решили создать потребителя на основе отдельного поставщика. В итоге мы не внедряли ограничение скорости, так как оно на самом деле не требовалось нашим тестам, но в остальном это вполне дополняющие основную задачу инструменты. Поставщик отправляет сообщение в заранее известном формате, потребитель его обрабатывает, рассчитывает задержку и выводит результат в CSV-файл для каждого топика. Поставщик опрашивает на предмет сообщений со значениями по умолчанию (к примеру, 500 сообщений на запрос). Это легко можно адаптировать, изменяя и улучшая код.

Применение опросов приводит к ряду ключевых последствий:

1. Используется меньше CPU. Потенциально ряд потребителей можно прогонять на той же машине для обработки множества поставщиков (генераторов), которые запускаются на нескольких машинах.

2. Точность временных расчетов ограничена интервалом опросов.

Вкратце об обособленных инструментах pepper-box

И поставщик, и потребитель функциональны, но не сильно изящны, и не особенно прощают ошибки, недостаточные или ошибочные параметры. Было бы здорово улучшить их удобство использования.

Обсудить в форуме