Уявіть: ваш інтернет-магазин на Бітрікс у день розпродажу лягає — сервер іде у своп, сторінки завантажуються по 30 секунд, менеджери втрачають замовлення. Навіть потужний standalone-сервер впирається у ліміти CPU та I/O при тисячах паралельних запитів. Для масштабування інтернет-магазину на Бітрікс ми часто бачимо таку картину у клієнтів, які досягають 10 000 відвідувачів на день. Єдиний порятунок — горизонтальне масштабування. Наша команда — сертифіковані інженери 1С-Бітрікс з 10-річним досвідом та гарантією якості робіт. Оптимізація Бітрікс для високих навантажень неможлива без правильної кластеризації. Ми розглянемо горизонтальне масштабування 1С-Бітрікс, яке офіційно підтримується починаючи з редакції «Малий бізнес». Для Бітрікс це не просто кнопка «кластеризувати» — потрібно вирішити три ключові проблеми: сесії, кеш та файлове сховище. Наш досвід 10 років у Бітрікс-розробці та понад 100 проєктів з масштабування показує: без правильної архітектури ви витратите тижні на налагодження, а результат не дасть приросту продуктивності. Кластеризація Бітрікс24 також підтримується, але потребує окремого ліцензування.
Три вузьких місця, які потрібно усунути
| Проблема | Суть | Рішення |
|---|---|---|
| Сесії | PHP-сесії зберігаються на диску. Різні вузли втрачають сесію користувача. | Перенесення сесій до Redis (або Memcached). Redis працює в 3 рази швидше за Memcached для операцій читання/запису сесій. |
| Файли | Завантажені файли та кеш унікальні для кожного вузла. | Спільне сховище (NFS, GlusterFS або S3) для upload/ та каталогів кешу. |
| Кеш Бітрікс | Керований кеш у файлах — при скиданні на одному вузлі інші віддають застарілі дані. | Використовувати Redis для кешу (крім HTML-кешу — він краще на NFS). |
Як налаштувати сесії в Redis для Бітрікс?
Бітрікс підтримує зберігання сесій у Redis нативно. Налаштування в /bitrix/.settings.php:
'session' => [ 'value' => [ 'mode' => 'default', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => '127.0.0.1', 'port' => 6379, 'serializer' => \Redis::SERIALIZER_PHP, ], ], ], ], Для високої доступності використовуємо Redis Sentinel — тоді при відмові майстра сесії не втрачаються. Налаштування аналогічне, тільки вказуємо sentinels та master_name. Важливо встановити PHP-розширення redis. Ми віддаємо перевагу Redis, а не Memcached, через атомарність операцій та вбудовану персистентність. В одному проєкті сесії в Redis врятували від втрати 20 000 корзин під час перемикання балансувальника. Redis гарантує атомарність операцій, що критично для консистентності даних у кластері.
Перенесення кешу Бітрікс у Redis
Керований кеш (/bitrix/cache/ та /bitrix/managed_cache/) краще зберігати в Redis. Це пришвидшує читання та усуває розсинхронізацію між вузлами.
'cache' => [ 'value' => [ 'type' => 'redis', 'redis' => [ 'host' => '127.0.0.1', 'port' => 6379, 'serializer' => \Redis::SERIALIZER_IGBINARY, ], ], ], Розширення igbinary стискає дані на ~40% швидше за PHP-серіалізацію. Для кешу HTML-сторінок (наприклад, bitrix:page.polycore) Redis неефективний через розмір об'єктів — такі сторінки кешуємо на рівні nginx proxy_cache або залишаємо на NFS.
Чому важлива реплікація MySQL?
При кількох веб-вузлах навантаження на базу даних зростає пропорційно. Один майстер не справляється з SELECT-запитами. Рішення — Master-Slave реплікація з розділенням запитів. Налаштування в /bitrix/.settings.php:
'connections' => [ 'value' => [ 'default' => [ 'className' => '\\Bitrix\\Main\\DB\\MysqlConnection', 'host' => 'mysql-master', 'database' => 'bitrix', 'login' => 'bitrix', 'password' => 'secret', ], 'slave' => [ 'className' => '\\Bitrix\\Main\\DB\\MysqlConnection', 'host' => 'mysql-slave', 'database' => 'bitrix', 'login' => 'bitrix_ro', 'password' => 'secret_ro', ], ], ], Для прозорого роутингу запитів використовуємо ProxySQL або кастомний Connection Resolver. Це знижує навантаження на майстер і збільшує пропускну здатність.
Вибір файлового сховища
| Критерій | NFS | GlusterFS | S3 (MinIO) |
|---|---|---|---|
| Простота налаштування | +++ | + | ++ |
| Відмовостійкість | - | ++ | +++ |
| Продуктивність | ++ | ++ | + |
| Блокування файлів | + | + | - |
NFS — простий варіант для 2–3 вузлів: швидко монтується і дає низьку затримку (low latency), але є єдиною точкою відмови без реплікації. GlusterFS складніше налаштувати, зате реплікує дані між вузлами і виключає SPOF, а також запобігає split-brain завдяки механізму quorum. S3-сумісні сховища (наприклад, MinIO) еластичні та не потребують фізичних серверів, але latency вища, і потрібен модуль Bitrix\Main\File\Remote\S3. Для продакшну ми частіше використовуємо GlusterFS — він уже врятував не один проєкт від даунтайму. Приклад монтування NFS:
mount -t nfs nfs-server:/srv/bitrix-shared /var/www/bitrix/upload Конфігурація балансувальника навантаження
Приклад конфігурації nginx з least_conn і health-check
upstream bitrix_backend { least_conn; server web-node-1:80 weight=1 max_fails=3 fail_timeout=30s; server web-node-2:80 weight=1 max_fails=3 fail_timeout=30s; server web-node-3:80 weight=1 max_fails=3 fail_timeout=30s; keepalive 32; } server { listen 443 ssl; location / { proxy_pass http://bitrix_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 5s; proxy_read_timeout 60s; } } При правильному налаштуванні сесій у Redis sticky sessions не потрібні — будь-який вузол відповідає на будь-який запит. Виняток: завантаження файлів чанками; для нього можна ввімкнути sticky по IP або використовувати окремий upload-ендпоінт.
Процес роботи
- Аудит — аналізуємо поточну архітектуру, навантаження, вузькі місця.
- Проектування — обираємо схему: Redis, сховище, балансувальник, реплікацію.
- Налаштування Redis — сесії та кеш, тестування відмовостійкості.
- Налаштування файлового сховища — NFS або GlusterFS, синхронізація codebase (git/rsync/Ansible).
- Конфігурація балансувальника — nginx upstream, health-check, SSL termination.
- Реплікація MySQL — Master-Slave + ProxySQL.
- Тестування — навантажувальні тести, перевірка при відключенні вузла.
- Документація та навчання — передача схеми та інструкцій.
Що входить у роботу
- Архітектурна схема кластера та конфігураційні файли.
- Налаштований Redis (сесії + кеш) з резервуванням через Sentinel.
- Спільне файлове сховище (NFS або GlusterFS) з автоматичним монтуванням.
- Балансувальник nginx з health-check та SSL termination.
- Реплікація MySQL з ProxySQL для розподілу запитів.
- Навантажувальне тестування та звіт з продуктивності.
- Документація з експлуатації та схема відновлення після збоїв.
- Навчання вашої команди базовим операціям.
- Пост-продакшн підтримка протягом місяця.
Терміни та вартість
Базова настройка (2 вузли, Redis, NFS, балансування) займає 2–3 тижні і коштує від 25 000 грн. Продакшн-схема з GlusterFS, Redis Sentinel, моніторингом та автоматизацією — 4–6 тижнів та від 60 000 грн. Економія на відмові від дорогого апгрейду сервера може сягати 60%. Наприклад, замість апгрейду сервера за 100 000 грн, ви отримаєте кластер, що обробляє в 5 разів більше запитів. Зниження витрат на серверну інфраструктуру до 40% порівняно з монолітним рішенням. Замовте аудит вашого проєкту — наші інженери оцінять можливість масштабування за 2 дні. Отримайте консультацію з вибору оптимальної схеми кластеризації.