Налаштування масштабування 1С-Бітрікс

Налаштування масштабування 1С-Бітрікс

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

Декомпозиція: що масштабується окремо

Починаємо з компонента, який є вузьким місцем — а не з того, що «здається правильним». Часто виявляється, що MySQL справляється, а гальмо в PHP-коді.

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

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

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

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

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

Файловий кеш 1С-Бітрікс. За замовчуванням кеш зберігається в /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. Для 1С-Бітрікс налаштовуємо через модуль 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

Вимоги: образ сервера з передвстановленим 1С-Бітрікс, конфіг підтягується зі сховища при старті інстанса, 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-інфраструктуру)