שינוי גודל על סמך תחזיות

אתם יכולים להגדיר התאמה אוטומטית לעומס (autoscaling) לקבוצת מופעי מכונה מנוהלים (MIG) כדי להוסיף או להסיר אוטומטית מכונות וירטואליות (VM) בהתאם לעלייה או לירידה בעומס. עם זאת, אם לוקח לאפליקציה כמה דקות או יותר להתחיל לפעול, הוספת מופעים בתגובה לשינויים בזמן אמת לא תגדיל את הקיבולת של האפליקציה מספיק מהר. לדוגמה, אם יש עלייה גדולה בעומס (כמו כשמשתמשים מתעוררים בבוקר), יכול להיות שחלק מהמשתמשים יחוו עיכובים בזמן שהאפליקציה מופעלת במכונות חדשות.

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

כשמפעילים את התכונה 'שינוי גודל אוטומטי חזוי',‏ Compute Engine חוזה את העומס העתידי על סמך ההיסטוריה של ה-MIG, ומגדיל את ה-MIG לפני שהעומס צפוי להגיע, כך שמופעלים מראש מופעים חדשים שמוכנים לטפל בעומס. בלי התאמה אוטומטית לעומס מבוססת-חיזוי, מידרוג אוטומטי יכול להתאים את הגודל של קבוצה רק באופן ריאקטיבי, על סמך שינויים בעומס שנצפו בזמן אמת. כשהתכונה "התאמה אוטומטית של קנה מידה לחיזוי" מופעלת, הכלי להתאמה אוטומטית של קנה מידה פועל עם נתונים בזמן אמת וגם עם נתונים היסטוריים, כדי לכסות את העומס הנוכחי והעומס החזוי. למידע נוסף, קראו את המאמרים איך פועל התאמה אוטומטית חזויה לעומס ובדיקה אם התאמה אוטומטית חזויה לעומס מתאימה לעומס העבודה שלכם.

לפני שמתחילים

תמחור

השימוש בתכונה 'התאמה אוטומטית לעומס חזויה' הוא בחינם. אבל אם מפעילים את התכונה 'שינוי גודל אוטומטי חזוי' כדי לבצע אופטימיזציה לזמינות, משלמים על משאבי Compute Engine שקבוצת ה-MIG משתמשת בהם.

מגבלות

  • התאמה אוטומטית חזויה לעומס עובדת רק עם ניצול CPU כמדד להתאמה. אין תמיכה במדדים של Cloud Load Balancing או Cloud Monitoring.
  • כדי ש-Compute Engine יוכל ליצור תחזיות, הוא צריך היסטוריה של 3 ימים של התאמה אוטומטית לעומס שמבוססת על מעבד.
  • החיזויים מבוססים על דפוסי עומס שבועיים ויומיים. ‫Compute Engine לא חוזה אירועים חודשיים, שנתיים או חד-פעמיים, ולא חוזה דפוסי עומס שנמשכים פחות מ-10 דקות. אתם יכולים להשתמש בהתאמה אוטומטית לעומס מבוססת-תזמון כדי לבקש קיבולת עבור דפוסים חד-פעמיים או דפוסי עומס אחרים.

עומסי עבודה מתאימים

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

  • האתחול של האפליקציה נמשך זמן רב – לדוגמה, אם הגדרתם תקופת אתחול של יותר מ-2 דקות.
  • עומס העבודה משתנה בצורה צפויה במחזורים יומיים או שבועיים.

אם לשירות שלכם לוקח הרבה זמן להתחיל, יכול להיות שהמשתמשים יחוו זמן אחזור בשירות אחרי אירוע של הרחבה אופקית בהתאם לעומס (scale out), כלומר בזמן שהמכונות הווירטואליות החדשות מוקצות אבל עדיין לא משרתות. התכונה 'שינוי גודל אוטומטי חיזוי' לוקחת בחשבון את זמן האתחול של האפליקציה ומגדילה את הקיבולת מראש לפני העלייה הצפויה בשימוש, כדי להבטיח שמספר המופעים הזמינים של שרתים יהיה מספיק לניצול היעד.

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

הפעלה והשבתה של שינוי גודל אוטומטי חזוי

אפשר להפעיל התאמה אוטומטית לעומס (auto-scaling) מבוססת-תחזיות כשמבצעים התאמה לעומס על סמך ניצול המעבד. מידע נוסף על הגדרת התאמה אוטומטית לעומס שמבוססת על מעבד זמין במאמר בנושא התאמה לעומס שמבוססת על ניצול המעבד.

אם לקבוצת ה-MIG אין היסטוריה של מידרוג אוטומטי, יכול להיות שיעברו 3 ימים עד שהאלגוריתם החזוי ישפיע על המידרוג האוטומטי. במהלך התקופה הזו, הקבוצה משתנה בהתאם לנתונים בזמן אמת בלבד. אחרי 3 ימים, הקבוצה מתחילה לשנות את הגודל שלה לפי התחזיות. ככל שנאספים יותר נתונים היסטוריים של עומס, כך המידרוג האוטומטי החזוי מבין טוב יותר את דפוסי העומס והתחזיות שלו משתפרות. כדי להזין את מודל למידת המכונה, המערכת של Compute Engine משתמשת בהיסטוריית העומסים של קבוצת ה-MIG בטווח של עד 3 שבועות.

המסוף

  1. נכנסים לדף Instance groups במסוף.

    כניסה לדף Instance groups

  2. ברשימה, לוחצים על השם של קבוצת MIG קיימת כדי לפתוח את דף הסקירה הכללית של הקבוצה.

  3. לוחצים על Edit.

  4. לוחצים על גודל הקבוצה והתאמה אוטומטית לעומס כדי להרחיב את הקטע ומבצעים את הפעולות הבאות:

    1. אם אין הגדרת התאמה אוטומטית לעומס, מגדירים אותה באופן הבא:

      1. בקטע Autoscaling, לוחצים על Configure autoscaling. אות ניצול המעבד (CPU) מתווסף כברירת מחדל.
      2. מציינים את המספר המינימלי והמקסימלי של מופעים שרוצים שהכלי להתאמה אוטומטית לעומס ייצור בקבוצה הזו.
      3. בקטע Autoscaling signals, לוחצים על האות של ניצול ה-CPU.
      4. משנים את סוג האות ואת ניצול המעבד לטירגוט לפי הצורך.

      5. בקטע Predictive autoscaling (שינוי גודל אוטומטי מבוסס-תחזיות), בוחרים באפשרות Optimize for availability (אופטימיזציה לזמינות) כדי להפעיל שינוי גודל אוטומטי מבוסס-תחזיות.

        • לחלופין, אם רוצים להשבית את אלגוריתם החיזוי ולהשתמש רק במנגנון ההתאמה האוטומטית לעומס בזמן אמת, בוחרים באפשרות Off.

      6. לוחצים על סיום.

    2. אם כבר הגדרתם התאמה אוטומטית לעומס על סמך ניצול המעבד, צריך לבצע את הפעולות הבאות:

      1. בקטע Autoscaling signals, לוחצים על האות של ניצול ה-CPU.
      2. בקטע Predictive autoscaling (שינוי גודל אוטומטי מבוסס-תחזיות), בוחרים באפשרות Optimize for availability (אופטימיזציה לזמינות) כדי להפעיל שינוי גודל אוטומטי מבוסס-תחזיות.

    3. לוחצים על סיום.

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

  6. לוחצים על Save.

gcloud

כשמגדירים או מעדכנים את ה-autoscaler של ה-MIG, צריך לכלול את הדגל --cpu-utilization-predictive-method עם אחד מהערכים הבאים:

  • ‫optimize-availability: כדי להפעיל את האלגוריתם החזוי
  • ‫none (ברירת מחדל): כדי להשבית את האלגוריתם לחיזוי

אם המידרוג האוטומטי מבוסס-CPU עדיין לא מופעל בקבוצה, צריך להפעיל אותו. אתם יכולים להשתמש בפקודה set-autoscaling כדי להגדיר מדיניות של התאמה אוטומטית לעומס של קבוצה מאפס. לדוגמה, הפקודה הבאה מראה איך להגדיר התאמה אוטומטית לעומס (automatic scaling) עם ההגדרות הבאות:

  • התכונה 'שינוי גודל אוטומטי חזוי' מופעלת.
  • יעד של 75% ניצול מעבד (CPU).
  • המספר המקסימלי של המכונות מוגדר ל-20.
  • תקופת אתחול (--cool-down-period) שמוגדרת ל-5 דקות. ההגדרה הזו מודיעה למנגנון לשינוי גודל אוטומטי מבוסס-חיזוי להגדיל את הקיבולת 5 דקות לפני העומס הצפוי, כדי שהאפליקציות יאותחלו כשהעומס יגיע.
gcloud compute instance-groups managed set-autoscaling MIG_NAME \
  --cpu-utilization-predictive-method optimize-availability \
  --target-cpu-utilization 0.75 \
  --max-num-replicas 20 \
  --cool-down-period 300

אם כבר הפעלתם בקבוצה התאמה אוטומטית לעומס (autoscaling) שמבוססת על שימוש ב-CPU, אתם יכולים להפעיל את האלגוריתם החזוי באמצעות הפקודה update-autoscaling:

gcloud compute instance-groups managed update-autoscaling MIG_NAME \
  --cpu-utilization-predictive-method=optimize-availability

REST

כשיוצרים או מעדכנים קנה מידה אוטומטי, צריך לכלול את השדה predictiveMethod בגוף הבקשה עם אחד מהערכים הבאים:

  • ‫OPTIMIZE_AVAILABILITY: כדי להפעיל את האלגוריתם החזוי
  • ‫NONE (ברירת מחדל): כדי להשבית את האלגוריתם לחיזוי

אם לקבוצה לא מוגדרת הגדרה קיימת של שינוי גודל אוטומטי, מבצעים את הפעולות הבאות:

אם לקבוצה כבר יש הגדרת התאמה אוטומטית לעומס, מבצעים את הפעולות הבאות:

אם המידרוג האוטומטי מבוסס-CPU עדיין לא מופעל בקבוצה, צריך להפעיל אותו.

לדוגמה, הבקשה הבאה מבצעת תיקון של משאב קיים של התאמה אוטומטית לעומס כדי להפעיל התאמה אוטומטית לעומס שמבוססת על מעבד (CPU) עם ההגדרות הבאות:

  • התכונה 'שינוי גודל אוטומטי חזוי' מופעלת.
  • יעד של 75% ניצול מעבד (CPU).
  • המספר המקסימלי של מופעים מוגדר ל-20.
  • תקופת אתחול (coolDownPeriodSec) שמוגדרת ל-5 דקות. ההגדרה הזו מודיעה למנגנון לשינוי גודל אוטומטי מבוסס-חיזוי להגדיל את הקיבולת 5 דקות לפני העומס הצפוי, כדי שהאפליקציות יאותחלו כשהעומס יגיע.
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/autoscalers?autoscaler=AUTOSCALER_NAME

{
  "target": "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/MIG_NAME",
  "autoscalingPolicy": {
    "cpuUtilization": {
       "utilizationTarget": 0.75,
       "predictiveMethod": "OPTIMIZE_AVAILABILITY"
     },
    "maxNumReplicas": 20,
    "coolDownPeriodSec": 300
  }
}

בדיקה אם המידרוג האוטומטי החזוי מופעל

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

הגדרת התאמה לעומס (autoscaling) על סמך חיזוי

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

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

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

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

למידע נוסף על עומסי עבודה שמתאימים להתאמה חזויה לעומס, קראו את המאמר עומסי עבודה מתאימים.

בדיקה אם יש עומס יתר

קבוצת ה-MIG עם שינוי הגודל האוטומטי עמוסה מדי כשהשימוש הממוצע במעבד חורג מהיעד שהגדרתם. כדי לבדוק אם הגדרת ההתאמה האוטומטית לעומס גרמה לעומס יתר על המכונות הווירטואליות ב-7 הימים האחרונים, ולראות אם התאמה אוטומטית חזויה לעומס יכולה להפחית את עומסי היתר, מבצעים את השלבים הבאים:

  1. נכנסים לדף Instance groups במסוף.

    כניסה לדף Instance groups

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

  3. לוחצים על Edit.

  4. לוחצים על גודל הקבוצה ושינוי גודל אוטומטי כדי להרחיב את הקטע.

  5. בקטע Autoscaling, בקטע Autoscaling signals, מרחיבים את הקטע CPU utilization ולוחצים על See if predictive autoscaling can optimize your availability.

  6. על סמך הנתונים מ-7 הימים האחרונים, בטבלה מוצג מספר המכונות הווירטואליות שהיו בשימוש בכל יום ומספר המכונות הווירטואליות שהיו בעומס יתר בכל יום, בשורות הבאות:

    • הגדרות המידרוג האוטומטי הנוכחיות: מציגות את הביצועים של המידרוג האוטומטי על סמך ההגדרות שלו ב-7 הימים האחרונים.
    • כשההגדרה של התאמה אוטומטית חזויה לעומס היא Optimize for availability: מוצג איך ההתאמה האוטומטית לעומס הייתה פועלת אם ההתאמה האוטומטית החזויה לעומס הייתה מופעלת ב-7 הימים האחרונים.

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

מעקב אחרי התאמה חזויה לעומס וסימולציה שלה

אתם יכולים להשתמש ב-Cloud Monitoring כדי להציג את הגודל ההיסטורי של הקבוצה שלכם. בתרשים המעקב מוצג איך הגדרת ההתאמה האוטומטית לעומס שינתה את גודל הקבוצה לאורך זמן, וגם איך ההתאמה האוטומטית לעומס החזוי, אם היא מופעלת, הייתה משנה את גודל הקבוצה.

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

  1. נכנסים לדף Instance groups במסוף.

    כניסה לדף Instance groups

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

  3. לוחצים על Monitoring כדי לראות תרשימים שקשורים לקבוצה.

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

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

איך פועל שינוי גודל אוטומטי מבוסס-חיזוי

מידרוג אוטומטי מבוסס תחזית חוזה את מדד המידרוג על סמך המגמות ההיסטוריות של המדד. התחזיות מחושבות מחדש כל כמה דקות, וכך המערכת האוטומטית לשינוי גודל יכולה להתאים במהירות את התחזית לשינויים האחרונים בעומס. כדי לספק תחזיות, הכלי לשינוי גודל אוטומטי מבוסס חיזוי צריך לצבור נתונים היסטוריים של 3 ימים לפחות, שמהם הוא יכול להסיק דפוס מייצג של שימוש בשירות. ‫Compute Engine משתמש בהיסטוריית העומסים של קבוצת ה-MIG עד 3 שבועות אחורה כדי להזין את המודל של למידת המכונה.

המידרוג האוטומטי מבוסס-חיזוי מחשב את מספר המכונות הווירטואליות שדרושות כדי להשיג את יעד הניצול שלכם על סמך גורמים רבים, כולל:

  • הערך העתידי החזוי של מדד ההרחבה
  • הערך הנוכחי של מדד ההתאמה
  • רמת המהימנות של מגמות קודמות, כולל השונות הקודמת של מדד ההתאמה לעומס
  • תקופת האתחול של האפליקציה שהוגדרה, שנקראת גם תקופת האתחול

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

השוואה בין מכונות וירטואליות להכניס לשימוש בסביבת הייצור עם התאמה אוטומטית לעומס חזויה לבין מכונות וירטואליות להכניס לשימוש בסביבת הייצור ללא התאמה אוטומטית לעומס חזויה.

איור 1. השוואה בין מכונות וירטואליות להצגת מודעות עם ובלי התאמה חזויה לעומס.

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

נתוני שימוש בזמן אמת

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

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

שני תרשימים שמראים איך התחזיות מתאימות את עצמן לשימוש בפועל במעבד (CPU).

איור 2. שני תרשימים שמראים איך התחזיות מתאימות את עצמן לשימוש בפועל במעבד (CPU).

באיור 2, הקו הצהוב המקווקו מראה את החיזוי בנקודת הזמן t1. אבל השימוש בפועל במעבד, שמוצג על ידי הקו הכחול הרציף, שונה מהשימוש שחזו. בתרשים הימני, השימוש בפועל במעבד גבוה מהשימוש הצפוי. בתרשים השמאלי, השימוש בפועל במעבד נמוך מהשימוש הצפוי. הקו הכחול המקווקו מייצג את התחזית המותאמת.

עליות קצרות ובלתי צפויות

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

עלייה קצרה ובלתי צפויה גורמת למידרוג אוטומטי להגיב בזמן אמת.

איור 3. עלייה קצרה ובלתי צפויה גורמת למידרוג אוטומטי להגיב בזמן אמת.

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

ירידות פתאומיות

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

ירידה פתאומית גורמת לשינוי בתחזית של ההתאמה החזויה לעומס.

איור 4. ירידה פתאומית גורמת למידרוג אוטומטי לשנות את החיזוי שלו.

באיור 4, הקו הצהוב המקווקו מראה את החיזוי ב-t1. אבל השימוש בפועל במעבד, שמוצג על ידי הקו הכחול הרציף, היה נמוך מהצפי. הקו הכחול המקווקו מציג את התחזית המעודכנת, שהותאמה אוטומטית אחרי שנצפה שימוש נמוך מהתחזית. כתוצאה מכך, המידרוג האוטומטי מסיר מכונות וירטואליות אחרי תקופת הייצוב הרגילה.

נתונים היסטוריים

כדי להתחיל לחזות, מידרוג אוטומטי מבוסס-חיזוי צריכה נתונים היסטוריים של עומס מ-3 ימים לפחות. אם יש לכם קבוצת MIG חדשה שאין לה נתונים היסטוריים, מערכת Compute Engine תבצע שינוי גודל של הקבוצה באופן תגובתי באמצעות נתונים בזמן אמת, עד שיהיו מספיק נתונים היסטוריים. אחרי 3 ימים, כשהמערכת של Compute Engine אוספת נתוני שימוש נוספים, התחזיות משתפרות.

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

המאמרים הבאים