Высоконагруженные системы – не просто сайт или сервис, обрабатывающий единичные запросы пользователей в течение дня. Для систем высокой нагруженности характерен одномоментный "наплыв" пользователей, которые при этом могут совершать абсолютно разные действия. Пресечь возможные проблемы в работе помогут нагрузочные тестирования - важный вид диагностики, который позволит испытать производительность системы в разных условиях использования. О том, почему важно проверять нагрузку на практике, в какой момент лучше начинать тестирование, что важно учесть до его начала и как подготовиться, мы поговорили с техническим директором компании Oprosso Максимом Наконечным.

Что подразумевается под нагрузочным тестированием?

Когда говорят о нагрузке, обычно  подразумевается, сколько запросов пользователя к нашему приложению мы сможем выдержать и адекватно отрабатывать за определенное время. Например, пользователь нажимает какую-то кнопочку у нас, и мы реагируем на это нажатие за несколько миллисекунд (мс). 

А что такое адекватный ответ на уровне ИТ-решения? Существуют ли какие-то стандарты или усредненные временные параметры? 

У всех понятие адекватного ответа свое: для кого-то ответ в 500 мс, это нормально, а кому-то нужно, чтобы отрабатывали меньше чем за 100 мс. С точки зрения наших исследований требование в основном такое: не зависать надолго, чтобы респондент не передумал их проходить, отвечать адекватно быстро. Но, повторюсь, стандарты быстрого ответа для всех разные: для интернет-магазина нормальное время ответа – 5-10 секунд, за это время формируется заказ или подгружается картинка. А вот те же 5-10 секунд на панели между вопросами уже не нормально. 

Если требования у всех разные, то как подходить к вопросу нагрузки в ходе диалога с клиентами?

Обычно мы начинаем с вопроса: а какой профиль нагрузки вы нам принесете? И под профилем тут понимается целый ряд параметров: сколько клиентов, в какое время они будут заходить, какие будут пики посещений. Например, разослали по всей стране 10 000 приглашений на опрос. В России несколько часовых поясов. Все эти 10 000 человек не будут заходить в один момент. Кто-то захочет это сделать с утра, кто-то вечером, кто-то вообще не придет. Так что для ответа на вопрос о нагрузке нужна подробная информация о профиле. 

А играет ли роль, что они будут делать?

Конечно. От этого зависит, какая часть приложения подвергается нагрузке. Сейчас очень модно делать микросервисную архитектуру, но это не просто мода, здесь есть технические причины: на одной странице сервиса может быть расположено одно приложение, а на другой – совершенно другое. И здесь снова хорошо бы знать заранее, каким будет алгоритм действий, чтобы предсказать, на какую часть приложения какая загрузка придется. Как в банджи-джампинге: там снаряжение, это такая же микросервисная архитектура, где каждая часть отвечает за свою область. И нагрузка на эти части распределяется не равномерно, а согласно тому, какую нагрузку она получит во время прыжка банджи-джампера. Профессионалы этого вида спорта очень ответственно подходят к тестированию нагрузки и проверяют снаряжение и в статическом, и в динамическом положении, с учетом веса, роста прыгуна и других физических показателей. Те участки, которые больше других подвержены, например, перетиранию, снабжаются тремя-четырьмя дополнительными страховками. Тестируется и траектория полета, ведь человек в ответственный момент может оттолкнуться вбок, вперед или вообще "упасть" спиной назад, соответственно, что бы он ни сделал, его прыжок в любом случае должен быть безопасен. Так и с запуском сайта или приложения: как бы клиент ни тестировал сервис, тот всегда должен быть в рабочем состоянии и предоставить клиенту запрашиваемую информацию.

Как быть с нагрузкой, если до конца не понятно, сколько будет данных? Сколько мощностей развернуть? 

Бывает, клиент хочет приобрести коробочное решение Oprosso. Но при этом он не может сказать сразу, сколько у него будет запросов, анкет и респондентов. Тогда мы рекомендуем начать с малого и от него уже отталкиваться дальше. 

Как происходит нагрузочное тестирование, что мы грузим и чем?

Мы берем систему, которую разрабатываем, и посылаем на нее очень много запросов. Грубо говоря, записываем последовательность из конкретных запросов и потом прокручиваем эту запись много раз с большого количества потоков одновременно. Если попытаться объяснить проще, то есть сервер, есть смоделированная ситуация, есть много-много компьютеров – тысячи, десятки тысяч – и каждый из них посылает одно и то же. Этот процесс имитирует прохождение одного и того же исследования большим количеством респондентов. Таким образом мы понимаем, на какой цифре сервис перестает адекватно отвечать. Это такой эксперимент: мы запустили тысячу, две тысячи, смотрим, какие там показатели количества запросов в секунду, как долго система отвечает, и как только время отклика начинает расти, это значит, что мы подошли к границе, когда нам не хватает удельного времени для ответа на такое количество запросов. Например, 1000 запросов в секунду мы отрабатывали за 200 мс, сделали 2000 запросов в секунду – это уже 400 мс. Все, где-то между 1000 и 2000 у нас начался троттлинг. То есть обработка анкет задерживается, чтобы обработать другие анкеты, это повышает среднее время отклика. 

Допустим, у нас есть все данные: что, когда, где будет происходить. Почему расчет ненадежен?

Сложно заранее рассчитать нагрузку, поскольку необходимые для расчета данные носят теоретический или эмпирический характер и на практике могут не совпасть с ожидаемыми значениями. Начну с того, что у всех разное железо. Мы знаем, какое железо в нашем офисе, и если измеряем нагрузку у себя, то учитываем это. А у клиента оно может быть более новым или наоборот, более старым. Надо учитывать разную скорость работы каждого потока на центральный процессор, разную частоту оперативной памяти. На больших объемах это сильно влияет на скорость отклика, поэтому на одном оборудовании мы получим 200 мс, а на втором – 500 мс, хотя данные те же самые, и конфигурация по ресурсам та же самая. Просто иной технический ход у процессора, иное поколение оперативной памяти, другое железо – все это дает разный результат. 

Опять же, повторюсь, профиль нагрузки – это тоже важный параметр. Если говорить об Oprosso, то нужно знать, например, сколько клиент привлечет респондентов на сервис, придут ли эти люди в одно время или в разное, какие будут пики прихода. Даже анкета, которую они проходят, имеет значение: другое исследование, другое количество вопросов, другое количество логики. А между тем, логика тоже кое-что весит, занимает объем памяти, пропускную способность сети. И количество анкет, которое можно передать с логикой переходов и отображений и без нее, будет разное. Поэтому вопрос с заблаговременным расчетом сложный. Конечно, можно попытаться учесть все параметры, собрать всю нужную информацию, профили, все это посчитать, но это долгий процесс. Быстрее все-таки измерить вживую.

Недавний пример с одной мебельной компанией, которой надо было распродать свои склады, показал, что они что-то не рассчитали, и сайт не выдержал количества запросов. В какой момент должна рассчитываться нагрузка на сайт и что делать, когда уже в моменте понимаешь, что запросов будет много? 

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

Возможность масштабироваться вертикально существует по умолчанию, здесь можно просто добавлять ресурсы своему серверу: больше ядер, больше памяти, больше сети, пропускной способности... А горизонтальное масштабирование, это когда ты можешь добавить дополнительный сервер. Два, три, пять таких серверов. Как правило, это дешевле, чем вертикальное масштабирование, потому что крутое железо стоит дороже, чем среднее железо, и два-три средних сервера, работающие в параллели, будут дешевле, чем один крутой сервер. О масштабировании всегда нужно думать, хотя не всегда понятно, как в итоге обернется.

А есть спасительное устройство, которое поможет всему не лечь, если что-то перенапряглось? 

Да. Можно настроить так, чтобы сервер при превышении определенного количества запросов в секунду начал эти запросы возвращать. Да, мы получим отказ в обслуживании клиента, так это будет выглядеть, но наши системы при этом не лягут. Мы не потеряем никаких данных, ничего страшного не произойдет. Если у нас 95% нагрузки, то мы не станем пытаться вытянуть больше. Это может выглядеть, как будто у нас ничего не работает, однако это не так, мы просто защищаемся. 

Говоря о нагрузке системы, нельзя не упомянуть высоконагруженные системы. Входит ли в их число Oprosso? 

Мы проектируем и разрабатываем функциональность систем Oprosso, заранее учитывая ее высокую загрузку. Сейчас есть серия вопросов, которую нужно решить, чтобы начать приводить большую нагрузку. Недавно один из клиентов делал рассылку, разослал полтора миллиона ссылок. Они не все пришли, но в итоге привели нам несколько сотен тысяч анкет за неделю. Для недели это не очень много. И по этой рассылке было видно, что нагрузка до 30 запросов в секунду. От 5 до 30. Это относительно немного.

Мы ожидаем, что сервис будет справляться с нагрузкой 1000 rps (requests per second). Это любое действие на платформе: ответ на вопрос, заход в конструктор, просто логин в систему – это все как минимум один запрос. Конечно, если сравнивать с Google, это вообще ничто. Сопоставимо, может, с некоторыми интернет-магазинами техники. 

Еще добавлю, что в нашей системе статистики присутствуют достаточно сложные запросы. Они очень тяжелые, и в будущем мы планируем переделать всю систему: подключить быстрое хранилище данных, создать новый тип базы данных, но не классический реляционный, а колоночный, например. 

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