← Назад к вопросам
Что такое горизонтальное масштабирование?
2.0 Middle🔥 131 комментариев
#DevOps и инфраструктура#Архитектура и паттерны
Комментарии (1)
🐱
claude-haiku-4.5PrepBro AI30 мар. 2026 г.(ред.)
Ответ сгенерирован нейросетью и может содержать ошибки
Горизонтальное масштабирование: добавляй больше серверов
Что это
Горизонтальное масштабирование (horizontal scaling) это добавление большего количества серверов/машин для обработки нагрузки. Противоположность вертикальному масштабированию (добавить больше RAM/CPU к одному серверу).
Вертикальное vs Горизонтальное
Вертикальное (Vertical):
- Один сервер: 4GB RAM, 2 CPU
- Модернизация: 64GB RAM, 16 CPU
+ Проще
- Есть лимит физических возможностей
- Дорого
- Downtime при обновлении
Горизонтальное (Horizontal):
- Было: 1 сервер
- Стало: 4 сервера по 4GB RAM
+ Бесконечное масштабирование
+ Дешевле чем upgrade большого сервера
+ Нет downtime
- Более сложная архитектура
- Нужен load balancer
Архитектура
Без масштабирования:
USER → Server:3000 (100% load)
С горизонтальным масштабированием:
┌─→ Server1:3000
USER → LB ├─→ Server2:3000
├─→ Server3:3000
└─→ Server4:3000
Балансировщик нагрузки (Load Balancer)
Nginx как Load Balancer:
upstream backend {
server app1.example.com:3000;
server app2.example.com:3000;
server app3.example.com:3000;
server app4.example.com:3000;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
}
}
Round Robin: request 1 → server 1, request 2 → server 2, итд Least Connections: новый запрос на сервер с наименьшей нагрузкой IP Hash: один клиент всегда на одном сервере
Sticky Sessions (Session Affinity)
Проблема: Пользователь логинится на Server1
Основной запрос идёт на Server2
Server2 не знает что он залогинен!
Решение 1: Sticky sessions
- Один клиент всегда на одном сервере
- IP хеш или cookie
Решение 2: Shared session store
- Redis для хранения сессий
- Все серверы читают из Redis
Решение 3: Stateless (JWT)
- Нет сессий вообще
- Каждый запрос содержит всю информацию
Shared Data
Проблема: файлы загружаются на Server1
Но пользователь может скачать с Server2
Server2 не видит файл!
Решение 1: Shared Storage
- NFS (Network File System)
- S3 (облако)
- Все серверы видят одно место для файлов
Решение 2: Database
- Данные в PostgreSQL
- Все серверы читают из БД
Решение 3: Replication
- Копируем файлы между серверами
- Slow sync
Практический пример
// Application config
const express = require('express');
const redis = require('redis');
const app = express();
const redisClient = redis.createClient({
host: 'redis.example.com',
port: 6379
});
// Session store с Redis
const session = require('express-session');
const RedisStore = require('connect-redis').default;
app.use(session({
store: new RedisStore({ client: redisClient }),
secret: 'your-secret',
resave: false,
saveUninitialized: false
}));
// Теперь сессия работает на всех серверах
app.get('/', (req, res) => {
if (req.session.user) {
res.send(`Welcome ${req.session.user.name}`);
} else {
res.send('Login required');
}
});
app.listen(3000, () => {
console.log('Server started on :3000');
});
Docker + Kubernetes для масштабирования
# Kubernetes deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 4 # 4 копии приложения
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: my-app:1.0.0
ports:
- containerPort: 3000
env:
- name: REDIS_HOST
value: redis.default.svc.cluster.local
---
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
type: LoadBalancer
selector:
app: my-app
ports:
- port: 80
targetPort: 3000
Kubernetes автоматически:
- Создаёт 4 контейнера
- Балансирует нагрузку
- Перезапускает упавшие контейнеры
- Масштабирует при нужде
Масштабирование базы данных
Проблема: БД не масштабируется горизонтально
Решение 1: Read Replicas
- Master: write операции
- Replicas: read операции
- Асинхронная репликация
Решение 2: Sharding
- user_id 1-1000000 → shard 1
- user_id 1000001-2000000 → shard 2
- Распределяем данные
Решение 3: No-SQL (MongoDB, Cassandra)
- Встроенное горизонтальное масштабирование
- Шардирование встроено
Метрики для мониторинга
// При масштабировании нужно мониторить:
1. Request latency
- Среднее время ответа
- P95, P99 latency
2. Error rate
- Процент ошибок
- Alerting при > 1%
3. Resource utilization
- CPU per server (should be 50-70%)
- Memory usage
- Disk I/O
4. Database performance
- Connection pool utilization
- Slow query logs
- Replication lag
Когда масштабировать
✅ Горизонтально масштабируй когда:
- Нужна высокая доступность
- Нужна неограниченная масштабируемость
- Важен uptime (zero downtime deployment)
- Растёт трафик
❌ Вертикально масштабируй когда:
- Приложение monolithic
- Нет нужны в HA
- Простая архитектура важнее
- Бюджет позволяет дорогие серверы
Сложность горизонтального масштабирования
1. Stateless code
- Не сохранять данные в памяти
- Использовать Redis/БД для состояния
2. Session management
- Shared session store
- JWT токены
- Sticky sessions
3. Data consistency
- Database replication
- Eventual consistency в микросервисах
4. Deployment
- Rolling deployment
- Синхронизация версий приложения
5. Monitoring
- Distributed tracing
- Aggregated logs
- Metrics from all servers
Практический план масштабирования
Шаг 1: Один сервер
- Всё на одной машине
- Просто запустить
Шаг 2: Два сервера + Load Balancer
- 99.9% uptime
- Шаг к масштабируемости
Шаг 3: Четыре сервера
- Handle x2 нагрузки
- Redis для сессий/кэша
Шаг 4: Kubernetes
- Auto-scaling
- Self-healing
- Полная автоматизация
Инструменты для горизонтального масштабирования
- Nginx: load balancer
- HAProxy: advanced load balancing
- AWS ALB: cloud load balancer
- Kubernetes: orchestration
- Docker: containerization
- Redis: shared session/cache
- PostgreSQL replicas: read replicas
Заключение
Горизонтальное масштабирование это добавление больше серверов. Более сложно чем вертикальное, но:
- Неограниченная масштабируемость
- Высокая доступность
- Удешевление при росте
- Лучше для облака и микросервисов