Направление 01
Высоконагруженные платформы
Система становится высоконагруженной не в момент, когда пользователей стало много, а когда рост перестал решаться увеличением мощности сервера. Дальше помогает только архитектура: разделение нагрузки, асинхронные операции и понятные пределы каждого узла.
Диагностика
Когда пора менять архитектуру, а не сервер
Четыре признака, по которым видно, что предел вертикального масштабирования достигнут.
- 01
Пик кладёт систему
В обычный день всё работает, но распродажа, рассылка или всплеск трафика роняют сервис. Значит, нагрузка нигде не сглаживается: запросы идут напрямую в самое дорогое место системы.
- 02
База данных — узкое горлышко
Отклик растёт вместе с объёмом данных, а не с числом пользователей. Обычно это отсутствие разделения чтения и записи, тяжёлые отчёты в той же базе, что и продакшн-нагрузка, или индексы, спроектированные под другой профиль запросов.
- 03
Отказ одного узла останавливает всё
Падение стороннего сервиса, очереди или одного инстанса выводит из строя весь продукт. Значит, границы отказа не заданы: нет таймаутов, повторов и деградации до урезанного, но работающего режима.
- 04
Причину инцидента ищут вручную
После сбоя команда лезет в логи по SSH и восстанавливает картину по кускам. Наблюдаемость — метрики, трассировки и алерты — часть архитектуры, а не то, что докручивают после запуска.
Схема
Как проходит запрос в такой системе
Упрощённый маршрут: между пользователем и данными стоит несколько слоёв, и каждый существует ради конкретного ограничения — латентности, пика или стоимости.
- Edge
Кромка
Статика и кэшируемые ответы отдаются, не доходя до приложения. Самый дешёвый запрос — тот, который не дошёл до бэкенда.
- Gateway
Шлюз
Аутентификация, лимиты на частоту запросов и маршрутизация. Здесь же обрывается заведомо мусорный трафик.
- Services
Сервисы
Бизнес-логика, разложенная по границам ответственности. Масштабируется горизонтально: узкое место расшивается добавлением инстансов, а не переписыванием.
- Queue
Очередь
Всё, что не обязано выполниться в момент запроса, уходит в асинхронную обработку: начисления, письма, выгрузки, интеграции. Очередь сглаживает пик.
- Cache
Кэш
Горячие данные лежат рядом с сервисом. Ключевой вопрос здесь не скорость, а инвалидация: устаревший ответ хуже медленного.
- Storage
Хранилище
Запись и чтение разделены, тяжёлая аналитика вынесена из боевой базы. Отчёты не должны конкурировать за ресурсы с пользовательскими запросами.
Наблюдаемость — метрики, трассировки, логи и алерты — снимается со всех слоёв сразу, иначе картины инцидента не собрать.
Работы
Что делаем на таких проектах
- 01
Проектирование с нуля
Архитектура под профиль нагрузки, который известен заранее: сколько пользователей, какие пики, какая цена простоя.
- 02
Аудит существующей системы
Разбор архитектуры и кода, нагрузочные сценарии, поиск узких мест. На выходе — список проблем с оценкой стоимости каждой.
- 03
Расшивка узких мест
Точечные изменения там, где они дают результат: разделение чтения и записи, кэширование, вынос тяжёлых операций в очереди.
- 04
Отказоустойчивость
Таймауты, повторы, ограничители, деградация до урезанного режима. Отказ части системы не должен останавливать продукт целиком.
- 05
Наблюдаемость
Метрики, трассировки и алерты, по которым видно состояние системы до того, как о нём сообщат пользователи.
- 06
Передача команде
Документация по решению и инфраструктуре, чтобы команда заказчика могла развивать систему без нас.
Вопросы
О высоких нагрузках
01
Что считается высоконагруженной системой?
Система становится высоконагруженной, когда рост числа пользователей или объёма данных перестаёт решаться увеличением мощности сервера. На практике это десятки тысяч одновременных пользователей, миллионы событий в сутки или требование отвечать за десятки миллисекунд под пиком. Такие системы проектируют иначе с самого начала: разделяют чтение и запись, выносят тяжёлые операции в очереди, закладывают горизонтальное масштабирование и наблюдаемость.
02
Можно ли ускорить систему без переписывания?
Часто да. Значительная часть проблем с производительностью решается точечно: индексы под реальный профиль запросов, кэширование горячих данных, вынос тяжёлых операций в асинхронную обработку, разделение чтения и записи. Переписывание оправдано, когда архитектура принципиально не допускает горизонтального масштабирования. Понять, какой случай перед вами, можно только после аудита.
03
Как проверяют, что система выдержит нагрузку?
Нагрузочным тестированием на сценариях, повторяющих реальное поведение пользователей, а не абстрактными запросами к главной странице. Тест показывает три вещи: при какой нагрузке начинает расти время ответа, какой узел упирается первым и как система ведёт себя после снятия нагрузки. Без такого теста цифры пропускной способности — предположение.
04
Сколько времени занимает аудит архитектуры?
Обычно от одной до трёх недель в зависимости от размера системы и доступности документации. В аудит входит разбор архитектуры, чтение ключевых частей кода, анализ схемы данных и профиля нагрузки. Результат — документ со списком узких мест, оценкой рисков и стоимостью работ по каждому пункту.
05
Что происходит с системой во время переработки архитектуры?
Она продолжает работать. Изменения вносятся постепенно: новый слой ставится рядом со старым, трафик переключается частями, каждый шаг обратим. Одномоментная замена всей системы — самый дорогой и самый рискованный сценарий, и мы его не предлагаем.
Дальше
Разберём вашу нагрузку
Напишите, что за система, где она ложится и какой профиль нагрузки ожидается. Предложим следующий шаг: аудит того, что есть, или проектирование того, чего пока нет.