Настройка автомасштабирования в облаке для 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 недель.