← Назад к вопросам

Что такое горизонтальное масштабирование?

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

Заключение

Горизонтальное масштабирование это добавление больше серверов. Более сложно чем вертикальное, но:

  • Неограниченная масштабируемость
  • Высокая доступность
  • Удешевление при росте
  • Лучше для облака и микросервисов