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

Сайт начинает тормозить при 500 RPS, а сервер упирается в CPU — пора масштабироваться. Многие клиенты приходят с проблемой: «купили мощный сервер, а нагрузка не снизилась». Мы сталкивались с этим не раз. Масштабирование инфраструктуры — не замена маленького сервера большим. Это архитектурный процесс: сначала оптимизация, затем горизонтальное масштабирование, потом вертикальное (если нужно). Неправильный порядок приводит к трате бюджета без решения проблемы. Наши инженеры с десятилетним опытом помогают пройти этот путь без простоев. Гарантируем стабильность на каждом этапе — все изменения проходят через stage-среду, обеспечивая uptime 99.9%. Один из клиентов — интернет-магазин с трафиком 2000 RPS — после реорганизации архитектуры снизил затраты на инфраструктуру на 40% при удвоении нагрузки. Экономия бюджета составила до 40% от прежних расходов.

Как диагностировать узкие места?

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

# CPU, I/O, memory, database, network diagnostics
top -b -n 1 | head -20
iostat -x 1 5
free -m && vmstat 1 5
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;"
ss -s

# Load testing with k6, ab, wrk
k6 run --vus 100 --duration 30s script.js
ab -n 10000 -c 100 https://mysite.com/
wrk -t12 -c400 -d30s https://mysite.com/

According to Wikipedia, horizontal scaling is often more cost-effective for high-load systems.

Почему кэширование — первый шаг?

Кэширование даёт самый быстрый ROI. Один из проектов — интернет-магазин на Laravel — после настройки Redis и Nginx fastcgi_cache снизил нагрузку на БД на 80% при тех же RPS. Вот конфигурация:

# Nginx: кэширование статики и FastCGI cache для PHP
location ~* \.(css|js|jpg|png|gif|ico|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
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 дополнительно кэширует данные приложения: php artisan config:cache, route:cache, view:cache.

CDN и балансировка

CDN (Cloudflare, CloudFront) разгружает сервер от статики. Настраиваем правило: статика кэшируется на Edge, API — пропускается. Для этого задаём заголовки Cache-Control в коде: const cacheControl = isStatic ? 'public, max-age=31536000' : 'no-cache';. Балансировщик (Nginx, HAProxy) распределяет трафик между репликами приложения — основа горизонтального масштабирования.

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

Горизонтальное масштабирование (добавление реплик) в 3–5 раз эффективнее вертикального (апгрейд железа) при высокой нагрузке, поскольку позволяет распределять трафик и даёт отказоустойчивость. Вертикальное масштабирование проще на старте, но упирается в физические ограничения.

Оптимизация базы данных

Даже с кэшем БД — частый bottleneck. Находим медленные запросы через EXPLAIN ANALYZE и добавляем индексы:

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);

Connection pooling через PgBouncer снижает нагрузку на БД в 2–3 раза. Также настраиваем пулы соединений для приложений: pdo_mysql.default_socket и max_connections в конфиге MySQL.

Как работают очереди задач?

Тяжёлые операции — рассылка писем, генерация PDF, обработка изображений — не должны выполняться синхронно. Используем очереди: Laravel Queue + Redis, RQ, или RabbitMQ. Это разгружает веб-сервер и улучшает отзывчивость. Пример с Laravel:

dispatch(new ProcessImageJob($file)); // Фронтенд не ждёт завершения — пользователь получает ответ мгновенно 

[program:queue-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/artisan queue:work redis --sleep=3 --tries=3
numprocs=2
autostart=true
autorestart=true
user=www-data

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

Один сервер не справляется — добавляем реплики. Kubernetes с HorizontalPodAutoscaler автоматически масштабирует количество подов по CPU:

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

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

Постепенно делим монолит на микросервисы:

• API Gateway (Nginx/Kong)
• Auth Service (stateless JWT)
• Content Service
• Media Service (отдельный для загрузки файлов)
• Search Service (Elasticsearch)

Тяжёлые операции выносим в очереди: вместо синхронной обработки используем Laravel Queue + Redis, выполняя dispatch(new ProcessImageJob(...)).

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

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

Что входит в работу

1. Аудит текущей архитектуры и узких мест (1-2 дня)
2. Настройка кэширования и CDN
3. Оптимизация БД: индексы, конфиги, пулинг
4. Контейнеризация приложения и настройка оркестрации
5. Нагрузочное тестирование до и после изменений
6. Документация и инструкции для команды

Сроки и бюджет

Аудит и оптимизация под нагрузку (без смены архитектуры) — 1–2 недели. Переход на горизонтальное масштабирование — 2–6 недель. Стоимость рассчитывается индивидуально после оценки вашей системы, но экономия от оптимизации обычно составляет 30-50% от текущих затрат. Получите консультацию — наши сертифицированные инженеры проанализируют вашу инфраструктуру и предложат план. Закажите аудит инфраструктуры — мы выявим узкие места и разработаем план масштабирования.

Опыт более 50 проектов по масштабированию, гарантия стабильности — все изменения проходят через stage-среду.