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

Сайт начинает тормозить при 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-среду.