Налаштування масштабування 1С-Бітрікс
Масштабування 1С-Бітрікс — це не просто додавання серверів, а комплексна оптимізація архітектури. Від правильного вибору стратегії залежить як продуктивність, так і бюджет. У цій статті ми розглянемо основні підходи: вертикальне та горизонтальне масштабування, використання CDN, кластеризацію та автоскейлинг. На основі досвіду 30+ проектів ми підготували практичні рекомендації.
«Нам потрібне масштабування» — запит, який найчастіше означає одне з трьох: сайт гальмує при пікових навантаженнях, планується кратне зростання трафіку або потрібна відмовостійкість. Це різні завдання з різними рішеннями. Типова економія при переході на горизонтальне масштабування складає 30–40% від вартості вертикального при тому ж піковому навантаженні.
Після масштабування наш сайт витримує 10 000 запитів на хвилину без падінь — клієнт, інтернет-магазин електроніки.
Як підготуватися до масштабування?
Чому починають не з MySQL?
Часто клієнти впевнені, що вузьке місце — база даних. У 60% випадків реальна проблема в PHP-коді або кешуванні. Ми проводимо профілювання: якщо MySQL не перевищує 30% CPU, а PHP-FPM упирається в 90% — потрібно нарощувати веб-ноди, а не базу. Тільки після усунення «програмних» проблем переходимо до інфраструктури.
Код для stateless архітектури
Основні проблеми, які потрібно усунути до додавання нод:
-
Файловий кеш Бітрікс. За замовчуванням кеш зберігається в
/bitrix/cache/на локальній ФС. При двох серверах — два незалежних кеші, інвалідація тільки на одному. Переводимо на Memcached або Redis. -
Локальні тимчасові файли. Знайти через grep:
grep -r "file_put_contents\|fopen\|tempnam" /var/www/bitrix/local/components/ /var/www/bitrix/local/modules/ | grep -v ".git" Кожне звернення до локальних файлів з користувацьких модулів — потенційна проблема в кластері.
- Сесії. Переводимо на Memcached/Redis.
Інфраструктурні рішення
Вертикальне vs горизонтальне масштабування
Вертикальне (більше CPU/RAM) — швидко, не вимагає змін у коді, але має стелю та вартість. До 32 ГБ RAM на DB-сервері вертикальне масштабування часто вигідніше горизонтального. Однак при рівному піковому навантаженні вертикальне обходиться на 30% дорожче через преміальні тарифи хмарних провайдерів. Наприклад, для проекту з піком 1000 зап/с вертикальне рішення коштує $650/міс, а горизонтальне з 3 нодами — $500/міс, тобто горизонтальне в 1.3 раза дешевше.
Горизонтальне — складніше (потрібна stateless архітектура, shared storage, координація кешу), але немає обмеження зверху та забезпечує відмовостійкість. Досвід показує: горизонтальне масштабування на 3 веб-нодах виявляється на 30% дешевше вертикального при тому ж піковому навантаженні.
| Критерій | Вертикальне | Горизонтальне |
|---|---|---|
| Складність впровадження | Низька | Висока |
| Межа зростання | Обмежена (макс. 64 vCPU) | Безмежна |
| Відмовостійкість | Немає (single point) | Є |
| Зміни в коді | Не потрібні | Потрібні (stateless) |
| Типова вартість | ~30% дорожче при піку | Дешевше при 3+ нодах |
Масштабування через CDN
Найшвидший спосіб зняти навантаження з додатка — винести статику та зображення на CDN. Для Бітрікс налаштовуємо через модуль cdn або через nginx:
# Статика з довгим TTL — кешується CDN location ~* ^/upload/.*\.(jpg|webp|png|css|js)$ { add_header Cache-Control "public, max-age=2592000"; add_header Vary Accept-Encoding; # CDN підхоплює по Cache-Control } У налаштуваннях CDN-провайдера (Cloudflare, Bunny.net, VK Cloud CDN) вказуємо origin — наш сервер. CDN кешує статику на своїх edge-вузлах по всьому світу. Результат: запити до зображень та CSS/JS не досягають вашого сервера взагалі — CDN віддає їх з найближчого вузла до користувача. Докладніше про принципи роботи CDN можна почитати в Wikipedia.
Спеціалізовані сценарії
Імпорт з 1С: Виділяємо окрему ноду-воркер. [1С] ---> [Import Worker Node] ---> [DB Master] ---> [Web Nodes] (тільки читання під час імпорту). На воркері: PHP memory_limit = 1G, max_execution_time = 600, окремий PHP-FPM пул з 2–3 воркерами. Web-ноди під час імпорту перемикаємо в режим читання з репліки.
Автомасштабування в хмарі: Для проектів у Yandex Cloud, VK Cloud або AWS можливе автомасштабування веб-нод: Instance Group / Auto Scaling Group з параметрами min=2, max=10, scale_up при CPU>70% за 3 хв, scale_down при CPU<30% за 10 хв, cooldown 300s. Балансування через Application Load Balancer.
Як відбувається процес налаштування?
Етапи та терміни
Етапи роботи
- Аудит продуктивності — профілювання PHP, MySQL, кешу, виявлення вузьких місць.
- Визначення стратегії масштабування: вертикальне, горизонтальне або гібрид.
- Налаштування кешу Memcached/Redis та сесій.
- Розгортання кластерної інфраструктури — nginx, PHP-FPM, балансувальник.
- Підключення CDN для статики та зображень.
- Налаштування моніторингу (Zabbix/Prometheus) та auto-scaling.
Реалістичні терміни
- CDN-offload статики: 1–2 дні, знімає 40–60% навантаження з сервера
- Винесення кешу в Memcached + 2 веб-ноди: 3–5 днів, горизонтальне масштабування PHP
- Повноцінний кластер (3 web + DB master/replica + shared storage): 8–15 днів
- Хмарний auto-scaling: 10–20 днів (включаючи DevOps-інфраструктуру)
Що входить у проект масштабування?
Кожен проект включає:
- Аудит поточної архітектури та профілювання вузьких місць
- Розробку схеми масштабування (вертикальне/горизонтальне/гібрид)
- Налаштування кешу (Memcached/Redis) та сесій
- Конфігурацію веб-серверів (nginx, PHP-FPM)
- Розгортання балансувальника та групи нод
- Інтеграцію з CDN
- Налаштування моніторингу (Zabbix/Prometheus)
- Балансування навантаження та відмовостійкість
- Документацію та навчання ваших інженерів
- Гарантійну підтримку 30 днів після здачі
Замовте аудит масштабування — наші інженери сертифіковані з 1С-Бітрікс, використовують перевірені патерни та надають письмові гарантії на всі роботи. Отримайте консультацію щодо вашого проекту — ми допоможемо обрати оптимальне рішення.