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

למה אוטוסקיילינג של kubernetes לא עומד בקצב העומס

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

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

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

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

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

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

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

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

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

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

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

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

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

מצבי אוטוסקיילינג של kubernetes לפי אופי עומס שונה

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

השוואת מצבי אוטוסקיילינג

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

איך עוברת ההטמעה: מביקורת עומס ועד מסירה

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

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

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

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

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

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

קונפיגורציות, סכימות ותקנונים שנשארים אצלכם

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

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

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

לפני: הרחבה ידנית לפי התראה

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

בחלון הזה שכבת הפרונט נחנקה: שיעור תגובות 5xx בשיא הגיע ל-7–9%, וחלק מההזמנות אבד ללא תקנה. תורנויות בעונה הפכו להעלאות ליליות 4–6 פעמים בשבוע. זה סוג כשל שנקבע לא לפי מלאי החומרה, אלא לפי מהירות התגובה לגידול בעומס.

אחרי: אוטומציה לפי מדדי עומס

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

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

התגובה לגידול הצטמצמה מ-25 דקות ל-90 שניות, שיעור 5xx בשיא — מ-7–9% ל-0,3%. התערבויות ידניות בעונה — אפס במקום 4–6 בשבוע, ובשעות שקטות מספר הרפליקות הפעילות יורד מעצמו: המשאבים המוקצים בין העונות הצטמצמו בערך פי שלושה. חזרנו לתיקונים רק כשנצרך להעלות את סף ההפעלה עצמו.

במה שונה קנה מידה אנכי מקנה מידה אופקי?

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

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

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

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

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

מה יקרה להגדרות הידניות?

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

איך מבצעים נסיגה של שינויים אם משהו משתבש?

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

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

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

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

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

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

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