אופטימיזציה של עלויות ענן: Kubecost, Infracost, Cost Anomaly

ניהול עלויות ענן: היכן דולף תקציב הענן

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

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

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

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

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

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

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

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

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

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

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

שיטות חישוב עלויות ב-Cloud: השוואת גישות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: איך עצרנו את גידול הוצאות הענן

מה היה

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

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

מה שינינו

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

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

מה נהיה

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

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

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

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

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

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

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

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

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

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

ספקות טכניים: שאלות של מהנדסים

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

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

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

מתי יופיעו הנתונים הראשונים ואיך להבדיל בין אנומליה חד-פעמית לגידול מערכתי?

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

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

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

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

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

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