הטמעת תכנון קיבולת על בסיס מדדי עומס

למה capacity planning נשבר בעומס אמיתי

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

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

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

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

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

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

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

מה נותן capacity planning על בסיס מדדי עומס

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

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

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

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

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

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

גישות לתכנון קיבולת: השוואת מצבים

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

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

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

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

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

מה מעבירים לידיים: ארטיפקטים ותקנוני עבודה

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

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

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

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

לפני: ירידת ביצועים בשעות שיא

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

אחרי: מדדים ועתודה מבוקרת

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

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

במה תכנון לפי מדדים שונה מחישוב לפי שיאים?

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

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

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

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

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

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

ספקות טכניים סביב תכנון קיבולת

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

אין לנו כמעט מדדים — מאיפה להתחיל?

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

האם זה תואם לניטור שלנו?

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

כמה זמן לוקח היישום?

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

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

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

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

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

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