Что такое высоконагруженные системы

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

Что такое высоконагруженные проекты

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

Нагрузку описывают несколькими метриками:

• Количество запросов в секунду (RPS): сколько обращений сервер принимает и обрабатывает.
• Одновременные пользователи и соединения. Особенно важны для чатов, игр и трансляций, где соединение держится долго.
• Объем данных: сколько хранится и сколько добавляется за сутки.
• Время ответа (задержка): как быстро пользователь получает результат. Смотрят не на среднее значение, а на самые медленные запросы, потому что именно их замечают люди.
• Доступность: какую долю времени сервис работает без сбоев.

Высоконагруженная система держит эти показатели на заданном уровне при росте нагрузки. Трафик вырос вдвое, а время ответа не изменилось - значит, архитектура справляется. Если каждая рекламная кампания кладет сервер, проект уже стал высоконагруженным, даже если до миллиона пользователей ему далеко.

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

Как масштабируют высоконагруженные системы

Есть два пути роста. Вертикальное масштабирование - поставить более мощный сервер: больше процессоров, памяти, быстрее диски. Это просто, но у железа есть потолок, а один сервер остается единой точкой отказа. Горизонтальное масштабирование - добавить серверов и распределить нагрузку между ними. Потолка почти нет, и система может обрабатывать большее количество запросов по мере добавления машин. Условие одно: приложение должно уметь работать на нескольких серверах сразу. Большинство приемов highload-архитектуры нужны именно для этого.

Балансировка нагрузки

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

Кэш и CDN

Самый быстрый запрос к базе - тот, которого не было. Кэш (промежуточное хранилище готовых ответов в оперативной памяти, чаще всего Redis) отдает частые данные без обращения к базе данных: карточки товаров, настройки, результаты популярных поисков. CDN (сеть серверов доставки контента) раздает картинки, видео и скрипты с узлов рядом с пользователем. Сложность кэша в актуальности: нужно продумать, когда сбрасывать устаревшие данные, иначе покупатель увидит старую цену.

Очереди

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

База данных

База данных чаще всего становится узким местом. Приемы по нарастающей сложности:

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

Хранение данных, которые нельзя потерять, вроде платежей и заказов, строят на надежности и транзакциях. Для логов и событий, которых набирается значительный объем, важнее скорость записи.

Микросервисы и отказоустойчивость

Монолит (одно приложение со всей логикой) проще разрабатывать на старте. Когда разные части нагружены по-разному, его делят на сервисы: каталог, корзина, платежи, уведомления. Каждый масштабируют отдельно, и отказ отдельного компонента не валит всю систему. Упал сервис рекомендаций - магазин продолжает принимать заказы. Цена у такого подхода есть: распределенная система требует мониторинга, трассировки запросов, автоматического развертывания (обычно в Kubernetes) и дисциплины в договоренностях между сервисами.

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

Высоконагруженные системы: примеры

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

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

Общее у всех одно: рост нагрузки не бывает плавным. Архитектуру проектируют под пики, а не под средний день.

Высоконагруженные системы: пример архитектуры

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

• Прием координат - легкий сервис за балансировщиком. Он только проверяет точку и кладет ее в очередь.
• Обработчики из очереди пишут координаты в хранилище временных рядов и обновляют последнюю позицию машины в кэше.
• Карта для клиентов читает последнюю позицию из кэша, а не из базы.
• Прогноз времени прибытия считает отдельный сервис, его масштабируют по числу активных рейсов.
• Заказы, договоры и счета живут в реляционной базе с репликами.
• Уведомления клиентам уходят через очередь.

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

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

Когда проекту нужна архитектура под высокую нагрузку

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

1. Сделать монолит с чистой структурой и вынести сессии и файлы из памяти сервера, чтобы потом можно было добавить серверы.
2. Настроить мониторинг и искать реальные узкие места по метрикам, а не по ощущениям.
3. Провести нагрузочное тестирование (имитацию большого числа пользователей) перед запуском рекламы или сезона.
4. Выносить в отдельные сервисы то, что нагружено сильнее остального или должно работать при отказе соседей.

Если продукт уже упирается в производительность, нужен аудит. Он покажет, где теряется время и какие изменения дадут больший эффект при меньших затратах. Проекты, где высокие требования к нагрузке понятны заранее, мы сразу проектируем под горизонтальный рост. Как устроена разработка высоконагруженных систем в студии, описано на странице услуги, а прикинуть объем работ можно в калькуляторе.