Highload: что это и как работают высоконагруженные системы

Highload простыми словами

Highload (высокая нагрузка) — состояние, когда система упирается в пределы одного сервера: процессора, памяти, диска или сети.

Признаки высоконагруженной системы:

время ответа сайта растет при увеличении числа пользователей;
регулярно возникает пиковая нагрузка, которая в разы выше средней;
один сервер или база данных стали «бутылочным горлышком» и тормозят работу систем;
простой даже в несколько минут приводит к прямым финансовым потерям;
объем данных в компании растет быстрее, чем можно добавить дисков в существующие серверы.

Основные компоненты highload-инфраструктуры

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

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

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

Тяжёлые и несрочные задачи принимает брокер сообщений, а данные хранятся в кластере базы данных и системе хранения.

За работой систем следит мониторинг, который указывает на возможное снижение производительности.

В виртуализированной среде, например на VMware vSphere, эти компоненты работают как виртуальные машины и сервисы поверх общего пула ресурсов, а гипервизор распределяет железо между ними.

Архитектура highload-систем

Любая система с высокой загруженностью упирается в три задачи:

Задача	Подход-решение
Запросов слишком много для одного узла	Распределение нагрузки и кэширование
Тяжелые задачи занимают сервер и замедляют ответы на легкие вопросы	Асинхронная обработка и очереди сообщений
Приложение растет и становится громоздким	Микросервисная архитектура

Разберем их подробнее.

Распределение нагрузки и кэширование

Идея в том, чтобы не обрабатывать один и тот же запрос дважды и не отправлять всех пользователей на один узел. Балансировщик распределяет трафик между серверами, а кэш (Redis, Memcached, CDN) хранит готовые ответы в быстрой памяти. Часто повторяющиеся данные, такие как карточки товаров или справочники, отдаются из кэша за миллисекунды и не доходят до базы данных.

Асинхронная обработка и очереди сообщений

Многие процессы не требуют, чтобы пользователь ждал результата, но если выполнять их прямо во время запроса, они занимают сервер и замедляют ответы остальным. Эту проблему решают асинхронная обработка и очереди сообщений. Отправка уведомлений, генерация отчетов и обработка файлов выносятся в очередь (RabbitMQ, Kafka). Пользователь получает быстрый ответ, а тяжёлая работа выполняется фоновыми обработчиками. Получается более гладкий процесс: если запросов больше, чем можно обработать, они ждут своей очереди, а не обрушивают сервис.

Монолитная и микросервисная архитектура

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

Однако микросервисы нужны не всегда. На практике многие команды начинают с «модульного монолита», где части приложения уже разделены логически, но по-прежнему работают вместе, а отдельные сервисы выделяют по мере роста.

Вертикальное и горизонтальное масштабирование инфраструктуры

Вертикальное масштабирование: что это

Это наращивание мощности одного узла: больше vCPU, оперативной памяти, более быстрые диски. В VMware vSphere ресурсы виртуальной машины увеличиваются за несколько минут, а при поддержке hot-add иногда без остановки.

Плюсы: можно быстро увеличить ресурсы.

Минусы: у физического сервера есть предел мощности, выше стоимость такого решения.

Горизонтальное масштабирование: что это

Здесь мощность растёт за счёт числа узлов: к работающим серверам добавляются новые, и нагрузка делится между ними. Потолка практически нет, и отказ одного узла не критичен. Но приложение должно быть к этому готово: не хранить сессии локально и уметь работать в кластере.

Плюсы: выше отказоустойчивость и стабильность.

Минусы: требует большой экспертизы и грамотной архитектуры.

Как лучше масштабироваться?

Вертикальное масштабирование чаще выбирают для баз данных и legacy-систем, потому что для них сложно разделить работу между несколькими серверами. База данных должна хранить согласованные данные: если их раскидать по нескольким узлам, придётся решать вопросы синхронизации, а это усложняет архитектуру. Legacy-системы, как правило, писались для работы на одном сервере, и переделывать их под кластер долго и дорого. Проще и быстрее добавить мощности существующему узлу.

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

Балансировка нагрузки и отказоустойчивая архитектура

Для максимальной доступности highload-инфраструктуры предусматривают балансировку и принципы отказоустойчивости.

Как работает балансировка нагрузки

Балансировщик принимает входящие запросы с учетом «веса» узлов. Он постоянно проверяет загруженность серверов и исключает из ротации тех, кто не отвечает. Балансировка работает на сетевом (L4) и прикладном (L7) уровнях, и на втором можно маршрутизировать трафик по URL, заголовкам или cookie. В VMware-средах эту роль выполняют, например, решения на базе NSX или отдельные программные балансировщики.

Резервирование и восстановление после сбоев

Отказоустойчивость строится на избыточности. Критичные компоненты дублируются, данные реплицируются, а отдельно размещаются резервные копии. В VMware отказоустойчивость помогает поддерживать vSphere HA, который перезапускает виртуальные машины на соседнем хосте при сбое, и vMotion, переносящий работающую ВМ между серверами без остановки.

Также в компании нужно отдельно предусмотреть стратегию резервирования и Disaster Recovery: определить RTO (за какое время сервис должен вернуться) и RPO (сколько данных допустимо потерять), выбрать подход, какие системы необходимо дублировать. Для действительно критичных систем используют геораспределенную архитектуру и размещают данные на разных площадках.

Подробнее про Disaster Recovery Plan можно узнать в отдельной статье.

Highload-база данных

Обычно база упирается в лимиты раньше всего. Все запросы рано или поздно сходятся к ней, а масштабировать её сложнее остальных слоёв. Далее — порядок действий для оптимизации инфраструктуры, от самого экономичного до дорогого.

Оптимизация запросов и кэширование

Когда вы только столкнулись с высокой нагрузкой на базу данных, стоит выжать максимум из того, что есть, и пройтись по списку:

Индексы. Часто достаточно добавить один недостающий.
Тяжёлые запросы. Убрать лишние и переписать самые затратные.
N+1. Найти запросы в цикле, которые незаметно множат нагрузку.
Кэш. Не отправлять в базу то, что можно отдать из памяти.

Оптимизация одного запроса нередко даёт больше эффекта, чем покупка нового сервера, и стоит на порядок дешевле.

Репликация и разделение чтения и записи

Типичная схема: одна главная нода принимает записи, несколько реплик обслуживают чтение. В большинстве систем чтений значительно больше, чем записей, поэтому основной сервер разгружается.

Правда, здесь есть ловушка: задержка репликации. Реплика может на мгновение отставать от главной ноды. Поэтому данные, критичные к актуальности, нужно читать с главной.

Шардинг

Если данные не помещаются на одном сервере или запись перестаёт справляться, их делят на части (шарды) по ключу, например по идентификатору клиента или региону. Каждый шард живёт на своём узле, и запись растёт горизонтально.

Важно учитывать, что шардинг усложняет архитектуру. Запросы между шардами и перебалансировка данных требуют продуманного ключа и дисциплины. Ошибка в выборе ключа обходится дорого, потому что исправлять её придётся на живых данных. Поэтому шардинг обычно оставляют как самую последнюю меру.

Highload-инфраструктура в облаке

Облако закрывает главный риск highload-проекта, связанный с расчетом емкости. Вы можете не бояться, что неправильно рассчитали объем закупленного оборудования — в облаке ресурсы выдаются по требованию, мощность наращивается за минуты, а оплата идет за фактическое потребление. Облако выбирают ради его преимуществ по скорости и гибкости: инфраструктура без закупки, поставки и ожидания.

В распоряжении заказчика облачной highload-инфраструктуры:

Виртуальные машины — базовая вычислительная мощность.

Управляемые балансировщики — распределение трафика между узлами.

Распределённые хранилища — благодаря им данные переживают отказ отдельного диска или узла.

Kubernetes-кластеры — оркестрация контейнеров и рост по числу экземпляров.

Готовые сервисы БД и очередей — вы не занимаетесь администрированием, а передаёте эту задачу провайдеру.

В VMware-среде всё это работает как общий пул ресурсов. DRS автоматически перераспределяет виртуальные машины между хостами в зависимости от загрузки, и один перегруженный хост не становится узким местом.

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

В OXYGEN специально для высоконагруженных систем мы готовы предоставить кластер BIGVM — с увеличенным размером виртуальных машин. Мы предлагаем конфигурации с Intel 3.0 GHz, 92 vCPU и 1,5 Тб vRAM — на практике вы получаете быстрые расчеты, уверенную работу с аналитикой и запас по производительности. А для самых требовательных задач мы развернем кластер SAP, где вы можете запустить виртуальную машину с объемом оперативной памяти до 5,8 Тб.

Серверная инфраструктура для высоконагруженного сайта

Физический слой — тот, на котором держится всё остальное. Если нужно работать быстро и без внезапных сбоев, экономить здесь не стоит, и лучше сразу учесть требования к конфигурации:

Процессор и память. С запасом, а не впритык под текущий пик.
Диски. Выбирайте быстрые NVMe: именно диск чаще всего оказывается слабым звеном.
Сеть. Важно добиться низкой задержки и осуществить резервирование каналов.
Площадка. Выбирайте дата-центр TIER III с резервированием питания и охлаждения.

Собственное оборудование даёт полный контроль, но требует закупки, обслуживания, площадки и людей. Размещение в дата-центре или аренда готовой облачной инфраструктуры снимает эти задачи: вы платите по факту, а за нижние уровни отвечает провайдер.

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

Как спроектировать highload-систему

Оценка нагрузки и поиск узких мест

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

Нагрузочное тестирование

Попробуйте сломать систему заранее — до того, как наступит наплыв пользователей в день распродажи. Технологии стресс-тестов имитируют реальный трафик и показывают, при каком количестве запросов начинается деградация систем. Протестируйте несколько сценариев: плановый рост, пиковая загруженность, отказ отдельных узлов. Результат — измеримый запас прочности и список доработок.

Мониторинг и автоматическое масштабирование

Highload-инфраструктурой невозможно управлять без постоянного наблюдения. Метрики (загрузка, задержки, ошибки), логи и алерты позволяют заметить проблему раньше пользователей. Автомасштабирование использует эти метрики: при росте нагрузки добавляются узлы, при спаде лишние убираются. Пороги и правила нужно подбирать по результатам тестов, иначе автомасштабирование сработает слишком поздно или слишком часто.

Заключение

Highload-инфраструктура редко ломается из-за одной ошибки. Чаще система упирается в слабое звено, которое никто не измерял: запрос без индекса, реплика с задержкой, автомасштабирование с неподобранным порогом.

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

Облако и виртуализация, в том числе VMware, дают гибкость ресурсов, но не избавляют от проектирования. Мощность, которую можно нарастить за минуты, всё равно придётся рассчитать, проверить тестами и взять под наблюдение.

Если вы планируете запуск или пересмотр высоконагруженной системы, расскажите нам о проекте, и инженеры OXYGEN подберут схему реализации и технологии.