Горизонтальное масштабирование
Тема дорожной карты · Backend разработчик
Горизонтальное масштабирование — практика обработки возросшей нагрузки путём добавления новых экземпляров сервиса вместо модернизации единственного сервера (вертикальное масштабирование); это фундаментальная стратегия масштабирования для stateless бэкенд-сервисов в современных облачно-нативных архитектурах. Поскольку stateless REST API-сервисы не хранят состояние сессий в процессе — делегируя аутентификацию валидации JWT и кеширование внешним Redis-экземплярам, — любой новый экземпляр может обслуживать любой запрос, обеспечивая прозрачное горизонтальное масштабирование за балансировщиком нагрузки. Kubernetes — основная платформа для горизонтального масштабирования: HorizontalPodAutoscaler (HPA) мониторит метрики Prometheus и автоматически подстраивает количество реплик подов под спрос, тогда как кластерные автоскейлеры добавляют новые узлы при полной загрузке существующих. Горизонтальное масштабирование требует, чтобы бэкенд-сервисы изначально проектировались для конкурентного выполнения: общее состояние должно жить во внешних системах (PostgreSQL, Redis, топики Kafka), а загрузки файлов — нацеливаться на объектное хранилище, а не на локальный диск. Уровни баз данных, как правило, сложнее всего масштабировать горизонтально, требуя методик репликации базы данных (read replica для PostgreSQL), шардинга (MongoDB, Cassandra), или выгрузки нагрузки чтения в Elasticsearch — именно поэтому стратегии горизонтального масштабирования приложений и баз данных должны планироваться совместно.
Как это работает
Горизонтальное масштабирование бывает вертикальным (более мощная машина) — до лимитов одной, потом горизонтальным (больше машин за балансировщиком). Stateless-сервисы масштабируются горизонтально тривиально; stateful (БД, очереди) — через primary-replica репликацию, шардинг или оба. Read-реплики поглощают read-нагрузку; write-throughput требует либо больший primary, либо шардинг, либо хитрости (CQRS + eventual-consistency reads). Агрессивно кешируйте на границе (CDN), на app-слое (Redis), внутри процесса.
Когда применять
Сначала вертикально — самое дешёвое и наименее болезненное операционно. Read-реплики — когда primary DB тратит > 50% CPU на чтения. Шардируйте только когда ни один primary не справляется с write rate (эта точка дальше, чем думают — Postgres держит 10k+ writes/sec с тюнингом). CDN — для любого публичного статичного или редко-меняющегося контента; выигрыш в latency обычно 5-10×.
Типичные ошибки
Ловушки Горизонтальное масштабирование: расчёт, что горизонтальное масштабирование решит всё (нет для stateful); преждевременный шардинг (необратимо без огромных миграций); игнор pooling — 1000 app-pod'ов по 10 соединений валят БД; не нагружаете до решений о масштабе (тюните не тот слой). Сначала меряйте, потом масштабируйте, потом документируйте.