תצורת קבוצות קנה מידה אוטומטי של AWS ברמה מומחית

אנו מגדירים קבוצות קנה מידה אוטומטי (Auto Scaling Groups) ב-AWS כך שהאפליקציה שלך תוכל להתמודד עם עומסי שיא ללא השבתה או תשלום יתר. תצורה שגויה עלולה לעלות עשרות אלפי דולרים בחודש או לגרום לשעות של השבתה. הגדרה נכונה של ASG עם קנה מידה חיזוי (Predictive Scaling) ומדיניות מופעים מעורבת (Mixed Instance Policy) מפחיתה עלויות ב-60–70%. עם למעלה מ-50 פרויקטי קנה מידה מוצלחים מאחורינו, מהנדסים מוסמכים ואחריות לתוצאות, אנחנו השותף המועדף עליך.

הנה סיפור אופייני: ASG שהוגדר עם מדיניות מבוססת CPU. העומס גדל, ה-CPU מגיע ל-70%, וה-ASG משיק מופע חדש. לוקח 5 דקות להתחיל ועוד 3 לבדיקות בריאות — 8 דקות בסך הכול לפני שהמופע החדש משרת תנועה. עד אז, ה-CPU על המופעים הקיימים כבר עבר מזמן את 90%, והמשתמשים רואים פסקי זמן.

הפתרון טמון בקנה מידה חיזוי ובתצורת חימום נכונה. בואו נצלול פנימה.

תבניות השקה (Launch Templates) במקום תצורות השקה (Launch Configurations)

תצורות השקה הן מיושנות. במשך שנים, AWS ממליצה רשמית על תבניות השקה לכל הפריסות החדשות. תבניות השקה תומכות בגרסאות (כדי שתוכל לחזור לאחור), מדיניות מופעים מעורבת (שילוב סוגי מופעים שונים ב-ASG אחד), מצב בלתי מוגבל של מופעי T, ותכונות חדשות אחרות.

resource "aws_launch_template" "app" {
  name_prefix = "myapp-"
  image_id = data.aws_ami.app.id
  instance_type = "t3.medium"
  iam_instance_profile {
    name = aws_iam_instance_profile.app.name
  }
  user_data = base64encode(templatefile("${path.module}/userdata.sh", {
    environment = var.environment
  }))
  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "myapp-${var.environment}"
    }
  }
  lifecycle {
    create_before_destroy = true
  }
}

באילו מדיניות קנה מידה לבחור?

מעקב אחר יעד (Target Tracking) הוא הפשוט והמומלץ ביותר. אתה מציין ערך מטריית יעד, וה-ASG מחשב אוטומטית כמה מופעים נדרשים. עבור יעד CPU של 50%, ה-ASG שומר על ממוצע CPU סביב 50% על ידי הוספה או הסרה של מופעים.

resource "aws_autoscaling_policy" "cpu_target" {
  name = "cpu-target-tracking"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 50.0
  }
}

קנה מידה מדורג (Step Scaling) נותן שליטה מדויקת יותר. שלבי קנה מידה שונים בהתאם למידת החריגה של המדד מהסף. CPU 60–75% → הוסף מופע אחד, CPU 75–90% → הוסף 3 מופעים, CPU >90% → הוסף 5 מופעים.

קנה מידה מתוזמן (Scheduled Scaling) לשיאים צפויים. שילוב גישות אלה מניב תגובה אופטימלית לעומס.

כיצד להגדיר תקופת חסד לבדיקת בריאות?

ה-ASG בודק את בריאות המופע באמצעות בדיקות סטטוס של EC2 או בדיקות בריאות של ALB. בדיקות בריאות של ALB הן הטובות ביותר לשירותי אינטרנט: הן בודקות תגובות אפליקציה אמיתיות, לא רק זמינות היפרביזור.

resource "aws_launch_template" "app" { name_prefix = "myapp-" image_id = data.aws_ami.app.id instance_type = "t3.medium" iam_instance_profile { name = aws_iam_instance_profile.app.name } user_data = base64encode(templatefile("${path.module}/userdata.sh", { environment = var.environment })) tag_specifications { resource_type = "instance" tags = { Name = "myapp-${var.environment}" } } lifecycle { create_before_destroy = true } } הוא הזמן שה-ASG נותן למופע חדש לאתחל לפני תחילת בדיקות הבריאות. אם הוא קצר מדי, המופע יסומן כלא בריא לפני שהאפליקציה מתחילה וה-ASG יפסיק אותו. אם הוא ארוך מדי, מופע שבור באמת נשאר ברוטציה.

ליישומים עם התחלה קרה ארוכה (Spring Boot, JVM) — תקופת חסד של 300–600 שניות. לשירותי Go/Node קלים — 60–120 שניות.

מדוע ווים למחזור חיים (Lifecycle Hooks) קריטיים לפריסות

ווים למחזור חיים מאפשרים לך לבצע פעולות במהלך השקת מופע או סיומו, תוך השהיית תהליך ה-ASG עד שהוו מסתיים. לפי תיעוד AWS Lifecycle Hooks, אתה יכול:

• resource "aws_autoscaling_policy" "cpu_target" { name = "cpu-target-tracking" autoscaling_group_name = aws_autoscaling_group.app.name policy_type = "TargetTrackingScaling" target_tracking_configuration { predefined_metric_specification { predefined_metric_type = "ASGAverageCPUUtilization" } target_value = 50.0 } } : לחכות לאתחול מלא של האפליקציה, הרשמה ב-consul/etcd, טעינת תצורה מ-S3.
• health_check_grace_period: לחכות לסיום בקשות נוכחיות, ביטול הרשמה מגילוי שירות, שליחת מדדים סופיים.

ללא וו סיום בקנה מידה פנימה, ה-ALB מקבל הוראה להסיר את המופע מהרוטציה, אך ה-ASG הורג את המופע לאחר 30 שניות. חיבורים פעילים נפלים. עם וו, המופע מנקז תחילה חיבורים (עד 5 דקות), ואז מאותת לוו להשלים.

כיצד לחסוך עם מדיניות מופעים מעורבת?

כדי להפחית עלויות, השתמש במדיניות מופעים מעורבת: חלק מהקיבולת על פי דרישה (On-Demand) (בסיס), והשאר על ספוט (Spot). מופעי ספוט יכולים להיות זולים פי 10 ממופעי On-Demand כאשר אתה בוחר את האסטרטגיה הנכונה. לדוגמה, אחד הלקוחות שלנו הפחית את החשבון החודשי שלו ב-AWS מ-$12,000 ל-$3,600 על ידי מעבר למדיניות מעורבת עם 80% מופעי ספוט.

mixed_instances_policy {
  instances_distribution {
    on_demand_base_capacity = 1
    on_demand_percentage_above_base_capacity = 20
    spot_allocation_strategy = "price-capacity-optimized"
  }
  launch_template {
    launch_template_specification {
      launch_template_id = aws_launch_template.app.id
      version = "$Latest"
    }
    override {
      instance_type = "t3.medium"
    }
    override {
      instance_type = "t3a.medium"
    }
    override {
      instance_type = "t2.medium"
    }
  }
}

אסטרטגיית autoscaling:EC2_INSTANCE_LAUNCHING בוחרת מופעי ספוט ממאגרים עם הזמינות הגבוהה ביותר והמחיר הנמוך ביותר, ומפחיתה את סיכון ההפרעה. אופטימיזציית עלויות של Auto Scaling מושגת באמצעות מדיניות מעורבת כזו. ניתן להגדיר קנה מידה אוטומטי של מופעי ספוט עם אסטרטגיה זו עבור עומסי עבודה סובלניים לתקלות.

כיצד להגדיר קבוצת קנה מידה אוטומטי: שלב אחר שלב

1. צור תבנית השקה עם AMI, סוג מופע, נתוני משתמש ותגיות.
2. צור קבוצת קנה מידה אוטומטי, בחר את תבנית ההשקה וציין VPC ורשתות משנה.
3. הגדר מדיניות קנה מידה: מעקב אחר יעד עבור CPU או ספירת בקשות.
4. חבר ALB והגדר תקופת חסד לבדיקת בריאות (300–600 שניות ליישומים כבדים).
5. הוסף ווים למחזור חיים לכיבוי חלק (EC2_INSTANCE_TERMINATING).
6. הגדר מדיניות מופעים מעורבת לחיסכון.
7. בדוק קנה מידה עם בדיקות עומס.

מה כלול (תוצרים)

• ביקורת על תצורת ASG הנוכחית עם המלצות
• עיצוב תבניות השקה עם אבטחה ונתוני משתמש
• הגדרה של מדיניות קנה מידה אחת או יותר (מעקב אחר יעד, מדורג, מתוזמן)
• אינטגרציה עם ALB וכיוונון בדיקות בריאות
• יישום ווים למחזור חיים לכיבוי חלק
• מדיניות מופעים מעורבת לאופטימיזציית עלויות
• ניטור (CloudWatch, Prometheus) והתראות
• תיעוד והדרכת צוות
• גישה לחשבון AWS שלך לניטור שוטף
• תמיכה לחודש אחד ומסירת אישורי גישה
• אחריות לחודש אחד על ההגדרות

ציר זמן ועלות

הגדרת ASG בסיסית עם מדיניות מעקב אחר יעד ואינטגרציית ALB — מיום אחד. תצורה מלאה כוללת ווים למחזור חיים, מופעים מעורבים, קנה מידה מתוזמן וניטור — 2–4 ימים. התמחור נקבע באופן אישי לאחר ניתוח התשתית שלך.

צור קשר להערכת פרויקט. נעריך את תצורת ה-ASG הנוכחית שלך ונראה לך כיצד לחסוך עד 70% בעלויות הענן. קבל ייעוץ ממהנדס AWS עם ניסיון של 7+ שנים. אנו מבטיחים שקנה המידה שלך יהיה אמין, חסכוני וניתן לניהול.