הטמעת סקיילינג מונע של Kubernetes לפי לוח זמנים

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

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

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

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

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

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

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

מה נותנת ההיערכות של האשכול לשיאי עומס

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

צמצום זמן ההשבתה בשעות השיא

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

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

פחות תיקונים ידניים ופחות קריאות לילה

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

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

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

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

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

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

המצב המתוכנן וגבולותיו

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

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

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

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

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

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

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

ביקורת פרופיל העומס והמלאים

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

תיאום הספים והחלונות

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

תיעוד, תרשימים ותקנונים בתפוקה

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

ערכת התצורות והתרשימים

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

תקנון תורנויות ונסיגה

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

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

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

מה היה לפני ההטמעה

חלק הכשלים בשיא בתהליך ביצוע ההזמנה נע בטווח של 7–9% — כבערך כל לקוח עשרים עזב עם שגיאה. האשכול נכנס למצב עבודה 12–18 דקות אחרי תחילת הגידול, כלומר התעבורה היקרה ביותר עובדה על הקצה.

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

מה השתנה לאחר מכן

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

חלק הכשלים בשיא ירד ל-0,2–0,4%, היציאה למצב עבודה אורכת פחות מדקה, וההתערבויות הידניות בלילה הצטמצמו לאחת-שתיים בחודש ורק באירועים אמיתיים. צריכת הקיבולת במישור לא גדלה: לוח הזמנים מכווץ את האשכול באותה משמעת שבה הוא מרחיב אותו.

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

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

הקונפליקט מופיע במקום שבו שני המנגנונים שולטים באותה величине. הפחתת מספר העותקים לפי מטריקה פועלת בתוך דקות, ולוח הזמנים כעבור רבע שעה מעלה אותם שוב לקראת שטף הבוקר — האשכול מתנדנד, וחלק מהבקשות עובר להמתנה.

Horizontal Pod Autoscaler בצירוף כזה מוגבל מלמטה, כדי שהמטריקה לא תוכל לרדת מתחת לסף שלוח הזמנים כבר חישב כבטוח.

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

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

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

ספקות טכניים: עמידות בתקלות, מגבלות ונסיגה

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

מה יקרה בשיא עומס בלתי מתוכנן?

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

עד כמה מדויק פרופיל העומס?

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

אפשר להפעיל זאת במעגל חי?

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

מה עם מגבלות המשאבים?

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

מי אחראי על צמתים מיותרים?

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

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

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

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

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