הטמעת קנה מידה חיזוי: קנה מידה אוטומטי מבוסס תחזית

הטמעת קנה מידה חיזוי: אוטוסקיילינג מבוסס תחזית

לעתים קרובות אנו נתקלים במצבים שבהם קנה מידה תגובתי אינו יכול לעמוד בקצב העומס הגדל: מופעים מתווספים רק לאחר שמשתמשים כבר חוו האטות. קנה מידה מתוזמן דורש תחזוקה ידנית של לוחות זמנים ונשבר כאשר הדפוסים משתנים. שיטת אוטוסקיילינג זו המונעת על ידי למידת מכונה פותרת בעיות אלה: המהנדסים המוסמכים שלנו עם ניסיון של 10+ שנים ו-40+ פרויקטים מוצלחים מגדירים פתרון זה במפתח מלא. AWS מנתחת נתוני עומס היסטוריים מ-14 הימים האחרונים ובונה תחזית למידת מכונה ל-48 השעות הבאות, ומוסיפה מופעים אוטומטית לפני שהעומס גדל.

גישה זו אינה תחליף לקנה מידה תגובתי אלא משלימה אותו. קנה מידה חיזוי מטפל בדפוסים קבועים, וקנה מידה תגובתי מטפל בקפיצות בלתי צפויות. אנו מבטיחים שהתשתית שלך תהיה מוכנה לכל תרחיש. עלות הפתרון הכוללת: $750 לכל קבוצת אוטוסקיילינג, כולל הגדרת Terraform ושבועיים של ניטור.

כיצד פועל חיזוי למידת מכונה של AWS

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

• דפוסים יומיים (עלייה בבוקר, מנוחה בלילה)
• מחזורים שבועיים (ימי חול לעומת סופי שבוע)
• שילובים (ימי שני בבוקר תמיד גבוהים יותר מימי שישי)

המודל אינו לוכד אירועים חד-פעמיים (קמפיינים פרסומיים, חדשות) או חריגות טכניות (DDoS, קפיצות של סורקים). עבור אלה, קנה מידה תגובתי יושב מעל.

קנה מידה חיזוי אינו מחליף קנה מידה תגובתי

זוהי שאלה נפוצה של לקוחות. השיטה המונעת על ידי למידת מכונה אידיאלית למחזורים צפויים אך חסרת אונים מול קפיצות פתאומיות. לכן, בתצורות ייצור, אנו תמיד משלבים את שניהם: קנה מידה חיזוי מכין קיבולת לפסגות קבועות, ו-Target Tracking מתאים כאשר מתרחשות סטיות. שילוב זה מבטיח SLA של 99.9% אפילו עם תעבורה כאוטית.

הגדרה באמצעות Terraform

resource "aws_autoscaling_policy" "predictive" {
  name = "predictive-scaling"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type = "PredictiveScaling"

  predictive_scaling_configuration {
    metric_specification {
      target_value = 50 # целевой CPU%
      predefined_scaling_metric_specification {
        predefined_metric_type = "ASGAverageCPUUtilization"
      }
      predefined_load_metric_specification {
        predefined_metric_type = "ASGTotalCPUUtilization"
      }
    }
    mode = "ForecastAndScale"
    scheduling_buffer_time = 300 # 5 минут до прогнозируемого пика
    max_capacity_breach_behavior = "IncreaseMaxCapacity"
    max_capacity_buffer = 10 # запас 10% сверх прогноза
  }
}

resource "aws_autoscaling_policy" "predictive" { name = "predictive-scaling" autoscaling_group_name = aws_autoscaling_group.app.name policy_type = "PredictiveScaling" predictive_scaling_configuration { metric_specification { target_value = 50 # целевой CPU% predefined_scaling_metric_specification { predefined_metric_type = "ASGAverageCPUUtilization" } predefined_load_metric_specification { predefined_metric_type = "ASGTotalCPUUtilization" } } mode = "ForecastAndScale" scheduling_buffer_time = 300 # 5 минут до прогнозируемого пика max_capacity_breach_behavior = "IncreaseMaxCapacity" max_capacity_buffer = 10 # запас 10% сверх прогноза } } — מופעים מופעלים 5 דקות לפני הפסגה החזויה. זה מכסה את זמן ההפעלה והאתחול. עבור יישומים עם התחממות ארוכה (Spring Boot), ייתכן שיידרשו 600–900 שניות.

scheduling_buffer_time: 300 — התחל עם מצב זה. קבוצת האוטוסקיילינג תבנה תחזיות ותציג אותן ב-CloudWatch אך לא תבצע פעולה. זה מאפשר לך להעריך את דיוק התחזית לפני הפעלת קנה מידה בפועל.

שלבי ההטמעה:

1. ניתוח נתונים היסטוריים לבחירת המדד האופטימלי.
2. הגדרת מדיניות קנה מידה חיזוי במצב ForecastOnly.
3. ניטור תחזיות במשך 1-2 שבועות.
4. מעבר ל-ForecastAndScale.
5. אימות והתאמת זמן חיץ.

מדדים אופטימליים לחיזוי

קנה מידה חיזוי עובד עם שני סוגי מדדים:

עבור מדד עומס ומדד קנה מידה, עדיף להשתמש במדדים שונים: מדד העומס מתאר את עומס הצי כולו (לדוגמה, ASGTotalCPUUtilization = סכום כל מעבדי המופעים), ומדד קנה המידה קובע את היעד לכל מופע.

מגבלות מעשיות

גישה זו פועלת רק עבור קבוצות EC2 Auto Scaling. שירותי ECS, DynamoDB, Lambda Provisioned Concurrency — רק באמצעות פעולות מתוזמנות או Target Tracking.

הגישה המונעת על ידי למידת מכונה אינה מקטינה במצב ForecastAndScale — רק מגדילה. הפחתה נשארת עם Target Tracking. אם דפוס העומס אינו יציב (סטארטאפים עם דפוסים משתנים במהירות, שינויי תעבורה בבדיקות A/B), ההיסטוריה של 14 הימים תהיה רועשת והתחזית לא מדויקת. במקרים כאלה, פעולות מתוזמנות + קנה מידה תגובתי אמינות יותר.

אימות דיוק התחזית

ב-CloudWatch, עיין ב-ASGAverageNetworkIn/Out ו-PredictiveScalingLoadForecast. השווה עומס חזוי לעומת בפועל. אם שגיאת התחזית עולה על 30% באופן שיטתי, או שהדפוס אינו יציב או שנבחר מדד שגוי. בקונסולת AWS (EC2 → Auto Scaling Groups → לשונית Predictive Scaling), יש ויזואליזציה של תחזית לעומת בפועל — נוחה לכיול ראשוני. בסביבות יציבות, דיוק התחזית עולה על 90%.

מה כלול

בהזמנת שירות זה, אנו מספקים:

• ניתוח נתונים היסטוריים ובחירת המדד האופטימלי
• הגדרת קנה מידה חיזוי באמצעות Terraform (ForecastOnly → ForecastAndScale)
• אינטגרציה עם מדיניות תגובתית ומתוזמנת קיימת
• ניטור דיוק תחזית ב-CloudWatch למשך שבועיים
• תיעוד Runbook והמלצות להפחתה
• אחריות איכות: אם שגיאת התחזית עולה על 20% באופן שיטתי, אנו מגדירים מחדש את המערכת ללא עלות. לדוגמה, בפרויקט אחרון, קנה מידה חיזוי הפחית את ההקצאה העודפת ב-40%, וחסך $1200 בחודש. אנו ממליצים להשתמש במספר אזורי זמינות (לפחות 3) כדי לפזר את העומס.

שילוב עם קנה מידה תגובתי

תצורת הייצור הסופית:

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

לוח זמנים והערכה

הפעלת קנה מידה חיזוי במצב ForecastOnly אורכת מספר שעות. התבוננות בתחזית במשך 1–2 שבועות, מעבר ל-ForecastAndScale וכיוונון פרמטרים אורכים 3–5 ימי עסקים בסך הכל (עם הפסקות לצורך צבירת נתונים). העלות מחושבת באופן פרטני — צור קשר לקבלת הצעת מחיר מפורטת. עלויות פרויקט טיפוסיות נעות בין $500 ל-$2000 בהתאם למורכבות.

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