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

Контекст

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

Моей первоначальной целью был поиск способа генерации и потребления нагрузки. Эта нагрузка затем стала бы фоном для экспериментов с устойчивостью, чтобы посмотреть, как справятся системы и репликация данных с суровыми условиями. Под «суровыми» я имею в виду различные уровни враждебности – от плохой связи до многокомпонентных условий ошибок, когда в ходе обновления выключались «неправильные» ноды, а система пыталась вызвать бэклог транзакций. Я пришел к концепции шкалы Бофорта для условий окружения, о которой напишу отдельно.

Инструменты тестирования устойчивости

Мои поиски быстро привели меня к jepsen, детищу Кайла Кинсбури. У него есть ряд прекрасных видео: https://www.youtube.com/watch?v=NsI51Mo6r3o and https://www.youtube.com/watch?v=tpbNTEYE9NQ, а также инструменты с открытым исходным кодом и различные статьи о тестировании различных технологий, включая Zookeeper и Kafka. Джей Крепс описывает свой взгляд на проведенное Кайлом тестирование тут, результаты работы Кайла очень помогли улучшить Kafka.

Пока все идет неплохо…

Однако, начав изучать практические аспекты применения Jepsen для тестирования более новых версий Kafka, я столкнулся с рядом значительных трудностей. Я не мог найти оригинальные скрипты, а те, которые я нашел на GitHub, были на Clojure, незнакомом для меня языке, и предназначались для более старой версии Kafka (0.10.2.0). Более того, они полагались на Docker. Docker крайне мощный и быстрый инструмент, но клиент не хотел доверять запуск тестов окружениям Docker (к тому же нашему окружению требовалось как минимум 20 копий для теста самой ограниченной конфигурации).

Следующим проектом был https://github.com/mbsimonovic/jepsen-python – этот язык знал и я, и коллеги. Но мы вновь столкнулись с препятствием – там тоже использовался Docker. Однако потенциально мы смогли бы тестировать кластеры, если бы заставили одну из зависимостей поддерживать docker swarm. Это проект Blockade. Я спросил, что нужно для поддержки docker swarm – много чего, согласно члену команды.

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

Инструменты тестирования производительности

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

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

1. kafkameter https://github.com/BrightTag/kafkameter

2. pepper-box: https://github.com/GSLabDev/pepper-box

3. kafka tools: https://github.com/apache/kafka

4. sangrenel: https://github.com/jamiealquiza/sangrenel

5. ducktape: https://github.com/confluentinc/ducktape

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

Я детально описал работу с pepper-box в отдельной статье.

На что, к сожалению, не хватило времени

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

В плане улучшения что pepper-box, что инструментов анализа еще есть, куда стремиться. Некоторые улучшения указаны в соответствующих репозиториях GitHub.

• https://github.com/commercetest/pepper-box/issues
• https://github.com/commercetest/pepperbox-analysis/issues

Что я бы исследовал далее

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

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