Налаштування автомасштабування в хмарі для 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 тижнів.