Высоконагруженные системы: как проектируют архитектуру под рост
«Высоконагруженная система» — не про конкретное число пользователей, а про то, выдерживает ли архитектура рост без деградации отклика и падений. Разбираем базовые принципы, на которых строится такая архитектура, и когда о них стоит думать заранее, а когда — это преждевременная сложность.
Разработать систему на заказ с запасом под нагрузку — не то же самое, что заложить избыточную сложность там, где она пока не нужна.
Вертикальное и горизонтальное масштабирование
Есть два способа справиться с растущей нагрузкой:
- Вертикальное масштабирование — сделать один сервер мощнее (больше процессора, памяти). Просто, но имеет физический потолок — сколько бы ни было денег, бесконечно мощный сервер не купить, и в какой-то момент рост упирается в этот предел.
- Горизонтальное масштабирование — добавить больше серверов, которые работают параллельно и делят нагрузку между собой. Даёт практически неограниченный запас роста, но требует, чтобы приложение изначально было спроектировано для работы в нескольких экземплярах одновременно.
Ключевое архитектурное решение, которое определяет, возможно ли горизонтальное масштабирование позже — где хранится состояние. Если данные пользовательской сессии хранятся только в памяти одного конкретного сервера, добавить второй сервер параллельно не получится без переделки этой части системы.
Кеширование и очереди сообщений
- Кеширование — хранение часто запрашиваемых данных в быстром промежуточном хранилище, чтобы не обращаться к основной базе данных каждый раз заново. Снижает нагрузку на базу и ускоряет ответ, но требует продуманной логики обновления кеша, чтобы не показывать пользователю устаревшие данные.
- Очереди сообщений — вместо мгновенной синхронной обработки каждого запроса, задача ставится в очередь и обрабатывается по мере готовности ресурсов. Это сглаживает резкие всплески нагрузки и не даёт системе упасть под пиковым потоком запросов, ценой небольшой задержки в получении результата.
Когда проектировать под нагрузку заранее, а когда — нет
Избыточно сложная архитектура на старте — это тоже проблема, а не только недостаточная. Проектировать сразу под миллион пользователей, когда их пока сто, замедляет разработку и увеличивает стоимость там, где в этом ещё нет смысла. Разумный баланс — не закладывать заранее ненужную сложность, но и не принимать архитектурных решений, которые сделают будущее масштабирование невозможным без полной переделки: например, хранить состояние так, чтобы позже можно было запустить несколько экземпляров приложения, даже если сейчас работает только один.
Как выбрать подрядчика
Разработчика для такой задачи стоит выбирать по конкретным признакам, а не по общему впечатлению от презентации:
- Спрашивает про реалистичный сценарий роста, а не сразу проектирует максимально сложную архитектуру по умолчанию.
- Объясняет, где хранится состояние приложения и почему это решение не заблокирует масштабирование в будущем.
- Умеет обосновать выбор между вертикальным и горизонтальным масштабированием под конкретную задачу, а не применяет один и тот же шаблон везде.
- Даёт возможность нагрузочного тестирования перед запуском, а не полагается только на теоретические расчёты.
Частые вопросы
С какой нагрузки система считается высоконагруженной?
Универсального порога не существует — дело не в абсолютном числе пользователей, а в том, справляется ли текущая архитектура с нагрузкой без деградации отклика или падений. Система на тысячу пользователей с плохо спроектированной базой данных может испытывать те же проблемы, что и система на миллион пользователей с грамотной архитектурой.
Нужно ли проектировать под высокую нагрузку с самого начала, если сейчас пользователей мало?
Не всегда — избыточно сложная архитектура на старте замедляет разработку и увеличивает стоимость там, где в этом ещё нет необходимости. Разумный подход — не проектировать сразу под миллион пользователей, но и не закладывать архитектурных решений, которые сделают масштабирование в будущем невозможным без полной переделки.
Что такое горизонтальное масштабирование простыми словами?
Вертикальное масштабирование — сделать один сервер мощнее. Горизонтальное — добавить больше серверов, которые работают параллельно и делят нагрузку между собой. Горизонтальное масштабирование обычно даёт больший запас роста, но требует, чтобы приложение изначально было спроектировано так, чтобы работать в нескольких экземплярах одновременно, а не полагаться на состояние, которое хранится только на одном сервере.
Зачем нужны очереди сообщений в высоконагруженной системе?
Очередь сообщений позволяет не обрабатывать все запросы мгновенно и синхронно, а поставить задачи в очередь и обрабатывать их по мере готовности ресурсов — это сглаживает пиковые нагрузки и не даёт системе упасть при резком всплеске запросов, ценой того, что результат обработки становится доступен не мгновенно, а с небольшой задержкой.
Можно ли добавить высокую нагрузочную способность в уже готовую систему позже?
Частично можно, но некоторые архитектурные решения проще заложить сразу, чем переделывать потом — например, хранение состояния сессии способом, который позволяет запускать несколько экземпляров приложения. Чем позже начинается адаптация системы под рост нагрузки, тем больше вероятность, что придётся переписывать значительную часть системы, а не точечно дорабатывать.
Расскажите про ожидаемый рост нагрузки — на созвоне за 40 минут поймём, какая архитектура нужна сейчас, а что можно добавить позже.
Обсудить проект