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

← [Раздел](README.md) · [Главная](../README.md)

## Цель

Различать **scale up** (вертикаль) и **scale out** (горизонталь), понимать ограничения каждого подхода и когда что применять в облаке.

## Предварительно

- [Оглавление раздела 06](README.md)

## Время

**3–4 часа**

---

## Вертикальное масштабирование (scale up)

**Идея:** сделать **один** сервер мощнее — больше CPU, RAM, быстрее диск.

| Плюсы | Минусы |
|-------|--------|
| Просто: сменить тип ВМ | Потолок железа |
| Нет распределённой логики | Downtime при resize (часто) |
| Подходит для БД на старте | Дорого на верхних размерах |
| | Single point of failure |

```mermaid
flowchart LR
  Before[API 2 vCPU 4GB] -->|scale up| After[API 8 vCPU 32GB]
```

**Когда:** MVP, монолит, managed DB до первых признаков упора в один узел.

---

## Горизонтальное масштабирование (scale out)

**Идея:** **больше экземпляров** одного и того же сервиса за балансировщиком.

| Плюсы | Минусы |
|-------|--------|
| Выше потолок throughput | Нужен stateless или shared state |
| Отказ одного инстанса — не катастрофа | Сложнее деплой и данные |
| Elastic в облаке | Согласованность данных |

```mermaid
flowchart TB
  LB[Load Balancer]
  LB --> API1[API replica 1]
  LB --> API2[API replica 2]
  LB --> API3[API replica 3]
  API1 --> DB[(DB)]
  API2 --> DB
  API3 --> DB
```

**Когда:** HTTP API с ростом RPS, workers очереди.

---

## Сравнительная таблица

| Критерий | Вертикаль | Горизонталь |
|----------|-----------|-------------|
| Сложность | Низкая | Средняя+ |
| Отказоустойчивость | Одна точка | N реплик |
| Стоимость на экстремумах | Часто хуже | Линейнее |
| БД write | Часто vertical | Шардинг сложен |
| API read-heavy | Кэш + vertical DB | Реплики + scale out API |

---

## Elasticity в облаке

**Auto Scaling Group / HPA (K8s):**

| Метрика | Действие |
|---------|----------|
| CPU > 60% 5 мин | +1 реплика |
| CPU < 30% 10 мин | -1 реплика |
| Custom: RPS | По запросам в секунду |

Минимум 2 реплики в prod для **availability** при rolling update.

---

## Узкие места при росте

| Компонент | Первый симптом | Мера |
|-----------|----------------|------|
| API CPU | Медленные ответы | Scale out |
| БД connections | `too many clients` | Pooler, read replicas |
| БД disk I/O | Slow queries | Индексы, bigger disk |
| Один регион | Latency издалека | CDN, multi-region позже |
| Синхронный SaaS | Хвост latency | Async |

---

## Шардинг (введение)

Когда одна БД не тянет **write**:

| Шард | Данные |
|------|--------|
| Shard A | user_id 0–999999 |
| Shard B | user_id 1M+ |

Сложность: кросс-шард запросы, ребаланс. **Не** для дня первого.

---

## Cost vs performance

Горизонталь без лимитов → счёт **растёт** при DDoS или баге (бесконечный autoscale). Закладывайте **max replicas** и бюджетные алерты.

---

## Практика

1. Для 100 → 10k пользователей: что scale up, что scale out? (таблица)  
2. Нарисуйте 3 API за LB.  
3. Почему БД сложнее масштабировать горизонтально, чем API?

---

## Самопроверка

1. Scale up — это больше машин или мощнее одна?  
2. Зачем min 2 реплики в prod?  
3. Что такое HPA одним предложением?

---

## Дальше

→ [Stateless vs stateful](stateless-vs-stateful.md)