קבוצות מופעים מנוהלות וקנה מידה אוטומטי ב-GCP

קבוצות מופעים מנוהלות ואוטוסקיילינג ב-GCP

אתה מריץ שירות ב-GCP על תריסר מכונות וירטואליות. עליות עומס מאלצות אותך להחזיק קיבולת רזרבה, ויצירה ידנית של מופעים גוזלת שעות. קבוצות מופעים מנוהלות (MIG) פותרות את זה: מאגר של מכונות VM זהות ש-GCP יוצר אוטומטית, יוצר מחדש במקרה של תקלות, ומבצע סקיילינג לפי מדדים. אנחנו משתמשים ב-MIG ב-80% מהפרויקטים במקום Kubernetes כאשר תקורה של קלאסטר אינה מוצדקת. הניסיון שלנו — מעל 50 סכמות ייצור, חיסכון בתקציב עד 40% בהשוואה לניהול ידני. לפי תיעוד קבוצות מופעים מנוהלות, MIG תומך באוטוסקיילינג לפי CPU, תעבורת מאזן עומס, ומדדים מותאמים אישית, מה שמאפשר התאמה מדויקת של מספר המופעים לעומס בפועל ללא תשלום יתר. גישה זו יעילה במיוחד עבור יישומים חסרי מצב עם עומס לא אחיד, למשל מעבדי תמונות או שרתי אינטרנט מאחורי Cloud Load Balancer. במאמר זה, אסקור כיצד להגדיר MIG עם אוטוסקיילינג מבוסס CPU ומבוסס Pub/Sub, להפעיל ריפוי אוטומטי, ולבצע עדכונים מתגלגלים ללא השבתה. נסקור גם MIG עם מצב (Stateful) עבור עובדים עם נתונים מקומיים.

תבנית מופע — הבסיס

MIG לא יעבוד ללא תבנית מופע. זהו תמונת מצב של תצורת VM: סוג מכונה, תמונת דיסק, רשת, חשבון שירות, סקריפט אתחול. להלן תבנית 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
  }
}

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 } } הוא חובה — בעדכון תבנית, Terraform יוצר תחילה את החדשה, ואז מוחק את הישנה, אחרת MIG מאבדת את התבנית שלו לזמן קצר.

איך להגדיר אוטוסקיילינג לעובדי Pub/Sub?

אם העובד שלך מעבד הודעות מ-Pub/Sub, השתמש באוטוסקיילר עם המדד create_before_destroy = true. דוגמת תצורה:

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?

השווה בין שתי הגישות:

עבור עובדים חסרי מצב, עיבוד תמונה, inference של ML, ויישומי אינטרנט מסורתיים, MIG מנצח בפשטות ובעלות פי 2–3.

אילו מלכודות נפוצות?

• pubsub.googleapis.com/subscription/num_undelivered_messages נמוך מדי. היישום מתחיל תוך 90 שניות, בדיקת בריאות מוגדרת עם השהיה של 30 שניות — MIG מתחיל להחליף מופעים "לא בריאים" לפני שהם מסיימים לאתחל. אתה מקבל לולאת החלפה אינסופית. כלל: 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" } } } צריך להיות עם חיץ של פי 1.5 מזמן האתחול בפועל.
• עדכון Canary דרך גרסאות. MIG תומך בשתי תבניות בו זמנית — Canary נוח ללא Kubernetes. פרוס ל-2 מתוך 10 מופעים, עקוב אחר מדדים, הרחב.
• MIG עם מצב עבור עובדים עם דיסק מקומי. אם העובד צריך דיסק קבוע שנשמר בעת יצירה מחדש, ציין תמיד initial_delay_sec. אחרת, הדיסק נמחק עם המופע במהלך ריפוי אוטומטי.

מתי MIG עם מצב עדיף על פני חסר מצב?

MIG עם מצב שומר דיסקים קבועים כאשר מופעים נוצרים מחדש. זה נחוץ עבור עובדים עם נתונים מקומיים, למשל שירותי מטמון או מסדי נתונים. ציין initial_delay_sec עם delete_rule = "NEVER" בתצורת Terraform.

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

ללא כלל זה, הדיסק נמחק עם המופע במהלך ריפוי אוטומטי — אתה מקבל אובדן נתונים.

אינטגרציה עם מאזן עומס

MIG מתחבר לשירות ה-Backend של מאזן העומס דרך פורט בעל שם:

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

בדיקות בריאות עבור LB ועבור ריפוי אוטומטי יכולות להיות שונות — בדיקת LB מסתכלת על stateful_disk, בדיקת ריפוי אוטומטי על delete_rule = "NEVER". זה חשוב לכיבוי חלק ונכון.

מה כלול בהקמת MIG סוהר

• ביקורת של הפריסה הנוכחית ותוכנית הניטור
• תכנון: MIG אזורי מול זונלי, מדיניות עדכון, מדדי אוטוסקיילינג
• יישום ב-Terraform באמצעות מודולים
• הגדרת בדיקות בריאות וריפוי אוטומטי
• בדיקת עדכון מתגלגל ופריסת Canary על staging
• אינטגרציה עם Cloud Monitoring והתראות
• תיעוד והעברת תפקידי RBAC
• הדרכת צוות (שעה)

אנחנו מבטיחים פעולה יציבה: אם משהו משתבש, אנחנו מתקנים ללא תשלום תוך שבועיים לאחר הפריסה. המהנדסים שלנו מוסמכי GCP ויש להם ניסיון עם מעל 50 פרויקטים מוצלחים. צור קשר לייעוץ להגדרת MIG נכונה.

תהליך

1. ניתוח — סקירת תשתית קיימת, עומס, תקציב
2. תכנון — בחירת סוג MIG, מדדים, מדיניות עדכון
3. יישום — כתיבת תצורות Terraform, בדיקה על staging
4. בדיקה — אימות אוטוסקיילינג, עדכון מתגלגל, בדיקות בריאות
5. פריסה — יישום לייצור, הגדרת ניטור

לוח זמנים: 2–3 ימים לסכמה סטנדרטית. ארוך יותר אם נדרשת תצורת מצב או אינטגרציה עם LB קיים.

צור קשר לביקורת תשתית — נעריך את הפרויקט ביום אחד. קבל הקמת MIG סוהר והשג אוטוסקיילינג יציב ללא הפתעות.