Высокие нагрузки

Бизнес обычно оперирует показателями посещаемости по количеству посетителей за сутки или за месяц, но с точки зрения разработки хорошей практикой измерения нагрузки является использование показателей RPS или RPM — количества запросов в секунду или в минуту. Это объясняется тем, что посещаемость большинства проектов очень неравномерная в зависимости от дня недели и времени суток — как минимум, ночью визитов сильно меньше, чем днём. А нагрузку создаёт не количество визитов, а количество просмотров — в некоторых проектах один пользователь в обычном сценарии использования приложения генерирует несколько десятков или даже сотен пакетных запросов к серверу.

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

Мы считаем, что разработанный проект должен выдерживать всплески посещаемости, превышающие плановые показатели как минимум в 5 раз. Практика показывает, что очень часто целевые показатели основаны на усреднённых данных или даже на гипотезах, а в реальности всплески посещаемости значительно превышают запланированные нагрузки.

Оптимизация CMS под высокие нагрузки часто упирается в необходимость полного кеширования данных, так как скорость обработки запросов в универсальных CMS оставляет желать лучшего, а иного инструментария в коробочных системах просто нет. При невозможности кеширования (персонализованный контент, высокая интерактивность интерфейса, частое обновление информации) — ситуация с адаптацией сайта на CMS под нагрузки становится практически неразрешимой (переписывание ядра коробочной CMS с целью оптимизации — не очень рациональное занятие, это долго и дорого). Именно поэтому в качестве платформ для нагруженных сайтов и приложений мы рекомендуем фреймворки, в частности, Ruby on Rails и Next.js.

Фреймворки лучше подходят для разработки решений, требовательных к производительности и к устойчивости к нагрузкам. Во фреймворках нет избыточного программного кода, который не используется, поэтому ядро фреймворка на порядок «легче» и производительнее ядра универсальной CMS. Логика получения и обработки данных, а также схема их хранения в случае разработки на фреймворке получается более специфичной для задач проекта, это позволяет добиться более высокой производительности. Фреймворки отлично интегрирутся не только с реляционными базами данных, но и с другими хранилищами и поисковыми движками, что позволяет использовать наиболее подходящие инструменты для решения задач приложения. Всё это делает разработку нагруженных решений на фреймворках более рациональным подходом. Мы разрабатываем высоконагруженные веб‑приложения на фреймворках Ruby on Rails и Next.js.

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

Для проектов с колебаниями нагрузки от низкой до умеренной (например, «в сезон» или на сайтах мероприятий) вполне может подойти и решение на базе виртуального выделенного сервера, который в моменты высокой нагрузки масштабируется до конфигурации близкой к уровню физического сервера. А когда высокие нагрузки эпизодические и краткосрочные (например, вебинарные площадки или трансляции), то экономически более выгодным может быть облачное решение с динамическим масштабированием под нагрузку — по сути, это тот же кластер, но состоящий не из физических, а из виртуальных выделенных серверов.