Настройка автомасштабирования в облаке для 1С-Битрикс

Настройка автомасштабирования в облаке для 1С-Битрикс

Автомасштабирование отличается от горизонтального масштабирования тем, что количество узлов меняется автоматически — растёт под нагрузку, сокращается в простое. Для 1С-Битрикс это актуально для проектов с неравномерной нагрузкой: интернет-магазины в сезон распродаж, мероприятийные порталы, B2B-площадки с дневными пиками. Держать 10 серверов ради пика в 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: ВМ добавляется в балансировщик
          → Трафик распределяется на новый узел

Требования к образу (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-20240315 \
    --source-disk bitrix-golden \
    --description "Битрикс 1C-Bitrix app node, PHP 8.1, March 2024"

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),
            ],
        ],
    ],
];

Настройка группы ВМ в Яндекс 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 при каждом деплое неудобно. Два подхода:

Подход 1: Code on NFS — код приложения тоже лежит на NFS. Деплой = обновление файлов на NFS-сервере. Все ноды автоматически видят изменения. Минус: NFS — единая точка отказа для кода.

Подход 2: Pull on start — в cloud-init добавляем шаг получения кода из git или артефакта:

# В cloud-init: получаем нужный тег из S3
aws s3 cp s3://bitrix-deploys/release-$(cat /etc/bitrix-release).tar.gz /tmp/
tar -xzf /tmp/release-*.tar.gz -C /var/www/html/

Переменная окружения RELEASE_TAG передаётся в метаданные ВМ при создании группы, cloud-init читает её и скачивает нужный артефакт.

Подготовка Битрикс к автоскейлингу: чеклист

• Сессии → 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-ноду.

Мониторинг и алерты

Метрики для политик автоскейлинга:

Состав работ

• Аудит архитектуры, подготовка Битрикс к stateless-режиму
• Настройка Redis HA (Sentinel или Cluster) для сессий и кеша
• Настройка NFS/GlusterFS или S3 для файлов
• Сборка golden image, cloud-init скрипты
• Terraform/Pulumi конфигурация Instance Group с политиками масштабирования
• Настройка Application Load Balancer, health-checks
• Решение проблемы cron/агентов в кластере
• Нагрузочное тестирование: проверка сценария scale-out/scale-in

Сроки: базовый автоскейлинг с двумя нодами — 3–4 недели. Продакшн-готовая схема с IaC, мониторингом и runbook — 6–10 недель.