הגדרת סקיילינג אוטומטי של Kubernetes (KEDA — סקיילינג מבוסס אירועים)

KEDA: מדוע התורים גדלים והצמתים עומדים בטלים

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

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

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

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

מה נותן סקיילינג מבוסס אירועים

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

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

ארבעה אפקטים שנראים במדדים:

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

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

מצבי סקיילינג אוטומטי: KEDA והמנגנונים הסטנדרטיים

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

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

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

שלבי ההטמעה: מביקורת עומס ועד מסירה

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

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

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

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

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

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

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

מה נשאר אצל הצוות: קונפיגורציות KEDA ותקנות

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

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

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

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

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

מה עשינו

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

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

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

במה KEDA שונה מהסקיילינג האוטומטי הסטנדרטי

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

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

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

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

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

ספקות טכניים: מגבלות ותאימות

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

מה לעשות אם המדד מגיע חלקית או באיחור?

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

כיצד לחזור אחורה אם ההתנהגות לא תמצא חן בעיניכם?

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

האם העומס על מערכת המדדים לא יגדל?

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

נדון במשימה: מה נדרש להערכה ולתוכנית

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

מה אנו מבקשים בהתחלה:

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

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