Кстати, если вам понравится этот рассказ, приходите на Тестовую среду в нашем питерском офисе 30 ноября (зарегистрироваться), – там я расскажу больше о, игровых механиках в тестировании и с удовольствием вживую с вами поговорю. Итак.
В 2005-2006 годах часть не поисковой инфраструктуры Яндекса стала испытывать нагрузки растущего как на дрожжах Рунета. Появилась необходимость тестировать производительность смежных с поиском сервисов, в первую очередь — баннерную крутилку. Тимур Хайруллин, на тот момент руководивший нагрузочным тестированием, озадачился поиском подходящего инструмента.
Но существующие в то время открытые решения были либо очень примитивны (ab/siege), либо недостаточно производительны (jmeter). Из коммерческих утилит выделялся HP Load Runner, но дороговизна лицензий и завязка на проприетарный софт нас не обрадовала. Поэтому Тимур вместе с разработчиком высокопроизводительного веб-сервера phantom Женей Мамчицем придумали хитрый трюк: они научили сервер работать в режиме клиента. Так получился модуль phantom-benchmark. Сам код фантома теперь открыт и его можно скачать отсюда, а рассказ про фантом можно посмотреть видео с презентации здесь.
Тогда Phantom был очень прост, умел измерять только максимальную производительность сервера, а мы могли лишь ограничивать количество потоков. Но уже в то время наша разработка была на голову производительней аналогов. Поэтому за нагрузочным тестированием к нам стали обращаться все чаще и все больше сервисов. С 2006 до 2009 года команда нагрузочного тестирования разрослась до десяти человек. К нам очень быстро прикрепилось название «танкисты», которые заряжают «ленты» с «патронами» и “стреляют” из «танков» по «мишеням». Танковая тематика до сих пор с нами. Для экономии ресурсов мы создали специальный «полигон» или «курятник», где держали виртуальные машины для нагрузочного тестирования. Платформа виртуализации в то время была на openvz, а сейчас мы полностью перешли на lxc из-за лучшей поддержки новых ядер и дистрибутивов ubuntu server. Респект сообществу lxc!
Параллельно с приходящими сервисами и ростом популярности нагрузочного тестирования, а точнее, с ростом самосознания команд сервисов, приходило понимание ограничения возможностей инструмента.
При содействии разработчиков и под руководством «танкиста» Андрея baabaka Кузьмичева мы стали развивать phantom в настоящий фреймворк для поддержки нагрузочного тестирования — Лунапарк. Ранее из-за плохой организации отчетов результаты складировались бессистемно — в Wiki, JIRA, почту и пр. Это было очень неудобно, мы вложили много труда в это больное место и постепенно у нас появился настоящий веб-интерфейс с дашбордом и графиками, где все тесты были провязаны с тикетами в JIRA, все отчеты наконец получили единообразие и понятный дизайн. Веб-интерфейс научился отображать процентили, тайминги, средние времена, коды ответа, объем получаемых и передаваемых данных и еще около 30 различных графиков и таблиц. Помимо этого Лунапарк был провязан с почтой, джаббером и другими сервисами. Изменения не обошли стороной и сам генератор нагрузки Phantom — он научился делать очень многое из того, чего не умел раньше. Например, подавать запросы по расписанию — линейно, ступенчато, снижать нагрузку и даже(!) подавать нулевую и дробную нагрузку. В консольный вывод добавился агрегационный вывод с процентилями, мониторинг объема данных, ошибок, ответов. Так выглядел консольный вывод образца 2009 года.
Постепенно пришло понимание, что нужно не только постоянно тестировать некоторые сервисы, но и сопровождать их из года в год от релиза к релизу, а также уметь сравнивать тесты между собой. Так появились важные для работы нагрузочного тестировщика страницы Лунапарка: сравнение тестов и регрессия. Так выглядели их первые версии.
Тестировщик, разработчик или менеджер в любой момент мог узнать, как развивается продукт с точки зрения производительности. Сейчас мы работаем над улучшением и выносом этих страниц во главу фреймворка. На текущем этапе развития нам наиболее важны не единичные тесты, а тренды производительности.
В 2011 году произошло важное событие — мы стали первой командой в Яндексе, запустившей настоящую геймификацию рабочего процесса, о которой у меня будет отдельный доклад на Тестовой среде. Такое даже сейчас редко встречается и в самых продвинутых IT-компаниях. На странице Лунапарка мы разместили «Зал Cлавы» и очень гордимся этой частью фреймворка. За конкретный тест можно сказать нагрузочному тестировщику настоящее дружеское «Спасибо!». Каждый тестер получает различные бэйджи за то или иное событие, становится «командиром танка» (а-ля мэром в Форскверике) и даже “звание”, которое выдается за число проведенных тестов. Среди рутинной работы любая ачивка или спасибка на вес золота. Это очень здорово мотивирует.
2011 год мы считаем переломным в нашем нагрузочном тестировании. Команду разработки возглавил Андрей undera Похилько. Сообщество тестеров знает его как разработчика замечательных плагинов для Jmeter. Андрей принес свежие идеи и подходы, которые сейчас очень помогают в работе.
Во-первых, мы поняли, что развивать инструмент в старой парадигме «некогда объяснять, кодируй» не получается, и перешли на модульную парадигму разработки, где большой монолит разбивается на компоненты и развивается отдельным частями, не создавая угрозу всему проекту. Во-вторых, так как заказы на нагрузочное тестирование стали поступать от сервисов, которым http-трафик был не интересен, нам понадобился инструмент, которым можно было бы тестировать SMTP/POP3/FTP/DNS и прочие протоколы. Писать phantom-протоколеры на каждый такой сервис нам показалось дорого, и мы решили встроить в Лунапарк обычный Jmeter. Тем самым небольшими усилиями мы научились поддерживать в нагрузочном тестировании несколько десятков новых протоколов. Встраивание помогло нам оставить стандартный вебинтерфейс без перехода на Jmeter GUI. Помимо поддержки Jmeter наш танк со временем научился поддерживать SSL, IPv6, UDP, elliptics, “мультитесты” в несколько адресов с одного генератора, подачу нагрузки в несколько миллионов rps с распределенных генераторов и многое другое.
В определенный момент заказов на нагрузочное тестирование повалило так много, что нам стало очевидно: мы не сможем удваивать штат каждый год без снятия рутинных и регрессионных тестов с нагрузочного тестировщика. Для решения этой задачи мы проанализировали всю нашу текущую каждодневную работу, и оказалось, что к сервисам нужно подходить с разной степенью глубины тестирования. Мы придумали следующую схему работы:
- Для тестирования прототипов или экспериментальных сборок мы сделали отчуждаемую версию генератора нагрузки и, чтобы не отвлекать нагрузочников от более подготовленных проектов, стали рекомендовать ее разработчикам или системным администраторам для отладочных нагрузочных тестов своего прототипа. Получаемые результаты совместимы с фреймворком Лунапарк и не бывает ситуаций «я потестировал свой прототип с помощью ab, он выдавал 1000 rps, а в Лунапарке только 500!».
- Для тестирования разовых или событийных сервисов, где нагрузка может внезапно вырастать в несколько раз (Спорт, ЕГЭ, Новости, Промопроекты), мы держим быстроподнимаемые виртуальные машины, где раскатываются готовые пакетированные сервисы. Тесты проходят в ручном режиме со снятием удаленной телеметрии с объекта нагрузки. Иногда процесс координируется в специальных чат-комнатах, где может сидеть до 5-10 человек: “танкистов”, разработчиков, менеджеров. По нашей внутренней статистике 50% ручных тестов(!) вылавливают различные проблемы с производительностью — от неправильно построенных индексов, “спайков” на файловых операциях, недостаточного количества воркеров и тд. Окончательные результаты документируются в JIRA.
Пример онлайн страницы проводимого теста.
Для анализа по желанию можно включать дополнительные графики, например, времена ответа.
HTTP и сетевые ошибки:
Времена на разных стадиях взаимодействия и потоки:
Для регрессионных тестов, или для тестов, приемка результатов которых проводится разработчиками, либо администраторами, мы сделали так называемые автоматические и полуавтоматические тесты. Про это нужно рассказать отдельно.
В конце 2011 мы поняли, что по сути все операции теста могут делаться скриптами, вызовами, или, проще говоря, каким-то исполняющим механизмом. Идеологически ближе всего к такой деятельности стоят CI фреймворки, которые умеют собирать проекты, запускать набор тестов, уведомлять о событиях и выносить вердикт о прохождении. Мы посмотрели на варианты этих инструментов и обнаружили, что открытых фреймворков не так много. Jenkins показался нам наиболее удобным для расширения функциональности с помощью плагинов и, потестировав его рядом с Лунапарком, внедрили его в тестирование. С помощью внешних вызовов к специальному API и встроенного планировщика мы смогли переложить всю рутинную работу тестеровщика на Jenkins. Разработчики получили заветную кнопку «Протестировать мой сервис сейчас!», нагрузочники получили десятки, а то и сотни тестов в день без их участия, менеджеры и системные администраторы получили регрессионные графики производительности от билда к билду. На данный момент автоматические тесты составляют около 70% от всего потока, и этот показатель постоянно растет. Это экономит нам десятки человек в штате и позволяет сконцентрировать интеллект тестера на ручных и исследовательских тестах.
Внимательный читатель заметит, что постепенно Лунапарк стал представлять собой раздельную структуру: отчуждаемый лоад-генератор, бэкенд для статистики и телеметрии, а также отдельный автоматизационный фреймворк. Окинув это взглядом и зная, что с YAC'10, где baabaka рассказывал про Лунапарк, тестеры всего Рунета при каждом удобном случае троллят нас открытием Лунапарка наружу, мы решили выложить часть Лунапарка в opensource. Летом 2012 года на одном из Яндекс.Субботников в Москве мы представили лоад-генератор сообществу тестировщиков. Сейчас Яндекс.Танк с легкими графиками, со встроенной поддержкой jmeter и ab развивается только на внешнем гитхабе, мы отвечаем на вопросы пользователей в клубике и принимаем внешние пулреквесты от разработчиков.
Мы знаем, что сообщество нагрузочных тестировщиков в Рунете невелико, доступные знания очень скудны и поверхностны, но тем не менее, интерес к теме производительности только нарастает. Поэтому будем рады поделиться накопленным опытом и знаниями в этой области и обещаем периодически публиковать статьи на тему нагрузок, инструментария и методов тестирования.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers.
Комментариев нет:
Отправить комментарий