Масштабирование инфраструктуры сайта при росте нагрузки

Масштабирование инфраструктуры сайта при росте нагрузки

Масштабирование — не замена маленького сервера большим. Это архитектурный процесс: сначала оптимизация, затем горизонтальное масштабирование, потом вертикальное (если нужно). Неправильный порядок приводит к трате бюджета без решения проблемы.

Диагностика узких мест

Прежде чем масштабировать — понять, где бутылочное горлышко:

# CPU-bound?
top -b -n 1 | head -20
# I/O-bound?
iostat -x 1 5
# Memory-bound?
free -m && vmstat 1 5
# Database?
mysql -e "SHOW PROCESSLIST;"
psql -c "SELECT pid, now() - pg_stat_activity.query_start AS duration, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC LIMIT 10;"
# Network?
ss -s

Инструменты нагрузочного тестирования:

# k6
k6 run --vus 100 --duration 30s script.js

# ab (Apache Bench)
ab -n 10000 -c 100 https://mysite.com/

# wrk
wrk -t12 -c400 -d30s https://mysite.com/

Слои масштабирования

1. Кэширование (самый дешёвый ROI)

# Nginx: кэширование статики
location ~* \.(css|js|jpg|png|gif|ico|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# FastCGI cache для PHP
fastcgi_cache_path /tmp/nginx-cache levels=1:2 keys_zone=MYAPP:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

# Redis для кэширования приложения
# Laravel:
php artisan config:cache
php artisan route:cache
php artisan view:cache

2. CDN

// Cloudflare/CloudFront перед сервером
// Правило: статика кэшируется на Edge, API пропускается
const cacheControl = isStatic ? 'public, max-age=31536000' : 'no-cache';

3. Database optimization

-- Поиск медленных запросов
EXPLAIN ANALYZE SELECT * FROM products WHERE category_id = 5 ORDER BY created_at DESC LIMIT 20;

-- Добавление индекса
CREATE INDEX CONCURRENTLY idx_products_category_created
ON products (category_id, created_at DESC);

-- PostgreSQL connection pooling через PgBouncer

4. Горизонтальное масштабирование

# Kubernetes HPA (Horizontal Pod Autoscaler)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

5. Разделение сервисов

Монолит → Микросервисы (постепенно):
├── API Gateway (Nginx/Kong)
├── Auth Service (stateless JWT)
├── Content Service
├── Media Service (отдельный для загрузки файлов)
└── Search Service (Elasticsearch)

6. Очереди для тяжёлых операций

// Вместо синхронной обработки — очередь
// Laravel Queue + Redis
dispatch(new ProcessImageJob($uploadedFile->path()));
dispatch(new SendEmailBatchJob($users));
dispatch(new GeneratePdfReportJob($orderId));

Архитектурные решения по уровню нагрузки

Правило: масштабируй то, что измерено как узкое место. Не масштабируй предположения.

Аудит и оптимизация под нагрузку (без смены архитектуры) — 1–2 недели. Переход на горизонтальное масштабирование — 2–6 недель.