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