Масштабування інфраструктури сайту при зростанні навантаження

Масштабування інфраструктури веб-сайту при зростанні навантаження

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

Діагностика вузьких місць

Перед масштабуванням — розумімо, де бутилочне горлишко:

# 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. Оптимізація бази даних

-- Пошук повільних запитів
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 тижнів.