Высоконагруженные порталы

Что входит

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

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

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

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

Этапы работы

1. 01Проектирование архитектуры под нагрузку
2. 02Разработка и оптимизация запросов
3. 03Кеширование, очереди и масштабирование
4. 04Нагрузочные тесты и вывод в продакшн

Частые вопросы

Как строится работа над таким проектом?

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

Обязательно ли переписывать проект с нуля?

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

Как понять, что нагрузка действительно высокая?

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

Что понадобится от вас?

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