הגדרת קנה מידה אוטומטי (VM Scale Sets) ב-Azure

סקיילינג אוטומטי ב-Azure: מה נשבר בלעדיו

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

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

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

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

מה משתנה בעבודת השירות: מהירות תגובה ויציבות

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

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

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

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

מצבי סקיילינג אוטומטי: כללים, לוח זמנים, תחזית

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

במה המצבים נבדלים בפועל

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

סדר ההטמעה: מאיסוף מדדים ועד העברת נהלים

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

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

סטים של כללים, תרשימי תשתית ונהלי תפעול

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

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

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

מקרה בוחן: כיצד גדלה יציבות השירות בעומסי שיא

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

איך היה לפני השינויים

מערך המכונות הווירטואליות היה קבוע. צמתים נוספו ידנית לפי התראה: מהאות ועד מכונה מוכנה לקבל תעבורה עברו 40–60 דקות — השיא הספיק להסתיים לפני שהעזרה הגיעה. בחלונות כאלה השירות החזיר 5–7% שגיאות, ותור הבקשות גדל מהר יותר משהספיקו לטפל בו.

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

מה שינו ומה קיבלו

השירות הועבר ל-Azure Virtual Machine Scale Sets עם סקיילינג אוטומטי לפי שלושה אותות: עומס המעבד, אורך תור הבקשות ומספר החיבורים הפעילים. הגדלת הצמתים הוגדרה אגרסיבית — כמה מכונות בכל צעד, וההקטנה שמרנית ועם תקופת צינון, כדי שהקבוצה לא "תרעד" בהפרצות קצרות.

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

התגובה לשיא הצטמצמה ל-2–3 דקות במקום 40–60, שיעור השגיאות בחלונות השיא ירד מתחת ל-0.5%, והזמן המת — משעתיים בחודש לדקות בודדות ברבעון. מספר המכונות מחוץ לשיאים פחת בחצי: הקיבולת כעת עוקבת אחרי העומס, ולא אחרי התרחיש הגרוע ביותר.

מה לעשות אם חלק מהשירותים כבר פועל על שרתים משלו?

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

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

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

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

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

ספקות טכניים: מדדים, חימום ונסיגת תצורות

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

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

מה קורה לחיבורים הפעילים כאשר מופע מוסר?

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

כיצד לבטל כלל כושל בלי לפרק את המתאר ידנית?

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

נדון במשימה ונחזור עם תוכנית הטמעה

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

מה עוזר לקבל הערכה מדויקת והרכב עבודות:

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

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