Горизонтальное масштабирование как операция на открытом сердце

Для кого: инженеры, отвечающие за аптайм и трафик. Если в вашей архитектуре до сих пор есть "sticky sessions", а деплой = молитва — эта глава должна выбить почву из-под ног и заставить переделать основу.

Провокация №1: ваши пользователи привязаны к конкретному серверу?

• Sticky sessions = долговая яма. Как только state хранится в памяти процесса, вы не сможете балансировать нагрузку честно. Один сервер перегорит, остальные будут скучать.

• Проверьте себя: зайдите в конфиг load balancer'а. Если там ip_hash, cookie или «session affinity» — вы до сих пор в 2008 году.

• Переходный план (если вы зарыты в legacy):

  Неделя	Действие	Метрика успеха
  1	Dual-write сессий: и в память, и в Redis	100% записей дублируются
  2	10% трафика без sticky	Error rate < 0.1%
  3	50% трафика без sticky	P95 latency не вырос
  4	100% без sticky, удаляем affinity	Сессии переживают убийство сервера

• Цель: любое приложение должно быть stateless, а state — вынесен в управляемые компоненты: Redis, БД, message bus.

1. Statless против Stateful: разбираем по косточкам

1.1 Тест на stateless

1. Убейте произвольный сервер приложения.
2. Запросите /api/profile с того же клиента.
3. Если пользователь вылетел из сессии — вы stateful и не готовы к горизонтальному масштабированию.

1.2 Как выносить state

• Сессии → Redis/Sentinel/Cluster. TTL, репликация, мониторинг. Обязательно включите автоматическое продление TTL при обращении.
• Аутентификация → JWT/opaque токены. Минимизируйте state: токен содержит всё необходимое, серверы проверяют подпись.
• Очереди: фоновые задачи не должны висеть в памяти API. Kafka/RabbitMQ/SQS.
• Кеш: сессионные данные и rate limiting хранятся в Redis/KeyDB, а не в Map внутри Node.js.

1.3 Контроль

• Настройте тест, который каждые 5 минут убивает случайный pod/EC2 instance. Если error rate растёт, значит, state ещё внутри приложения.

Провокация №2: Load balancer — ваш единственный point of failure?

Если LB лежит — весь кластер мёртв. Симуляция: остановите Nginx/ALB на staging. Система пережила? Если нет, читайте дальше.

2. Load Balancer: стратегии и тёмные углы

2.1 Архитектура

• Горизонтальный LB слой: минимум 2 инстанса (Nginx/HAProxy/envoy) + health-checker.
• DNS: используйте Route 53/Cloud DNS с health checks, чтобы при падении LB трафик мигрировал.
• Наблюдаемость: метрики upstream_response_time, active_connections, 502/504.

2.2 Алгоритмы

Кейс: e-commerce с акциями. Во время пика 20% запросов long-polling. Round Robin приводит к переполнению очередей на одном сервере. Переключение на least_conn + лимит активных соединений спасает.

2.3 Health-check — не формальность

• Passive HC: max_fails, fail_timeout. Настройте так, чтобы сервер исключался после 2–3 подряд 5xx.
• Active HC: отдельный эндпоинт /readyz, который проверяет БД, кэш, внешние API. Liveness (/healthz) — просто проверка процесса.
• Правило: здоровый сервер = тот, что успел прогреть кэш и подключиться к БД. Не пускайте трафик раньше.
• Пример:

  curl -f "http://localhost:3000/readyz" \
    -H "X-Health-Check: deep" \
    --max-time 3 \
    --retry 2 \
    --retry-delay 1

2.4 Конфигурация Nginx (проверенный шаблон)

upstream backend {
  least_conn;
  server app1.internal:3000 max_fails=2 fail_timeout=15s weight=2;
  server app2.internal:3000 max_fails=2 fail_timeout=15s weight=2;
  server app3.internal:3000 max_fails=2 fail_timeout=15s weight=1;
  keepalive 48;
}
 
server {
  listen 443 ssl http2;
  server_name api.example.com;
 
  # Rate limiting
  limit_req_zone $binary_remote_addr zone=api_limit:20m rate=200r/s;
 
  log_format json_analytics '{"time":"$time_iso8601","status":$status,"request_time":$request_time,"upstream_addr":"$upstream_addr","upstream_response_time":"$upstream_response_time","upstream_status":"$upstream_status","request":"$request"}';
  access_log /var/log/nginx/access.log json_analytics;
 
  location /api/ {
    limit_req zone=api_limit burst=100 nodelay;
    proxy_pass http://backend;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_buffering on;
    proxy_connect_timeout 5s;
    proxy_read_timeout 60s;
    proxy_next_upstream error timeout http_502 http_503;
    proxy_next_upstream_tries 2;
    proxy_next_upstream_timeout 1s;
  }
 
  location /readyz { proxy_pass http://backend; access_log off; }
  location /healthz { return 200 'ok'; }
}

Тест: nginx -t, nginx -s reload, затем wrk -t8 -c64 -d60s https://api.example.com/readyz. Проверяйте upstream_status в логах.

Провокация №3: Сессии всё ещё в памяти?

Если вы храните Map<sessionId, data> в приложении, деплой = убийство пользователей. Это неприемлемо.

3.1 Стратегии

1. Redis + TTL + репликация: используйте Sentinel/Cluster. Ключ session:{id} → JSON. TTL продлевайте при каждом обращении.
2. JWT: минимальный state. Включите ротацию ключей, короткий TTL, refresh-токены.
3. Opaque tokens + storage: хэш токена + user data в БД/Redis.
4. WebSocket state: выносите в отдельный state store (например, Redis pub/sub или Kafka). Серверы должны быть взаимозаменяемы.

3.2 Контроль качества

• Инструмент: chaos-проверка SESSION_KILL — трафик идёт через LB, случайный сервер убивается, пользователь не теряет state.
• Метрика: время восстановления сессии после падения сервера < 1 секунды.

Провокация №4: деплой = 5xx?

Если каждое обновление = штурм Slack, вы ещё не умеете deploy без downtime.

4.1 Rolling deployment сценарий

1. Drain traffic: kubectl cordon + drain / nginx -s quit.
2. Graceful shutdown: приложение закрывает входящие соединения, ждёт 30 секунд, завершает воркеры.
3. Health-check gate: пока /readyz не возвращает 200 + «warmed=true», сервер не получает трафик.
4. Логи: в Kibana/CloudWatch ищите 5xx во время деплоя. Допустимый всплеск — < 0.5% от общего трафика.

4.2 Blue/Green vs Rolling

• Blue/Green: мгновенное переключение DNS/Ingress между версиями. Цена — двойное потребление ресурсов.
• Rolling: дешевле, но требует идеального graceful shutdown. Не подходит для радикальных миграций (schema change).
• Canary: 5–10% трафика идёт на новую версию, остальное — на старую. Сравните error rate, P99 latency и бизнес-KPI в течение 15–30 минут. Если новая версия не хуже по всем метрикам — расширяем. Требует маршрутизации и feature flag'ов, но ловит баги до массового инцидента.
  • Метрики: error_rate_new <= error_rate_old, P99_new <= P99_old * 1.1, бизнес-KPI без деградации, CPU/RAM в пределах бюджета.

4.3 Graceful shutdown для Node.js/Go/Java

• Закройте входящие соединения (server.close() / http.Shutdown).
• Дождитесь завершения активных запросов (таймаут 30–60 с).
• Освободите ресурсы (БД, очереди).
• Отдавайте /readyz = 503, чтобы LB перестал слать трафик.

Провокация №5: тестируете ли вы отказ load balancer’а?

• Сценарий: выключите один LB-инстанс. Трафик должен автоматически перейти на резервный. В DNS — health check + failover. В Kubernetes — минимум два ingress controller’а.
• Метрики:
  • failover < 30 секунд,
  • error rate < 2% во время переключения,
  • через 5 минут состояние «как было».

5. Экономика горизонтального масштабирования: считаем деньги

Важно: Архитектор, не считающий деньги, — угроза бизнесу. Каждое решение о масштабировании должно иметь экономическое обоснование.

5.1 Стоимость scale-out: 1 сервер vs кластер

Сценарий: API сервис на Node.js, 500 RPS, требует 4 vCPU и 8GB RAM.

Вариант A: Один мощный сервер (вертикальное масштабирование)

AWS EC2 (us-east-1, on-demand):

• Instance: c6i.2xlarge (8 vCPU, 16GB)
• Стоимость: $0.34/час = $245/месяц
• Headroom: 100% (можем вырасти до 1000 RPS)

Плюсы:

• ✅ Простота (один сервер)
• ✅ Нет затрат на load balancer
• ✅ Минимальная операционная сложность

Минусы:

• 🔴 Single point of failure
• 🔴 Zero-downtime деплой невозможен
• 🔴 Нет отказоустойчивости

Вариант B: Кластер из 3 серверов (горизонтальное масштабирование)

Компоненты:

1. Load Balancer (ALB):

   • $16.20/месяц (фиксированная часть)
   • $0.008/LCU-час (переменная часть)
   • ~$25/месяц при умеренной нагрузке

2. 3× API серверы:

   • Instance: t3.large (2 vCPU, 8GB) каждый
   • Стоимость: $0.0832/час × 3 = $180/месяц

Итого: $205/месяц (LB + серверы)

Плюсы:

• ✅ High availability (падение 1 сервера = 66% capacity)
• ✅ Zero-downtime деплой (rolling update)
• ✅ Готовность к росту (легко добавить 4й, 5й сервер)

Минусы:

• 🟡 Операционная сложность (3 сервера вместо 1)
• 🟡 Stateless architecture обязательна

Сравнение стоимости

Вывод: Горизонтальное масштабирование не только надежнее, но и дешевле при правильном выборе инстансов!

5.2 Break-even point: когда scale-out становится выгоднее

Вопрос: При каком RPS горизонтальное масштабирование начинает окупаться?

Расчет:

Cost_vertical = instance_cost (растет ступенчато при апгрейде)
Cost_horizontal = LB_cost + (num_servers × server_cost)
 
Break-even: когда Cost_horizontal < Cost_vertical

Пример (Node.js API):

Вывод: После 500 RPS горизонтальное масштабирование почти всегда дешевле.

5.3 Reserved Instances vs On-Demand: экономия до 72%

Сценарий: Вы знаете, что кластер будет работать минимум год.

Стратегия экономии:

Рекомендация для production кластера из 3×t3.large:

Baseline capacity (всегда нужны): 2 сервера
→ Reserved Instances: 2×$35/мес = $70/мес
 
Burst capacity (иногда нужны): 1-3 сервера
→ On-Demand или Spot: 1×$60/мес = $60/мес
 
Итого: $130/мес вместо $180/мес
Экономия: $50/мес = $600/год

5.4 Cloud vs Self-hosted: TCO сравнение

Сценарий: 5 серверов API (5×t3.large = 10 vCPU, 40GB RAM total)

Вариант A: AWS (managed cloud)

Компоненты:

• 5× t3.large (Reserved 1yr): $175/мес
• ALB: $25/мес
• Data transfer out (500GB): $45/мес
• EBS volumes (5×100GB gp3): $40/мес
• CloudWatch logs: $10/мес
• Итого: $295/месяц

Плюсы:

• ✅ Zero DevOps для инфраструктуры
• ✅ Автоматические бэкапы, патчи
• ✅ Global availability (multi-region легко)

Минусы:

• 🔴 Высокая стоимость data transfer
• 🔴 Vendor lock-in

Вариант B: Self-hosted (bare metal или Hetzner)

Компоненты:

• 2× Dedicated servers (16 vCPU, 64GB RAM каждый): €89/мес × 2 = $190/мес
• Nginx LB (на тех же серверах): $0
• Bandwidth (20TB included): $0
• Backup storage (1TB): $10/мес
• Итого серверы: $200/месяц

DevOps costs (скрытые):

• Зарплата DevOps инженера (1 FTE): $8,000/мес
• Амортизация времени на поддержку: ~10% времени = $800/мес
• Итого с DevOps: $1,000/месяц

Плюсы:

• ✅ Низкая стоимость железа
• ✅ Нет ограничений по bandwidth
• ✅ Full control

Минусы:

• 🔴 Операционная сложность
• 🔴 Нужна команда DevOps
• 🔴 Медленное масштабирование (заказ сервера = дни)

TCO сравнение (3 года)

Вывод: AWS выгоднее для команд < 50 инженеров. Self-hosted — только при большом масштабе (100+ серверов) или специфичных требованиях.

5.5 Auto-scaling: экономия 40-60% в off-peak

Проблема: В ночное время (00:00-06:00) RPS падает на 70%, но вы платите за все серверы.

Решение: Auto-scaling по CPU или RPS.

Пример конфигурации (AWS Auto Scaling):

min_capacity: 2 # Всегда минимум 2 для HA
max_capacity: 10 # Максимум при пиковой нагрузке
target_cpu: 60% # Поддерживаем CPU около 60%
 
scale_out:
  metric: CPUUtilization > 70%
  cooldown: 300s # Подождать 5 минут перед добавлением еще одного
 
scale_in:
  metric: CPUUtilization < 40%
  cooldown: 600s # Подождать 10 минут перед удалением

Экономия (реальный кейс):

Средняя экономия за сутки: ~30%

Стоимость:

• Без auto-scaling: 5 серверов × 24 часа = 120 server-hours/день
• С auto-scaling: ~84 server-hours/день (оценка)
• Экономия: $60/мес → $42/мес = $18/мес (30%)

5.6 Cost allocation: кто платит за инфраструктуру?

Проблема: Несколько команд используют один кластер. Как распределить costs?

Решение: Tagging + cost allocation.

Пример (AWS Cost Allocation Tags):

# Каждый сервер/LB должен иметь теги:
Environment: production
Team: payments
Product: checkout-api
CostCenter: engineering-backend

Отчет по costs (пример месяца):

Польза:

• ✅ Прозрачность расходов
• ✅ Стимул оптимизировать (команды видят свои costs)
• ✅ Chargeback модель (можно списывать с бюджета команд)

5.7 Cost optimization checklist

Перед масштабированием задайте эти вопросы:

• Нужно ли вообще масштабировать? Может быть, проблема в медленном запросе?
• Вертикальное vs горизонтальное? Посчитайте break-even point.
• Reserved Instances? Если capacity стабильна, экономьте 40%.
• Auto-scaling? Если нагрузка предсказуема, экономьте 30%.
• Spot Instances? Для stateless workloads — экономия 70%.
• Right-sizing? Проверьте CPU/Memory utilization (может быть, переплачиваете).
• Data transfer costs? Используйте CloudFront/CDN для статики.
• Cross-AZ traffic? $0.01/GB между AZ — может быть дорого.

5.8 Реальный кейс: оптимизация $10k/мес → $3k/мес

Компания: E-commerce стартап, 2,000 RPS пик.

Было (до оптимизации):

• 10× c5.xlarge (on-demand): $1,700/мес
• 3× ALB: $75/мес
• Data transfer: $500/мес
• Logs/metrics: $200/мес
• Total: $2,475/мес (только API, без БД)

Проблемы:

• ❌ Over-provisioned (CPU utilization 20-30%)
• ❌ Все on-demand
• ❌ Нет auto-scaling
• ❌ Статика через API (data transfer)

Что сделали:

1. Right-sizing: c5.xlarge → t3.large (достаточно CPU)
2. Reserved Instances: 5 серверов baseline (1yr)
3. Auto-scaling: 5-10 серверов в зависимости от нагрузки
4. CDN для статики: CloudFront + S3
5. Consolidated ALBs: 3 → 1 (path-based routing)

Стало:

• 5× t3.large (Reserved): $175/мес
• 0-5× t3.large (On-Demand, auto-scale): ~$150/мес avg
• 1× ALB: $25/мес
• Data transfer (90% через CDN): $50/мес
• CloudFront: $30/мес
• Logs/metrics (sampling): $50/мес
• Total: $480/мес

Экономия: $2,475 → $480 = -$1,995/мес (-81%) ROI: Работа заняла 1 неделю (стоимость ~$2,000). Окупилось за 1 месяц.

6. Практика: без этого нет смысла идти дальше

1. Stateless check:
   • Шаг 1: раз в день в off-peak убивайте один сервер и проверяйте UX.
   • Шаг 2: когда метрики стабильны, повышайте частоту до 1 раза в 4 часа.
   • Шаг 3: продвинутая стадия — каждые 30 минут, включая пиковые часы. Критерий: пользователи не теряют state.
2. Load balancer drill:
   • Прогоните wrk/k6 со сценарием long-polling и short requests.
   • Найдите, какой алгоритм балансировки даёт минимальный latency для вашего трафика.
3. Session store migration:
   • Перенесите хотя бы один тип state (например, корзину) в Redis/JWT.
   • Измерьте разницу в error rate при падении сервера.
4. Zero-downtime rehearsal:
   • На staging выполните rolling деплой по шагам из раздела 4.1.
   • Снимите метрики до/после, докажите, что 5xx нет.
5. Chaos LB/AZ:
   • Отключите одну Availability Zone / LB-инстанс.
   • Метрики успеха: failover < 2 минут, error rate < 5%, ручное вмешательство = 0.
6. FinOps анализ (НОВОЕ):
   • Посчитайте стоимость вашего текущего кластера (или придуманного сценария)
   • Сравните: on-demand vs reserved instances vs spot
   • Найдите break-even point для вашей нагрузки
   • Предложите план экономии на 30%

Что дальше

Урок 03 — вертикальное масштабирование и оптимизация кода. После того как трафик научился бегать по нескольким серверам, нужно заставить каждый сервер работать на максимум: профилирование, cluster-mode, pool'ы БД. Не прыгайте туда, пока не выполнили практику отсюда.