Тонкие грани High Load
High Load (хайлоад, hiload, highload) - очень популярный термин в кругах IT. Но так сложилось, что у него нет четкого определения. Все понимают, что это связано с высокими нагрузками, но метрики для определения этих нагрузок у каждого свои.
Показатели и порог наступления High Load
Мне очень нравится определение с сайта компании “Жить в небе”: Высоконагруженными (highload) интернет-проектами считаются сайты, приложения и системы, способные обслужить на порядок больше пользовательских запросов, чем обслужили бы аналогичные проекты с точно такими же ресурсными конфигурациями серверов и стандартными (дефолтными) настройками. Иными словами, высокие нагрузки для любой системы начинаются там, где серверы начинают работать медленно, страницы перестают загружаться, соединения обрываются, а приложения начинают тормозить или утилизируют 100% серверных ресурсов.
Соответственно, High Load для проекта начинается тогда, когда начинаются проблемы с производительностью.
Пример - сайт интернет-магазина на Битрикс. В стандартной конфигурации без оптимизаций на виртуальном сервере 4CPU 8GB RAM он может обслужить сотни пользователей в минуту. Но только стоит увеличить число пользователей (например, объявить скидки), сайт начнет испытывать проблемы - страницы начнут медленно отдаваться, могут появиться различные ошибки, могут быть проблемы с работой админпанели.
Здесь для этого проекта уже начался High Load.
Метрики для диагностики настоящей высокой нагрузки
Но можно же оптимизировать проект, применить кэширование, увеличить мощности сервера, улучшить код? - спросите вы. Да, конечно, можно. И нужно, если вы уже сталкиваетесь с артефактами, описанными выше. Тогда система станет оптимизирована для бОльших нагрузок. И текущая планируемая нагрузка уже не станет для нее High Load. Но это не убережет от возможных проблем с замедлениями при еще большем числе посетителей.
И тут уже другие методы борьбы с высокими нагрузками вступают в бой - разделение проекта на микросервисы, внедрение очередей, горизонтальное масштабирование ресурсов.
Однако и это при каких-то высоких для данного проекта нагрузках может не уберечь от проблем с производительностью. Такую борьбу можно продолжать очень долго. Все зависит от бизнес-задач, возможностей проекта и выделяемого бюджета. А бюджет на некоторых проектах только на сервера может уходить за сотни тысяч рублей в месяц. И не каждый бизнес готов такие суммы выделять на оптимизацию проектов для растущих нагрузок.
Таким образом, High Load для проектов с разной архитектурой наступает по-разному. И количественные показатели наступления High Load тоже разные.
Пример из жизни: работаем над интернет-магазином, все устойчиво, по всем параметрам системы хороший запас. И тут отдел маркетинга решил объявить невиданные скидки, разослали клиентам пуши в мобильном приложении - и наша система упала от неожиданного наплыва людей. High Load случился там, где не ждали. И здесь очень важно, чтобы бизнес свои желания согласовывал с техническими возможностями. Ведь в данном случае подготовиться можно было вполне к пиковой нагрузке, если знать о ней заранее.
Разница между High Load и интенсивной нагрузкой
Следует разделять понятия “High Load” и “интенсивная нагрузка”. Например, мы проектируем сервис хранения файлов на базе облачного S3-хранилища. Заведомо известно, что S3-хранилище будет очень широко и интенсивно использоваться в системе по сравнению с остальными ее узлами. Но эта нагрузка будет заранее известна, учтена при проектировании системы, и не должна оказывать негативного влияния на работу всей системы в целом. Таким образом интенсивная нагрузка - это не показатель High Load. Она должна быть учтена при разработке системы.
High Load или ошибки разработки
Разберем отношение плохо спроектированных систем и High Load. Я считаю, если система выполняет заявленные на момент ее разработки параметры по нагрузке, она хорошо и на достаточном уровне спроектирована. При превышении допустимой нагрузки и появляющихся при этом проблемах уже стартует High Load. И систему нужно дорабатывать.
Случай из жизни. Заказчик обращается с просьбой о помощи - некоторые страницы сайта очень долго открываются, притом по Яндекс метрике он не видит каких-то неожиданных всплесков посещений. Начали разбираться - нашли на этих страницах множественные запросы в цикле. Налицо ошибка разработки. Поправив запросы, все стало работать вполне быстро. Такое поведение системы не стоит называть High Load. В данном случае система не выполняла заданные для нее параметры из-за некорректно написанного кода.
Количественные показатели High Load
По количественным показателям High Load все довольно просто. Смотрим на метрики сервера, и, если процессор и оперативная память загружены более чем на 80 процентов, то это можно считать High Load для данной системы. И нужно начинать предпринимать какие-то действия по оптимизации системы.
Например, High Load может наступить для блога на виртуальном хостинге при 50 запросах в минуту, для интернет-магазина на облачном сервисе - при 500 запросах в минуту, для государственного сервиса на выделенных серверах - при нескольких десятках тысяч запросов в минуту. Для каждого проекта свои показатели.
Бывают более тривиальные случаи, когда и все параметры системы “по железу” в норме, но все работает медленно. Это может быть связан с ограничениями ПО. Например, установлено слишком низкое число воркеров nginx или малое число коннектов в базе данных.
Конечно, и ошибки разработки никуда не уходят. Те же неоптимальные запросы к базе данных могут давать большие последствия. И устранение программных просчетов может занять много времени и средств. Но, снова повторюсь, если система соответствует всем нормам, указанным в техническом задании, то даже с неоптимальными запросами она может считаться вполне нормальной.
Можно сделать вывод что High Load - это ненормальное состояние системы. Если нам нужно большое количество пользователей, если предполагаются изначально высокие нагрузки по каким-либо показателям, при этом система спроектирована с учетом заданных показателей и реализована по ТЗ, в этой системе нет High Load, насколько бы сложной эта система не была и какие бы мощные нагрузки она не держала.
В пример можно привести всеми любимые и знакомые соцсети. Для них большое число посетителей, запросов к базам данных, к хранилищам файлов, к каким-то смежным системам - это нормальное состояние. Да, можно сказать, что соцсети работают в условиях High Load - все это поймут, там действительно такие метрики, до которых далеко обычным проектам. Но эти системы на такие нагрузки рассчитаны и для них состояние High Load наступает при выходе за расчетные параметры и следующих из-за этого проблемах.
В какой момент компании переходить к архитектуре High Load
Как определить, работает-ли ваша система в режиме High Load? Снова возвратимся к “железным” метрикам по использованию процессоров и оперативной памяти. Если один из этих параметров используется больше, чем на 80% - вы уже в режиме High Load.
На практике можно определить, когда ваша система придет в режим High Load. Достаточно для нее провести нагрузочное тестирование. Для обычных веб-ресурсов нагрузочное тестирование делается такими утилитами, как Yandex Tank, Apache AB или другие. Эти сервисы генерируют разную нагрузку и смотрят на реакцию системы. Если система стала выдавать ошибки, увеличилось время ответа или возросли до критичных параметры загрузки сервера - мы попали в зону High Load. И эта нагрузка становится нашей критической нагрузкой.
Подытожим сказанное. High Load - это критическое состояние системы, связанное с ее некорректной работой вследствие нагрузки, превышающей заданные при проектировании параметры.
Опубликовано 27.02.2025
