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

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

• Сколько людей работает одновременно в самый плотный час. Для действующего сервиса это берётся из журналов балансировщика и приложения. Для нового это гипотеза бизнеса, и мы так её и записываем: «принято как гипотеза, проверим после запуска».
• Из чего состоит запрос в пик. Какая доля запросов читает, какая пишет, какая обращается к внешней системе.
• Насколько быстро растёт пик. Рост за час и всплеск за минуту после уведомления лечатся по-разному: во втором случае не успевают ни добавление мощностей, ни прогрев кэша.
• Что нельзя ронять ни при каком пике. Обычно это вход, оплата и оформленные заказы.

Как строим нагрузочное испытание

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

Число одновременных пользователей на выходе мы называем только по замерам на вашем стенде и не переносим с других проектов.

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

Сессии и токены

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

Ограничение числа запросов

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

Виртуальная очередь

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

Эта страница про сервис для массового пользователя, где главный риск связан с пиками. Если у вас закрытая корпоративная система с долгими отчётами и релизами раз в квартал, смотрите микросервисы и высокую нагрузку. Выбор между монолитом и сервисами описан в статье «Микросервисы или монолит»: для большинства B2C-сервисов на старте достаточно монолита с правильным кэшем и очередью.

Если сервиса ещё нет, начните со веб-сервиса или веб-приложения. Если вы продаёте доступ компаниям, а не людям, это SaaS-платформа. Если нужен кабинет к данным учёта, хватит личного кабинета. Если проблема в обмене с внешними системами, начинают с API и бэкенда. Состояние кода покажет аудит кода и архитектуры.