Ми часто стикаємося з ситуацією, коли сайт на 1С-Бітрікс починає падати під навантаженням. Всього 500 одночасних користувачів під час розпродажу — і сервер упирається в CPU або I/O. Клієнти втрачають замовлення, бізнес зазнає збитків. Горизонтальне масштабування — єдиний вихід, але воно вимагає специфічних рішень: сесії не повинні прив'язуватися до конкретної машини, кеш має бути розподіленим, файли — доступні з усіх вузлів. Наша команда має багаторічний досвід налаштування кластерів Бітрікс під високі навантаження — понад 30 успішних проектів, 7 років у розробці на цій платформі. Ми сертифіковані партнери 1С-Бітрікс та гарантуємо стабільну роботу кластера під будь-яким навантаженням.
Чому горизонтальне масштабування критичне для Бітрікс?
Один сервер фізично обмежений по CPU, RAM та I/O. Бітрікс — важка CMS: кожен хіт завантажує інфоблоки, модулі, агенти. При 1000+ одночасних користувачів стандартний сервер перестає справлятися, навіть з оптимізацією коду. Горизонтальне масштабування (кластер) розподіляє навантаження між кількома вузлами, забезпечуючи відмовостійкість та лінійне зростання продуктивності при додаванні нових серверів. Наприклад, на одному з проектів ми збільшили пропускну здатність з 300 до 5000 RPS — час відгуку скоротився з 2 секунд до 200 мілісекунд (у 10 разів).
Архітектура кластера Бітрікс
Бітрікс підтримує кластерну конфігурацію в редакції 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. У тестуванні Redis показав продуктивність у 10 разів вищу за файлові сесії.
У /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], ], ], Redis знижує час завантаження сторінки на 60% і дозволяє обробляти до 10 000 запитів на секунду.
Розподілене файлове сховище
Директорії /upload/ та /bitrix/cache/ (дисковий кеш) повинні бути спільними для всіх web-вузлів. Варіанти:
| Рішення | Коли використовувати |
|---|---|
| NFS | Прості конфігурації, один NFS-сервер |
| GlusterFS | Відмовостійкість, розподілене сховище |
| S3-сумісне (MinIO, Ceph) | Хмарний деплой, великий об'єм файлів |
| CDN + об'єктне сховище | Глобальна доставка медіа |
Для Бітрікс: модуль disk та завантаження (/upload/) монтуються на спільну FS. Кеш краще перевести на Redis і повністю відключити дисковий кеш.
Реплікація бази даних
Бітрікс підтримує роботу з кількома хостами БД через DBConnectionPool у /bitrix/.settings.php. Записи йдуть на Master, читання — на Slave. Конфігурація:
'connections' => [ 'value' => [ 'default' => [ 'host' => 'db-master', ... ], 'slave' => [ 'host' => 'db-slave-1', ... ], ], ], Кастомний код повинен явно вказувати з'єднання для читання через Application::getConnection('slave'). Реплікація зменшує час відповіді на запити читання до 5 мс та знижує навантаження на мастер-сервер на 70%.
Які вузькі місця виникають при масштабуванні?
Агенти. Стандартні агенти Бітрікс викликаються в web-потоці при кожному хіті. На кластері це означає конкурентне виконання одного агента на кількох вузлах. Рішення: винести агенти в окремий cron-процес на одному сервері, відключивши web-виклик через BX_CRONTAB. Це скорочує навантаження на web-вузли на 30%.
Генерація PDF та важкі задачі. Генерація документів, звітів, пакетні операції не повинні виконуватися в web-потоці. Потрібна черга задач — RabbitMQ або Redis Queue — з воркерами на окремих серверах.
Оновлення ядра в кластері. Rolling update без даунтайму: оновлюємо вузли по одному, за умови зворотної сумісності оновлення з поточною версією БД.
Уникайте типових помилок: не залишайте файлові сесії на локальному диску, відключайте веб-виклик агентів, використовуйте Redis замість дискового кешу, тестуйте навантаження на ідентичному продакшну staging.
Як ми налаштовуємо кластер Бітрікс за 5 кроків?
- Аудиторське обстеження: профілювання поточного навантаження, виявлення вузьких місць (CPU, RAM, I/O, запити до БД).
- Проектування архітектури: вибір балансувальника, сховища, Redis-кластера, схеми реплікації.
- Реалізація: налаштування всіх компонентів, міграція сесій та кешу, монтування shared storage.
- Навантажувальне тестування Bitrix: імітація пікового навантаження за допомогою Apache JMeter або k6 на staging-середовищі, ідентичному продакшну.
- Оптимізація та деплой: коригування конфігурацій, відключення дискового кешу, налаштування моніторингу, rolling update на бой.
| Етап | Орієнтовні терміни |
|---|---|
| Аудит | 3–5 днів |
| Проектування | 5–7 днів |
| Налаштування кластера | 10–20 днів |
| Навантажувальне тестування | 5–10 днів |
| Оптимізація | 5–10 днів |
Що входить в консультацію з масштабування?
- Аналіз поточних вузьких місць (CPU, RAM, I/O, БД)
- Проектування цільової архітектури (схема, компоненти)
- Документація з конфігурації Redis, балансувальника, реплікації БД
- Налаштування розподіленого файлового сховища (NFS, GlusterFS або S3)
- Переведення сесій та кешу на Redis
- Винесення агентів та важких задач із веб-потоку
- Методологія навантажувального тестування
- Підтримка після впровадження (2 тижні)
Терміни та вартість
Терміни впровадження кластерної архітектури становлять від 2 тижнів до 3 місяців. Вартість консультації визначається після аналізу складності проекту. Економія на інфраструктурі після масштабування може сягати 40% — наприклад, для проекту з 1000 користувачів економія становить від $500 до $2000 на місяць. Окупність інвестицій — 3-6 місяців.
У консультування з масштабування входить аналіз поточних вузьких місць, проектування цільової архітектури, рекомендації з конфігурації Redis, балансувальника та реплікації БД, налаштування розподіленого файлового сховища, переведення сесій та кешу на Redis, винесення агентів та важких задач із веб-потоку, а також методологія навантажувального тестування.
«Після масштабування наш інтернет-магазин витримує 5000 одночасних покупців — продуктивність зросла в 4 рази» — відгук клієнта.
Замовте консультацію з масштабування — наші сертифіковані інженери проаналізують ваш проект та запропонують оптимальну архітектуру під ключ. Зв'яжіться з нами для попередньої оцінки.