Под капотом Wiremock: разгадка проблемы производительности Тестирование
Инженер по автоматизации тестирования. Автоматизировал тестирование платежных систем American Express, UnionPay, JCB, создавал процессы автотестирования в британской инвестиционной компании, транспортной процессинговой платформе и в биотех-стартапе. Сейчас работает в Яндекс Финтехе, автоматизирует тестирование кредитных сервисов Яндекс Банка. Контрибьютит в опенсорсные библиотеки, очень любит копаться в технологиях, с которыми работает, узнавать новые и читать профессиональную литературу.
Тезисы
Представьте ситуацию: единое тестовое окружение, в котором работает более 300 микросервисов, нагрузка свыше 300 RPS на сервис, и этим окружением пользуются все — от разработчиков до аналитиков.
Задача: нам нужны моки для негативных сценариев, ускорения текущих автотестов и стабилизации сервисов, но нельзя просто взять и замокать сервисы, ведь остальным нужно ходить в реальные сервисы.
Мы выбрали Wiremock, который может быть не только мок-сервером, но и прокси. Однако оказалось все не так просто — Wiremock начал падать даже при нагрузке в 100 RPS, Kubernetes перезапускал поды, а один из багов Kubernetes и вовсе сломал мастер-ноду.
Всё это мало напоминало успех, но в результате — после множества экспериментов и расследований — мне удалось разобраться в причинах. После исправлений всех проблем и аппрува от создателя Wiremock — производительность Wiremock выросла в десятки раз, он стал выдерживать нагрузку более 1000 RPS. Чтобы узнать, как мы с этим справились, с какими проблемами столкнулись и как мы их решали, приходите на мой доклад. Будет интересно и поучительно!
