Стратегия масштабирования при десятикратном росте нагрузки

Условие

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

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

• изменения в архитектуре;
• подходы к кэшированию;
• стратегии шардирования данных;
• систему мониторинга и оповещений;
• механизмы автоматического масштабирования.

Ответ

Сначала измерьте профиль 1000 RPS и определите запас до 10 000: доли чтения и записи, latency, БД и внешние зависимости. Масштабируйте подтверждённые узкие места поэтапно, не начиная автоматически с шардинга.

План на три месяца:

1. Зафиксировать SLO и нагрузочный сценарий с ростом данных, пиками и отказами.
2. Устранить дорогие запросы, настроить индексы, ограничить connection pools и подготовить отказоустойчивость PostgreSQL.
3. Масштабировать stateless-приложение за балансировщиком; вынести долгие операции в очередь.
4. Кешировать подходящие чтения с TTL, защитой от stampede и понятной инвалидацией. Реплики чтения применять с учётом lag.
5. Шардирование рассматривать при подтверждённом пределе одного узла. Выбрать ключ, оценить горячие tenant, миграцию и межшардовые операции; партиционирование таблицы само по себе не даёт дополнительных серверов.
6. Наблюдать p95/p99, ошибки, saturation, locks, lag и возраст очереди. Автомасштабирование ограничить возможностями БД и провайдеров.
7. Проверить 10 000 RPS с запасом, отказ узла и откат до выхода на новые рынки.