Алексей Лавренюк (Яндекс) - Методика нагрузочного тестирования

Доклад с конференции Moscow Python Conf 2016 (http://conf.python.ru)
Видео: https://conf.python.ru/metodika-nagruzochnogo-testirovaniya/

Я расскажу об этапах тестирования производительности типичного сервиса, о том, какие виды тестов нужно проводить, как интерпретировать результаты измерений и об инструментах, которые мы применяем для генерации нагрузки и анализа результатов тестов. Слушатели доклада научатся применять opensource и бесплатные инструменты, созданные в стенах Яндекса, для тестирования производительности своих сервисов.

Transcript

2. Нагрузочное тестирование
 в Яндексе Алексей Лавренюк
3. Погода на Марсе Load Testing at Yandex
4. Кадр из фильма "Марсианин"
5. Кадр из фильма "Марсианин"
6. Кадр из фильма "Марсианин" Предположим, объем шлюза составляет два кубических метра. Надутый скафандр, вероятно, занимает половину. Требуется минута, чтобы добавить 0.2 атм к 1 кубическому метру. Это 285 грамм воздуха… (тут еще два абзаца подобных вычислений) …когда я выйду из шлюза, этот скафандр продержится всего четыре минуты.
7. Back-of-the-envelope вычисления Задача (от Google): сервис картинок, нужно спроектировать страницу с результатами поиска 〉 есть хранилище фотографий, по 256 КБ каждая 〉 страница результатов содержит 30 превьюшек по 24 КБ 〉 у нас есть серверы с 24 ГБ RAM, 8-ю ядрами, 2x2TB hdd, 1Gbps ethernet С чего начать? 7
8. Back-of-the-envelope вычисления 8 Задача (от Google): сервис картинок, нужно спроектировать страницу с результатами поиска 〉 есть хранилище фотографий, по 256 КБ каждая 〉 страница результатов содержит 30 превьюшек по 24 КБ 〉 у нас есть серверы с 24 ГБ RAM, 8-ю ядрами, 2x2TB hdd, 1Gbps ethernet С чего начать: оценить нагрузку! (хотим 100 000 RPS)
9. Подход "в лоб" Делаем все на одной машинке. 30 картинок / 2 диска = 15 чтений (256 KB/1 MB) * (время чтения 1 MB с диска) ms + (время поиска на диске) ms = ? ms чтение одной картинки 15 чтений * ? ms = ? ms время генерации страницы 9
10. "Latency numbers every programmer should know" L1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns 14x L1 cache Mutex lock/unlock 25 ns Main memory reference 100 ns 20x L2 cache, 200x L1 cache Compress 1K bytes with Zippy 3,000 ns Send 1K bytes over 1 Gbps network 10,000 ns 0.01 ms Read 4K randomly from SSD* 150,000 ns 0.15 ms Read 1 MB sequentially from memory 250,000 ns 0.25 ms Round trip within same datacenter 500,000 ns 0.5 ms Read 1 MB sequentially from SSD* 1,000,000 ns 1 ms 4X memory Disk seek 10,000,000 ns 10 ms 20x datacenter roundtrip Read 1 MB sequentially from disk 20,000,000 ns 20 ms 80x memory, 20X SS Send packet CA->Netherlands->CA 150,000,000 ns 150 ms By Jeff Dean: http://research.google.com/people/jeff/ Originally by Peter Norvig: http://norvig.com/21-days.html#answers 10
11. Подход "в лоб" Делаем все на одной машинке. 30 картинок / 2 диска = 15 чтений (256 KB/1 MB) * 30 ms + 10 ms seek = 17.5 ms чтение одной картинки 15 чтений * 17.5 ms = 362 ms время генерации страницы Долго. 11
12. Параллельность Фронтенды читают с нескольких бэкэндов. (30 * 24 KB * 10 ms) / 1 MB = около 7 ms на чтение 30 превьюшек по сети 17.5 ms + 0.5 ms (rtt внутри сети) + 7 ms = около 25 мс на генерацию страницы Ускорили сервис более чем в 10 раз, не написав ни одной строки кода! 12
13. Теперь можно помечтать Сколько бэкэндов нужно, чтобы держать 100 000 показов страниц с результатами? 100 000 * 30 = 3 000 000 превьюшек нужно в секунду (1000 ms / 17.5 ms) * 2 диска = около 120 генерится одним сервером 3 000 000 / 120 = 25 000 бэкэндов нужно 13
14. Но мы же взяли цифры с потолка!
15. Подтверждаем нагрузочными тестами Проверяем гипотезы: 〉 времена ответов и максимальную производительность компонентов 〉 масштабируемость 〉 сложность алгоритмов Уточняем модель (чем раньше — тем дешевле ошибки) 15
16. Проверяем как можно раньше 〉 Бенчмарки: синтетическая нагрузка на минимально функционирующем коде. (timeit, pytest-benchmark) 〉 Ранние тесты новых реализаций на имеющихся данных. 16
17. (чтобы мерить семь раз, нужен удобный инструмент) Семь раз отмерь, один раз отрежь
18. На поле танки Load Testing at Yandex
19. Yandex.Tank: 10 лет истории Better software is produced by those forced to operate it* phantom — очень быстрый вебсервер phantom-benchmark плагин для фантома, предназначенный для тестирования. Тоже очень быстрый Yandex.Tank построен вокруг phantom- benchmark. Сейчас появилось много нового * из анонса доклада Theo Schlossnagle's "Operational Software Design" 19
20. Yandex.Tank сегодня Yandex.Tank — проект с открытыми исходниками Основной язык — Python Генератор нагрузки по умолчанию
 phantom (C++) Поддержка JMeter Пушки на Go и Python 20
21. Внутренняя архитектура танка Yandex.Tank — это метаинструмент Танк предоставляет общий фреймворк для разных генераторов нагрузки Генератору остается только отправить запросы и аккуратно замерить время их выполнения Танк состоит из модулей 21 By Dave Hakkens [CC BY-SA 3.0], via Wikimedia Commons
22. Модули танка В модулях содержится вся функциональность 〉Поддержка генераторов 〉Сбор и анализ данных 〉Мониторинг 〉Автостопы 〉Отправка результатов тестов 22
23. Типы тестов Load Testing at Yandex
24. Первый тест Конфигурация в .ini-файлах Предусмотренны хорошие дефолтные значения Их можно переопределять на разных уровнях довольно просто использовать Танк в автоматизированных системах 24
25. Пример конфигурации, load.ini Заголовок секции для каждого плагина 25 [phantom]
26. Выбираем мишень IPv4, IPv6 или доменное имя 26 [phantom] address = my.service.com
27. Указываем запросы Патроны в одном из возможных форматов 27 [phantom] address = my.service.com uris = / /mypage.html /clck/page?data=hello headers = [Host: example.org] [Accept-Encoding: gzip,deflate]
28. Задаем расписание Для начала — попроще лента генерируется заранее 28 [phantom] address = my.service.com uris = / /mypage.html /clck/page?data=hello headers = [Host: example.org] [Accept-Encoding: gzip,deflate] rps_schedule = const(1, 40s)
29. А как же мониторинг? 29 [monitoring] config_contents=<Monitoring> <Host address="my_tank" /> <Host address="my_backend"> <Custom measure="call" label="db size"> stat -c%s /usr/mysql/data </Custom> </Host> <Host address="my_frontend" /> </Monitoring>
30. Подключаем Overload Сервис от Яндекса (public beta): overload.yandex.net залогиньтесь с помощью GitHub или Yandex и скачайте токен 30 [tank] plugin_overload=yandextank.plugins.Overload [overload] token_file = ~/token.txt
31. Запускаем тест Сохраняем конфиг как load.ini и стреляем 31 yandex-tank
32. Или используем Docker 32 docker run —-net host —v $(pwd):/var/loadtest -v $HOME/.ssh:/root/.ssh -it direvius/yandex-tank
33. Результаты тестов Итоговые цифры за весь тест — этого недостаточно. Нужно наблюдать систему в динамике. Нужны графики. Графики времен ответа не сильно лучше. Каждую секунду может прилетать несколько тысяч ответов. Много шума. Графики средних времен за каждую секунду? Они не дают представления о характере распределения. 33
34. overload.yandex.net/1759
35. График распределения времен 35 число потоков
 (расписание) RPS распределение времен
 (каждую секунду)
36. Квантильный график 36 расписание
 (ожидаемое RPS) квантили Времена ответов
37. Два разных теста на максимальную производительность
38. Открытые и закрытые системы 38 Закрытая система Открытая система В закрытых системах есть обратная связь, которая не дает "добить" сервис. Пользователи ждут ответа, если сервис перегружен В открытых системах обратной связи нет. Интернет — открытая система
39. Кривые масштабируемости 39
40. Universal Scalability Law 40 sigma — contention, непараллельные части kappa — coherency delay, межпроцессное взаимодействие
41. Neil Gunther www.perfdynamics.com/ Manifesto/USLscalability.html
42. Плохой параллелизм vs. плохое IPC 42 В десять раз улучшили параллелизм В два раза увеличили затраты на коммуникацию выигрываем в начале, но ухудшаем масштабируемость
43. Ищем максимальную производительность Закрытая модель, постепенно растим число пользователей, каждый пользователь шлет запросы один за другим. overload.yandex.net/1763 43 yandex-tank -c ./load.ini -o "phantom.instances_schedule=line(1, 8, 4m)" -o "phantom.rps_schedule=" -o "phantom.loop=100000"
44. Ищем пик производительности 44 пик производительности деградация! линейный
 рост график распределения времен ответа
45. Ищем точку разладки Открытая система, строгое расписание, эмуляция открытой системы с помощью большого числа пользователей overload.yandex.net/1764 45 yandex-tank -c ./load.ini -o "phantom.rps_schedule=line(1, 600, 5m)" -o "phantom.instances=10000"
46. Ищем точку разладки 46 квантили времен ответа началась
 разладка RPS разладки
47. Смотрим в мониторинг Во что "уперлись"? Полностью ли утилизировали процессор? Соответствует ли картина нашим ожиданиям? (например, линеен ли рост загруженности CPU) 47
48. Замеряем времена ответов Открытая система, постоянная нагрузка. Уровень нагрузки из SLA или на основании предыдущих тестов не забываем прогревать систему 48 yandex-tank -c ./load.ini -o "phantom.rps_schedule=line(1, 300, 30s) const(300, 5m)" -o "phantom.instances=10000"
49. Обращаем внимание на аномалии 49 периодические пики на квантильном графике
50. Причины пиков "Тяжелый" запрос в патронах. Частота пиков зависит от уровня нагрузки Периодический процесс на сервере. Cron job или синхронизация кэша. Garbage collector Кто-то еще приходит на сервер и что-то скачивает 50
51. Ищем причины в мониторинге 51 Сервис периодически скачивает что-то по сети: потребление памяти сеть
52. Ищем утечки ресурсов Открытая система, постоянная нагрузка, стреляем подольше, смотрим в мониторинги уровень нагрузки на 80-90% от максимально возможного 52 yandex-tank -c ./load.ini -o "phantom.rps_schedule=line(1, 700, 30s) const(700, 1h)" -o "phantom.instances=10000"
53. Методология тестирования 〉 Смоук-тест. Убедиться, что все работает и мы собираем все необходимые метрики 〉 На максимальную производительность. Закрытая модель 〉 На разладку. Открытая модель, жесткое расписание 〉 Тайминги. Открытая модель, постоянный уровень (SLA) 〉 Утечки. Нагрузку повыше, стреляем подольше 〉 Любой тест, который позволит больше узнать о сервисе 〉 Автоматизация и регрессионные тесты 53
54. BFG 9000 Load Testing at Yandex
55. BFG: генератор нагрузки BFG стреляет кодом на Python До 10 000 RPS Можно делать нагрузочные тесты из функциональных сценариев Можно вообще все =) 55 BFG9000, оружие из игры Doom (id Software)
56. BFG Стенд на YaC 2014 〉«Ручное» нагрузочное тестирование 〉MIDI → ØMQ → BFG (Tank) → сервис В реальной жизни: тесты Thrift и LDAP клиента, XML RPC, развесистые сценарные тесты, тесты мобильных приложений с Appium. 56
57. Переключаем пушку Выключаем phantom, включаем Bfg 57 [tank] plugin_phantom= plugin_generator=yandextank.plugins.Bfg
58. Настраиваем пушку Какие пакеты поставить перед стрельбой. Пакет со сценарием, например. 58 [bfg] pip=https://api.github.com/repos/example/ult/tarball/master
59. Настраиваем пушку Адрес, патроны, расписание 59 [bfg] pip=https://api.github.com/repos/example/ult/tarball/master address=example.org ammofile=ammo.jsonline rps_schedule=line(1, 10, 30s)
60. Настраиваем пушку Тип пушки, число процессов. 60 [bfg] pip=https://api.github.com/repos/example/ult/tarball/master address=example.org ammofile=ammo.jsonline rps_schedule=line(1, 10, 30s) gun_type=ultimate instances=5
61. Настраиваем пушку Путь к модулю со сценариями и его название. 61 [ultimate_gun] module_path=. module_name=ult
62. Пример сценария 62 def case1(self, missile): # используем контекст measure, чтобы замерять время. # поле gun проинициализировано в __init__() # Результаты собираются автоматически: with self.gun.measure("case1"): log.info("Shoot case 1: %s", missile) # в одном сценарии может быть несколько шагов: with self.gun.measure("case1_step2") as sample: log.info("Shoot case 1, step 2: %s", missile) # можно самим проставить коды ответов: sample["proto_code"] = 500
63. Пишите письма! И не только Load Testing at Yandex
64. О чем мы сегодня поговорили 〉Оценка, проектирование, эксперимент 〉Яндекс.Танк и Overload 〉Методика нагрузочного тестирования 〉Стрельбы Python-скриптами 64
65. Ссылки Нагрузочный чат: gitter.im/yandex/yandex-tank Yandex.Tank: github.com/yandex/yandex-tank Overload: overload.yandex.net phantom: github.com/mamchits/phantom pandora: github.com/yandex/pandora Read the docs at ReadTheDocs: yandextank.readthedocs.org 65
66. Алексей Лавренюк инженер по тестированию Контакты @direvius, #yandextank direvius@yandex-team.ru
67. Albert Einstein* Once we accept our limits, we go beyond them. * некоторые утверждают, что Эйнштейн этого не говорил, но фраза все равно классная