סקיילינג אוטומטי חזוי מבוסס AI של אפליקציות לפי עומס

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

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

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

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

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

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

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

מה נותנת תחזית עומס: אפקט בזמן ובכשלים

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

מהירות תגובה בשיאים ושיעור כשלים מעומס יתר

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

כמה משאבים מפסיקים לשבת בבטלה בין התפרצויות

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

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

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

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

היברידי: ספים ועוד תחזית

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

כאשר תחזית מיותרת

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

שלבי הטמעת תחזית עומס בתפעול

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

איסוף מדדים וסימון שיאים

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

בדיקה בלולאת צל והעברה למשמרת התורן

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

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

תצורות, תרשימים ונהלים לאחר ההטמעה

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

מה כלול בחבילת התיעוד

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

נוהל תורנות בעת הפעלת תחזית

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

מקרה בוחן: איך תחזית עומס הסירה עומסי יתר בשעות שיא

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

מה היה לפני

הסקיילינג פעל לפי סף עומס מעבד — באיחור של כמה דקות. בזמן הזה תור הבקשות גדל, זמן התגובה הגיע לשניות, וב-6-8% מחלונות השיא השירות החזיר שגיאות. ברבעון קרו שני כשלים חוזרים: כושר נוסף ידנית ושוב לא הספיקו לפני תחילת השיא.

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

מה קרה אחרי

את התחזית בנו לפי פרופיל עומס היסטורי עם התאמה ללוח אירועים, ואת כללי הסקיילינג השאירו לצד תיאור השירות ב-Kubernetes — לא נדרשה לולאת שליטה נפרדת. שיעור חלונות השיא עם שגיאות ירד מ-6-8% ל-0.4%, התגובה לעליית העומס הקדימה ב-10-15 דקות, והרחבות שווא הצטמצמו בכשליש בערך.

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

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

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

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

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

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

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

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

מגבלות וכשלים אופייניים של סקיילינג חזוי

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

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

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

איך להבדיל בין הפעלת שווא לעלייה אמיתית?

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

מה עם אנומליות נדירות שהמודל לא ראה?

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

מאיפה להתחיל: ניתוח עומס ותוכנית הטמעה

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

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

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