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