Консультування з масштабування проєкту 1С-Бітрікс
Сайт починає падати під навантаженням — 500 одночасних користувачів, розпродаж, «чорна п'ятниця». Один сервер впирається в CPU або I/O. Горизонтальне масштабування Бітрікс можливе, але потребує специфічних рішень: сесії не повинні прив'язуватися до конкретної машини, кеш має бути спільним, завантажені файли — доступними з усіх вузлів.
Архітектура кластера Бітрікс
Бітрікс підтримує кластерну конфігурацію в редакції Business і вище («Масштабування»). Компоненти типової кластерної схеми:
[Балансувальник: nginx / HAProxy]
|
+---------+
| |
[Web-1] [Web-2] ... [Web-N] — PHP-FPM
| |
+---------+
|
[Shared storage: GlusterFS / NFS / S3] — /upload/, /bitrix/cache/
|
[Redis cluster] — сесії, керований кеш
|
[MySQL / PostgreSQL Master] → [Slave-1] [Slave-2]
Сесії та кеш
Сесії. Стандартний PHP зберігає сесії у файлах на локальному диску — при кількох серверах користувач втрачає авторизацію при потраплянні на інший вузол. Рішення: перенести сесії до Redis.
У /bitrix/.settings.php:
'session' => [
'value' => [
'mode' => 'default',
'handlers' => [
'general' => [
'type' => 'redis',
'host' => '127.0.0.1',
'port' => '6379',
],
],
],
],
Керований кеш Бітрікс (ManagedCache) також переводиться на Redis:
'cache' => [
'value' => [
'type' => 'redis',
'redis' => ['host' => 'redis-host', 'port' => 6379],
],
],
Спільне файлове сховище
Директорії /upload/ та /bitrix/cache/ (дисковий кеш) мають бути спільними для всіх web-вузлів. Варіанти:
| Рішення | Коли використовувати |
|---|---|
| NFS | Прості конфігурації, один NFS-сервер |
| GlusterFS | Відмовостійкість, розподілене сховище |
| S3-сумісне (MinIO, Ceph) | Хмарний деплой, великий обсяг файлів |
| CDN + об'єктне сховище | Глобальна доставка медіа |
Для Бітрікс: модуль disk та завантаження (/upload/) монтуються на спільну файлову систему. Кеш краще перенести на Redis і повністю вимкнути дисковий кеш.
Реплікація бази даних
Бітрікс підтримує роботу з кількома хостами БД через DBConnectionPool у /bitrix/.settings.php. Записи йдуть на Master, читання — на Slave. Конфігурація:
'connections' => [
'value' => [
'default' => [
'host' => 'db-master',
...
],
'slave' => [
'host' => 'db-slave-1',
...
],
],
],
Кастомний код має явно вказувати з'єднання для читання через Application::getConnection('slave').
Вузькі місця при масштабуванні
Агенти. Стандартні агенти Бітрікс викликаються у web-потоці при кожному хіті. У кластері це означає конкурентне виконання одного агента на кількох вузлах. Рішення: винести агенти в окремий cron-процес на одному сервері, вимкнувши web-виклик через BX_CRONTAB.
Генерація PDF і важкі задачі. Генерація документів, звітів, пакетні операції не повинні виконуватися у web-потоці. Потрібна черга задач — RabbitMQ або Redis Queue — з воркерами на окремих серверах.
Оновлення ядра в кластері. Rolling update без даунтайму: оновлюємо вузли по одному, за умови зворотної сумісності оновлення з поточною версією БД.
Навантажувальне тестування
Перед масштабуванням — навантажувальне тестування на staging-середовищі, ідентичному продакшну. Інструменти: Apache JMeter, k6, Yandex.Tank. Тестуємо:
- Сторінку каталогу з фільтром
- Оформлення замовлення (транзакції в БД)
- AJAX-запити (кошик, фільтр)
Результат: крива деградації продуктивності в міру зростання навантаження, bottleneck — CPU, RAM, I/O або БД.
Що входить до консультування з масштабування
- Аналіз поточних вузьких місць під навантаженням (профілювання, моніторинг)
- Проєктування цільової кластерної архітектури
- Рекомендації з конфігурації Redis, балансувальника, реплікації БД
- Налаштування спільного файлового сховища
- Перенесення сесій і кешу Бітрікс на Redis
- Винесення агентів і важких задач із web-потоку
- Методологія навантажувального тестування та оцінка результату