Настройка масштабирования 1С-Битрикс

Настройка масштабирования 1С-Битрикс

«Нам нужно масштабирование» — запрос, который чаще всего означает одно из трёх: сайт тормозит при пиковых нагрузках, планируется кратный рост трафика, или требуется отказоустойчивость. Это разные задачи с разными решениями. Горизонтальное масштабирование Битрикс — не установка ещё одного сервера, а перестройка архитектуры с разделением ответственности компонентов.

Декомпозиция: что масштабируется отдельно

Начинаем с компонента, который является узким местом — а не с того, что «кажется правильным». Часто оказывается, что MySQL справляется, а тормоз в PHP-коде.

Вертикальное vs горизонтальное

Вертикальное (больше CPU/RAM) — быстро, не требует изменений в коде, но имеет потолок и стоимость. До 32 ГБ RAM на DB-сервере вертикальное масштабирование часто выгоднее горизонтального.

Горизонтальное — сложнее (нужна stateless архитектура, shared storage, координация кэша), но нет ограничения сверху и обеспечивает отказоустойчивость.

Подготовка кода к горизонтальному масштабированию

Основные проблемы, которые нужно устранить до добавления нод:

Файловый кэш Битрикс. По умолчанию кэш хранится в /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 (см. статью по настройке кластера).

Масштабирование через 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 отдаёт их с ближайшего узла к пользователю.

Масштабирование импорта из 1С

Импорт больших каталогов (100 000+ SKU) — ресурсоёмкая задача, которую нельзя выполнять на production-нодах. Выделяем отдельную ноду-воркер:

[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_instances: 2
- max_instances: 10
- scale_up: CPU > 70% за 3 минуты
- scale_down: CPU < 30% за 10 минут
- cooldown: 300s

Требования: образ сервера с предустановленным Битрикс, конфиг подтягивается из хранилища при старте инстанса, Application Load Balancer автоматически регистрирует новые ноды.

Бюджет масштабирования

Реалистичные цифры для планирования:

• 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-инфраструктуру)