Большинство систем падает не от миллионов пользователей, а от десяти тысяч, пришедших одновременно после рекламы. Разбираем принципы, которые позволяют пережить пик без переписывания всего.
Когда пора думать о нагрузке
- Время ответа растёт вместе с трафиком, а не остаётся постоянным.
- База данных загружена на 70% и выше в обычный день.
- Один сервер — единая точка отказа.
- Релизы требуют остановки системы.
- Вы планируете маркетинговую акцию, распродажу или выход на федеральный рынок.
Если хотя бы два пункта про вас — пора.
Пять принципов, которые работают
1. Кэшируйте всё, что можно. 80% запросов к интернет-магазину — чтение каталога, который меняется раз в час. Redis перед базой снимает 90% нагрузки. CDN перед сервером — ещё половину оставшегося.
2. Разделяйте чтение и запись. Реплики базы для чтения, мастер для записи. Отчёты и аналитика — в отдельное хранилище, ClickHouse, а не в боевую базу.
3. Всё тяжёлое — в очередь. Отправка писем, генерация PDF, обмен с 1С, пересчёт рекомендаций не должны выполняться в момент запроса пользователя. Kafka или RabbitMQ и воркеры, которые масштабируются независимо.
4. Горизонтальное масштабирование вместо вертикального. Десять небольших серверов за балансировщиком надёжнее и дешевле одного огромного. Приложение должно быть stateless: сессии в Redis, файлы в объектном хранилище.
5. Деградируйте изящно. При перегрузке отключайте рекомендации и персонализацию, но сохраняйте корзину и оплату. Пользователь, который смог купить, — важнее красивого баннера.
Микросервисы или монолит
Микросервисы — не синоним highload. Хорошо спроектированный модульный монолит на Go выдерживает десятки тысяч запросов в секунду. Микросервисы нужны, когда:
- Разные части системы нагружены по-разному и их нужно масштабировать отдельно.
- Над системой работает несколько команд.
- Отдельные модули требуют разного стека или частоты релизов.
Начинать с микросервисов небольшой продукт — переплатить за инфраструктуру и сложность.
Как подготовиться к пиковой нагрузке за месяц
- Нагрузочное тестирование. k6 или Yandex.Tank на копии продакшена. Узнайте, на каком RPS система ломается и где.
- Профилирование. Найдите 5 самых медленных запросов к базе. Обычно индексы решают половину проблем.
- Кэш. Redis для каталога, сессий, счётчиков. CDN для статики.
- Очереди. Вынесите всё, что не нужно делать синхронно.
- Автомасштабирование. Kubernetes или облачные группы серверов, которые добавляют мощности при росте нагрузки.
- Мониторинг и алерты. Prometheus, Grafana, оповещения при росте времени ответа и ошибок.
- План деградации. Что отключить первым, если всё-таки не хватает.
Типичные узкие места
- N+1 запросы в ORM — сто запросов к базе там, где нужен один.
- Отсутствие индексов на полях фильтрации и сортировки.
- Синхронные вызовы внешних API в критическом пути — платёжка ответила за 10 секунд, и ваш сервер ждёт.
- Файлы на локальном диске — не масштабируется.
- Один экземпляр приложения — деплой останавливает сервис.