Настройка Managed Instance Groups и автоскейлинга в GCP

Настройка автоматического масштабирования (Managed Instance Groups) GCP

Вы запускаете сервис на GCP на десятке виртуальных машин. Пики нагрузки заставляют держать резервные мощности, а ручное создание инстансов отнимает часы. Managed Instance Groups (MIG) решают эту проблему: пул идентичных ВМ, которые GCP автоматически создает, пересоздает при сбоях и масштабирует по метрикам. Мы используем MIG в 80% проектов вместо Kubernetes, когда оверхед кластера не оправдан. Наш опыт — более 50 продакшен-схем, экономия бюджета до 40% по сравнению с ручным управлением. Согласно документации Managed Instance Groups, MIG поддерживает автоскейлинг по CPU, нагрузке балансировщика и пользовательским метрикам, что позволяет точно подстраивать количество инстансов под реальную нагрузку без переплаты. Такой подход особенно эффективен для stateless-приложений с неравномерной нагрузкой, например, обработчиков изображений или веб-серверов под Cloud Load Balancer. В этой статье я разберу, как настроить MIG с автоскейлингом на основе CPU и Pub/Sub, обеспечить auto-healing и выполнить rolling update без простоев. Также рассмотрим stateful MIG для воркеров с локальными данными.

Instance Template — основа всего

MIG не работает без Instance Template. Это снимок конфигурации ВМ: машинный тип, образ диска, сеть, сервис-аккаунт, startup script. Ниже типовой шаблон на Terraform:

resource "google_compute_instance_template" "app" {
  name_prefix = "app-template-"
  machine_type = "n2-standard-4"

  disk {
    source_image = "projects/debian-cloud/global/images/family/debian-12"
    auto_delete  = true
    boot         = true
    disk_size_gb = 50
    disk_type    = "pd-ssd"
  }

  network_interface {
    network    = google_compute_network.main.id
    subnetwork = google_compute_subnetwork.app.id
  }

  service_account {
    email  = google_compute_service_account.app.email
    scopes = ["cloud-platform"]
  }

  metadata = {
    startup-script = file("scripts/startup.sh")
  }

  lifecycle {
    create_before_destroy = true
  }
}

create_before_destroy = true обязателен — при обновлении шаблона Terraform сначала создаёт новый, потом удаляет старый, иначе MIG ненадолго остаётся без шаблона.

Как настроить автоскейлинг для Pub/Sub воркеров?

Если ваш воркер обрабатывает сообщения из Pub/Sub, используйте autoscaler с метрикой pubsub.googleapis.com/subscription/num_undelivered_messages. Пример конфигурации:

resource "google_compute_region_instance_group_manager" "app" {
  name = "app-mig"
  region = "us-central1"
  base_instance_name = "app"
  version {
    instance_template = google_compute_instance_template.app.id
  }
  target_size = 2
  auto_healing_policies {
    health_check = google_compute_health_check.app.id
    initial_delay_sec = 120
  }
  update_policy {
    type = "PROACTIVE"
    minimal_action = "REPLACE"
    max_surge_fixed = 3
    max_unavailable_fixed = 0
    replacement_method = "SUBSTITUTE"
  }
}

resource "google_compute_region_autoscaler" "app" {
  name = "app-autoscaler"
  region = "us-central1"
  target = google_compute_region_instance_group_manager.app.id
  autoscaling_policy {
    min_replicas = 2
    max_replicas = 20
    cooldown_period = 90
    cpu_utilization {
      target = 0.65
    }
    metric {
      name = "pubsub.googleapis.com/subscription/num_undelivered_messages"
      target = 100
      type = "GAUGE"
    }
  }
}

Какие метрики автоскейлинга поддерживает MIG?

Почему стоит выбрать MIG вместо Kubernetes?

Сравним два подхода:

Для stateless-воркеров, рендеринга, ML-инференса и традиционных веб-приложений MIG выигрывает по простоте и стоимости в 2–3 раза.

Какие подводные камни встречаются?

• initial_delay_sec слишком мал. Приложение стартует 90 секунд, health check настроен с delay 30s — MIG начинает заменять «нездоровые» инстансы до того, как они успели запуститься. Получаем бесконечный цикл замены. Правило: initial_delay_sec должен быть с запасом 1.5x от реального времени старта.
• Canary update через версии. MIG поддерживает два template одновременно — удобный canary без Kubernetes. Катим на 2 из 10 инстансов, смотрим метрики, расширяем.
• Stateful MIG для воркеров с локальным диском. Если воркеру нужен persistent диск, который сохраняется при пересоздании, обязательно укажите delete_rule = "NEVER". Иначе диск удаляется вместе с инстансом при авто-хилинге.

Когда stateful MIG предпочтительнее stateless?

Stateful MIG сохраняет persistent диски при пересоздании инстансов. Это нужно для воркеров с локальными данными, например, кэширующих сервисов или баз данных. Укажите stateful_disk с delete_rule = "NEVER" в конфигурации Terraform.

stateful_disk { device_name = "data-disk" delete_rule = "NEVER" } 

Без этого правила диск удаляется вместе с инстансом при авто-хилинге — получите потерю данных.

Интеграция с Load Balancer

MIG подключается к Backend Service балансировщика через named port:

resource "google_compute_region_instance_group_manager" "app" {
  # ...
  named_port {
    name = "http"
    port = 8080
  }
}

Health check для LB и для auto-healing могут быть разными — LB-check смотрит на /ready, auto-healing check — на /live. Это важно для корректного graceful shutdown.

Что входит в настройку MIG под ключ

• Аудит текущей схемы деплоя и мониторинга
• Проектирование: regional vs zonal MIG, политика обновлений, метрики автоскейлинга
• Реализация в Terraform с использованием модулей
• Настройка health checks и auto-healing
• Тестирование rolling update и canary-деплоя на staging
• Подключение Cloud Monitoring и алертов
• Передача документации и ролей RBAC
• Обучение вашей команды (1 час)

Мы гарантируем стабильную работу схемы: если что-то пошло не так — бесплатно исправляем в течение 2 недель после внедрения. Наши инженеры имеют сертификацию GCP и опыт более 50 успешных проектов. Для правильной настройки MIG обратитесь к нам за консультацией.

Процесс работы

1. Аналитика — разбираем текущую инфраструктуру, нагрузку, бюджет
2. Проектирование — выбираем тип MIG, метрики, политику обновлений
3. Реализация — пишем Terraform-конфиги, тестируем на staging
4. Тест — проверяем auto-scaling, rolling update, health checks
5. Деплой — применяем в production, настраиваем мониторинг

Срок: 2–3 дня для стандартной схемы. Больше — если нужна stateful конфигурация или интеграция с существующим LB.

Свяжитесь с нами для аудита вашей инфраструктуры — оценим проект за один день. Закажите настройку MIG под ключ и получите стабильный автоскейлинг без сюрпризов.