Налаштування автомасштабування у хмарі для 1С-Бітрікс

Налаштування автомасштабування в хмарі для 1С-Бітрікс

Автомасштабування відрізняється від горизонтального масштабування тим, що кількість вузлів змінюється автоматично — зростає під навантаження, скорочується в простої. Для 1С-Бітрікс це актуально для проектів із нерівномірним навантаженням: інтернет-магазини в сезон розпродажів, подієві портали, B2B-майданчики з денними піками. Тримати 10 серверів заради піку о 15:00 нераціонально — автоскейлінг дозволяє платити лише за фактично використані ресурси.

Хмарні платформи: Яндекс 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 тижні. Production-готова схема з IaC, моніторингом і runbook — 6–10 тижнів.