Сайт починає гальмувати при 500 RPS, а сервер упирається в CPU — пора масштабуватися. Багато клієнтів приходять з проблемою: «купили потужний сервер, а навантаження не знизилося». Ми стикалися з цим не раз. Наша команда має 10+ років досвіду в масштабуванні інфраструктури сайту та реалізувала понад 50 проєктів. Масштабування інфраструктури — не заміна маленького сервера великим. Це архітектурний процес: спочатку оптимізація, потім горизонтальне масштабування, потім вертикальне (якщо потрібно). Неправильний порядок призводить до витрати бюджету без вирішення проблеми. Наші сертифіковані інженери (AWS, Kubernetes) допомагають пройти цей шлях без простоїв. Гарантуємо стабільність на кожному етапі — всі зміни проходять через 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/ Згідно з Wikipedia, горизонтальне масштабування часто є більш економічно ефективним для високонавантажених систем.
Кешування, CDN та балансування навантаження
Кешування дає найшвидший ROI. Один із проєктів — інтернет-магазин на Laravel — після налаштування Redis і Nginx fastcgi_cache знизив навантаження на БД на 80% при тих же RPS. Порівняно з використанням лише кешування nginx, комбінація Redis та FastCGI забезпечує прискорення у 5-10 разів. Ось конфігурація:
# 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 (Cloudflare, CloudFront) розвантажує сервер від статики — це основа балансування навантаження. Налаштовуємо правило: статика кешується на Edge, API — пропускається. Для цього задаємо заголовки Cache-Control в коді: const cacheControl = isStatic ? 'public, max-age=31536000' : 'no-cache';. Балансувальник (Nginx, HAProxy) розподіляє трафік між репліками додатка — основа горизонтального масштабування. Пам'ятайте: кешування nginx і CDN для сайту разом здатні знизити навантаження на сервер у 5-10 разів.
Чому варто обрати горизонтальне масштабування?
Горизонтальне масштабування (додавання реплік) у 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)); // Фронтенд не чекає завершення — користувач отримує відповідь миттєво Масштабування за допомогою Kubernetes HPA
Один сервер не справляється — додаємо репліки. Kubernetes з HorizontalPodAutoscaler (HPA) автоматично масштабує кількість подів по 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.
Архітектура за рівнем навантаження
| RPS | Архітектура | Орієнтовна вартість інфраструктури |
|---|---|---|
| До 50 | 1 VPS + Redis + PgBouncer | Невелика |
| 50–500 | 2–3 App + LB + RDS/managed DB | Середня |
| 500–5000 | Kubernetes + CloudFront + ElastiCache + Aurora | Висока |
| 5000+ | Багаторегіональний K8s + DynamoDB/Cassandra | Дуже висока |
Правило: масштабуй те, що виміряно як вузьке місце. Не масштабуй припущення.
Що входить в роботу?
Наш комплексний підхід «під ключ» включає:
- Аудит поточної архітектури та вузьких місць (1-2 дні)
- Налаштування кешування та CDN
- Оптимізація БД: індекси, конфіги, пулінг
- Контейнеризація додатка та налаштування оркестрації
- Навантажувальне тестування до та після змін
- Документація архітектури та інструкції для команди
- Навчання вашої команди роботі з новою інфраструктурою
- Підтримка після впровадження (2 тижні)
Ми також надаємо доступ до stage-середовища для тестування.
Ціни та строки
Аудит та оптимізація під навантаження (без зміни архітектури) — 1–2 тижні, вартість від 500 $. Перехід на горизонтальне масштабування — 2–6 тижнів. Вартість розраховується індивідуально після оцінки вашої системи, але економія від оптимізації зазвичай становить 30-50% від поточних витрат. Оцінимо ваш проєкт за 1 день.
Пишіть нам для отримання деталей проєкту. Наші сертифіковані інженери проаналізують вашу інфраструктуру та запропонують план. Замовте аудит інфраструктури — ми виявимо вузькі місця та розробимо план масштабування.