Налаштування автомасштабування в хмарі для 1С-Бітрікс
Ми часто бачимо проєкти, де сайт на Бітрікс лягає під час акції. Сервер не витримує — адміни вручну піднімають копії. Автомасштабування вирішує цю проблему: кількість вузлів змінюється автоматично. Зростає під навантаження і скорочується в простої. Для 1С-Бітрікс це особливо актуально для інтернет-магазинів у сезон розпродажів, подієвих порталів та B2B-майданчиків із денними піками. Тримати 10 серверів заради піку о 3 годині дня нераціонально. Автоскейлінг дозволяє платити лише за фактично використані ресурси. Наш досвід показує, що грамотне налаштування скорочує витрати на інфраструктуру в 2–3 рази при збереженні відмовостійкості.
Хмарні платформи: Яндекс Cloud та VK Cloud
У російському сегменті основні платформи — Яндекс Cloud (Instance Groups) та VK Cloud (Auto Scaling Groups). Архітектура ідентична AWS Auto Scaling: групи віртуальних машин з політиками масштабування на основі метрик (CPU, RPS, memory). Принцип роботи:
- Metric Alert (CPU > 70% за 5 хвилин)
- Scale-out trigger
- Створюється нова ВМ із golden image
- Cloud-init: встановлення nginx + php-fpm, монтування NFS
- Health check: ВМ додається до балансувальника
- Трафік розподіляється на новий вузол
| Параметр | Яндекс Cloud | VK Cloud |
|---|---|---|
| Інтеграція з Terraform | Підтримка офіційного провайдера | Обмежена підтримка |
| Managed Kubernetes | Є (з автоматичним масштабуванням) | Є (з ручним конфігуруванням) |
| Техпідтримка | Стандартна платна | Включена в тариф |
Обидві платформи забезпечують відмовостійкість, але налаштування golden image та cloud-init ідентичне. Golden image — стандартний патерн для stateless-архітектури. Офіційна документація по Terraform допоможе розібратися з провайдерами.
Чому golden image — основа автоскейлінгу?
Автоскейлінг працює тільки якщо нова ВМ готова приймати трафік без ручного втручання. Образ повинен містити:
- nginx, php-fpm потрібної версії з розширеннями для Бітрікс
- PHP-код додатку (або механізм його швидкої доставки)
- Скрипт монтування спільного сховища (
/upload/, кеш) - Скрипт підключення до Redis для сесій
- Конфігурацію Бітрікс з правильними параметрами БД та Redis
Створення golden image в Яндекс Cloud:
# Запускаємо базову ВМ, налаштовуємо вручну # Після налаштування створюємо знімок диска yc compute disk create --snapshot-id <snapshot-id> --name bitrix-golden # Створюємо образ зі знімка yc compute image create \ --name bitrix-app-v1 \ --source-disk bitrix-golden \ --description "Бітрікс 1C-Bitrix app node, PHP 8.1" Cloud-init: автоматичне налаштування при старті ВМ
Приклад конфігурації cloud-init
Cloud-init виконується при першому старті ВМ. У нього виносимо все, що залежить від конкретного оточення:
# /etc/cloud/cloud.d/bitrix-init.yaml #cloud-config runcmd: # Монтуємо спільний том NFS - echo "nfs-server:/srv/bitrix-shared /var/www/html/upload nfs rw,sync,hard,intr 0 0" >> /etc/fstab - mount -a # Реєструємо ноду в consul для service discovery - | curl -X PUT http://consul:8500/v1/agent/service/register \ -d '{"name":"bitrix-web","address":"'$(hostname -I | awk '{print $1}')'"}' # Прогріваємо кеш PHP OPcache - php /var/www/html/bitrix/cli/health.php --warmup # Стартуємо сервіси - systemctl start nginx php8.1-fpm - systemctl enable nginx php8.1-fpm Конфігурація Бітрікс через змінні оточення (не хардкодимо в образі):
// /bitrix/.settings.php — читає з environment return [ 'connections' => [ 'value' => [ 'default' => [ 'className' => '\\Bitrix\\Main\\DB\\MysqlConnection', 'host' => getenv('DB_HOST') ?: 'mysql-master', 'database' => getenv('DB_NAME') ?: 'bitrix', 'login' => getenv('DB_USER') ?: 'bitrix', 'password' => getenv('DB_PASS') ?: '', ], ], ], 'cache' => [ 'value' => [ 'type' => 'redis', 'redis' => [ 'host' => getenv('REDIS_HOST') ?: 'redis-master', 'port' => (int)(getenv('REDIS_PORT') ?: 6379), ], ], ], ]; Для зберігання сесій використовуємо Redis. Це в 10 разів швидше за файлове зберігання.
Налаштування групи ВМ в Яндекс Cloud (terraform)
resource "yandex_compute_instance_group" "bitrix_web" { name = "bitrix-web-asg" service_account_id = var.service_account_id instance_template { platform_id = "standard-v3" resources { cores = 4 memory = 8 } boot_disk { initialize_params { image_id = var.bitrix_golden_image_id size = 50 } } network_interface { subnet_ids = var.subnet_ids } metadata = { user-data = file("cloud-init.yaml") } } scale_policy { auto_scale { initial_size = 2 min_zone_size = 1 max_size = 10 measurement_duration = 60 # секунди warmup_duration = 120 # прогрів нової ВМ cpu_utilization_rule { utilization_target = 70 # % } } } deploy_policy { max_unavailable = 1 max_expansion = 2 } load_balancer { target_group_name = "bitrix-target-group" } } Як деплоїти код без перескладання образу?
Перескладати golden image при кожному деплої незручно. Використовуємо підхід Pull on start: у cloud-init додаємо крок отримання коду з артефакту. Змінна оточення RELEASE_TAG передається в метадані ВМ при створенні групи, cloud-init читає її та завантажує потрібний архів з S3. Деплой зводиться до зміни тега в метаданих — всі нові ноди стартують з актуальним кодом.
Ось покрокова інструкція по деплою:
- Зібрати артефакт з кодом додатку та завантажити в S3.
- Оновити метадані групи ВМ: вказати новий тег.
- Запустити rolling update групи: ноди по черзі перестворюються з новим тегом.
- Перевірити, що всі ноди працюють з новим кодом.
Як підготувати Бітрікс до stateless-архітектури: чеклист
- Сесії → Redis (не файли)
- Кеш → Redis або NFS (не локальний диск)
- Файли
/upload/→ NFS або S3 - Тимчасові файли, черги → Redis або БД, не
/tmp/ - Cron-завдання → запускаються тільки на одній designated ноді (не на всіх)
- Бітрікс агенти → переключити на cron-режим (
BX_CRONTAB=Y) та запускати з designated ноди -
REMOTE_ADDR→ коректна передача черезX-Forwarded-Forвід балансувальника
Критичний момент з cron: якщо агенти Бітрікс запустяться на всіх нодах одночасно — будуть дублі. У bitrix/.settings.php параметр bx_crontab_nodes або обмеження через iptables на cron-ноду.
Моніторинг та алерти
Метрики для політик автоскейлінгу:
| Метрика | Threshold scale-out | Threshold scale-in |
|---|---|---|
| CPU середнє по групі | > 70% за 3 хв | < 30% за 10 хв |
| Середній час відповіді (p95) | > 2000 ms | < 500 ms |
| Черга запитів nginx | > 100 | < 10 |
| RPS | > 500 на ноду | < 100 на ноду |
Що ви отримуєте
- Документацію по архітектурі з описом всіх компонентів
- Доступи до інфраструктури та IaC-коду (Terraform)
- Інструкції по деплою та оновленню
- Навчання вашої команди (2-годинний воркшоп)
- Супровід протягом місяця після введення в експлуатацію
- Повна автоматизація: від створення ВМ до моніторингу
Замовте аудит вашої інфраструктури — ми оцінимо поточну архітектуру та запропонуємо план міграції. Отримайте консультацію інженера, щоб обговорити деталі вашого проєкту.
Кейс: замовник з піковим навантаженням 10 000 RPS у годину пік. Після впровадження автоскейлінгу downtime знизився з 15 хвилин до нуля. Вартість інфраструктури скоротилася на 40% за рахунок відключення зайвих нод у простої. Досвід нашої команди — понад 50 успішних проєктів на Бітрікс, 10+ років у розробці.
Терміни: базовий автоскейлінг з двома нодами — 3–4 тижні. Продакшн-готова схема з IaC, моніторингом та runbook — 6–10 тижнів.