ניקוי אוטומטי של משאבי ענן: היכן מתחילה הדליפה
דליפת משאבי ענן מתחילה במקום שבו משאב נוצר למשימה מסוימת, ולאחר השלמתה ממשיך להתקיים. בAmazon Web Services כרך אינו נמחק יחד עם המופע כברירת מחדל — ולאחר פירוק הסביבה הוא ממשיך להיות מחויב. כרך אחד כזה אינו מורגש, אך לאחר עשרה סבבי סביבות מצטברת שכבה שאיש מעולם לא בדק.
ב-Kubernetes הדליפה זורמת בערוצים משלה: בקשות ל-Persistent Volumes נותרות לאחר מחיקת ה-namespace, שירותים מסוג LoadBalancer תלויים ללא עומסי עבודה, snapshot ותמונות ישנים מצטברים ב-registry. התפשטות התשתית מואצת מכך שמשאבים נוצרים אוטומטית בעת אספקת גרסאות חדשות, אך נמחקים ידנית ומהזיכרון.
מאזני עומס שאינם בשימוש וכרכים יתומים מסוכנים לא רק בגלל עליית עלויות: הם מעוותים את התמונה בעת חקירת אירועים ויוצרים תלויות שווא בתכנון קיבולת. ביקורת ידנית פעם ברבעון מתיישנת ברגע סיומה — בין הבדיקות מספיקות לעבור כמה מהדורות וניסויים.
אנו מפרטים כיצד הדבר נסגר: כללים לניקוי אוטומטי של משאבי ענן, הנקשרים לתג בעלים ולתוחלת חיים, ביקורת שגרתית של יתומים בכל סוגי המשאבים, ומחיקה עם חלון הסגר כדי שהחזרה לאחור תישאר אפשרית.
מה מספק מחזור חיים מנוהל של משאבים
כללי מחזור חיים הופכים את הניקוי מאוסף של פעולות ידניות להצהרה: לכל משאב מופיעים תוחלת חיים, תנאי הארכה ובעלים. בהמשך האפקט מתפרק לארבעה מדדים מדידים הנראים בניטור, ולא מתוארים במילים.
מהירות פריסה וזמן התאוששות
מהירות הבנייה והפריסה גדלה לא בגלל הכללים עצמם, אלא מכך שהסביבה מפסיקה לצבור אשפה. מטמון בנייה, כרכים זמניים ומרחבי שמות לבדיקות מתפנים לפי לוח זמנים, ולכן קו מתאר חדש עולה לפי הצהרה נקייה, ללא חיפוש ידני אחר אובייקטים מתנגשים.
זמן ההתאוששות לאחר תקלה תלוי בכמה מהר מתפנים שמות, כרכים ומכסות תפוסים — באשכול אלה הישויות הנדירות ביותר. כאשר כלל מסיר אובייקטים תקועים עם פקיעת התוקף, ההתאוששות מתבצעת בדקות במקום בהמתנה שמישהו ישחרר את המשאב ביד.
צמתים לא מנוצלים ופעולות ידניות
שיעור הצמתים הלא מנוצלים מחושב כיחס בין הקיבולת המבוקשת לצריכה בפועל. סקיילינג אוטומטי מפחית אותו, אך אינו מאפס אותו: נותרות חלונות לילה, סביבות לאחר הדגמות, צמתים למשימות חד-פעמיות. הכללים מסירים בדיוק את היתרה הזו ומחזירים אותה למאגר המשותף.
צמצום הפעולות הידניות הוא השיעור של משאבים שהתפנו ללא מעורבות מהנדס. אנו מביאים אותו לערכים שבהם הניקוי הידני נותר רק לחריגים, וכל חריג נרשם ביומן. כך קו המתאר הופך לצפוי: תנאים זהים מניבים תוצאה זהה ואינם תלויים במי שנמצא היום בתורנות.
מצבי ניקוי: לפי תוקף, לפי אירוע, לפי מדד
מצב הניקוי קובע לפי איזה סימן הכלל מחשיב את המשאב כמנוצל. ב-AWS ובאשכול סימנים כאלה חיים ברמות שונות: תוחלת החיים של גרסת תמונה, אירוע במחזור החיים של הסביבה, עומס הדיסק בפועל. ערבוב רמות בכלל אחד מביא לכך שהניקוי מוחק את מה שהכלל הסמוך נשען עליו.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| לפי תוחלת חיים | זרימת בנייה צפויה, registries של תמונות, snapshot וגיבויים | אינו יודע על נחיצות אמיתית: משאב נדיר אך חי נמחק יחד עם האשפה |
| לפי אירוע | סביבה לאחר עצירה, ענף לאחר מיזוג, משימה לאחר סיום | דורש אספקה מובטחת של האירוע: התראה שאבדה משאירה את המשאב לנצח |
| לפי מדד | דיסקים, צמתים ומאזני עומס שמשולמים אך אינם בשימוש | נדרשים תגים ובעלים של משאבים, אחרת הכלל יפיל סביבה פעילה בירידת עומס |
תוחלת חיים ואירוע: צפויות מול דיוק
תוחלת חיים פועלת ללא תלויות חיצוניות — מספיק תג עם תאריך ומעבר תקופתי על הרשומה. היא נשברת בחריגים: מדיניות שמירה חייבת להשאיר כמה אובייקטים אחרונים לכל גרסה, אחרת חזרה למהדורה הקודמת תהפוך לבלתי אפשרית. ניקוי לפי אירוע מדויק יותר, אך נשען על אספקת התראה על סיום משימה או מיזוג ענף.
ניקוי לפי מדד: נדרשים תגים ובעלים
ניקוי לפי מדד נשען על העומס בפועל: דיסק לא מנוצל, צומת ללא עומס, מאזן עומס ללא פניות. כאן לא ניתן להסתדר בלי תגים ובעלים של משאבים — הכלל חייב לדעת של מי המשאב ולאיזה תוקף הוא שייך, אחרת הוא יפעל על סביבה חיה ברגע שפל. סכימה עובדת היא לשלב: תוקף כביטוח מפני אובייקטים חיים לנצח, מדד כעילה למחיקה מוקדמת.
שלבי יישום: ממיפוי מלאי ועד מסירה
סדר השלבים כאן אינו פורמליות. אם מתחילים מיד עם כללי מחיקה, האוטומציה תפיל את מה שהצוות עוד לא הספיק לתייג: כרכים יתומים, snapshot ללא בעלים, קווי מתאר לבדיקות שכולם שכחו מהם. לכן תחילה רישום ותגים, לאחר מכן מצב תצפית, ורק אז הפעלת המחיקה.
- מיפוי מלאי של משאבים ובעלים. אוספים רשימה מלאה: כרכים, snapshot, מאזני עומס, אשכולות, סביבות ישנות. בנפרד מוציאים את מה שנוצר ידנית ואינו מתואר בקונפיגורציה — דווקא כאן הסיכון העיקרי.
- סכימת בעלות. לכל יחידה — תג של צוות, סביבה ומחלקה: פרודקשן, בדיקות, חד-פעמי. מה שלא הצליח להתאים לבעלים עובר לרשימה נפרדת לבדיקה, ולא למחיקה.
- מצב תצפית. הכללים פועלים באופן סרק ורק כותבים דוח על מה שהיה נמחק. במשך שבועיים עד ארבעה שבועות משווים את הדוח לצריכה בפועל ומתקנים ספים.
- הגדרת כללי מחיקה. תוחלת חיים נקבעת לפי מחלקות משאבים, חריגים — לפי תגים, והמחיקה עצמה נדחית ובעלת חלון ביטול. snapshot וגיבויים מוצאים אל מחוץ לכלל.
- בדיקת הכללים בסביבת בדיקות. יוצרים משאבים עם תוקף שפג ומוודאים שרק היעד מוסר, ונקודת השחזור נשארת פעילה.
- מסירת נהלים. מתעדים תוקפים לפי מחלקות, תגי חובה, סדר הארכה ובקשת חריג, ונקודות חזרה לאחור.
מה מתעדים בנהלים
הנוהל מתאר לא רק תוקפים, אלא גם כיצד להאריך משאב: תג, בקשה של הבעלים, חריג אוטומטי לתקופה מוגדרת. בלי זה מהנדסים עוקפים את האוטומציה ידנית, והניקוי מפסיק לעבוד בשקט.
מדיניות שמירה, סכימות ונהלים בתוצר
הפרויקט נסגר לא כשהכללים התחילו לעבוד, אלא כשהצוות יכול לשנות אותם ללא המחבר. לכן בערכה נכללים לא רק קונפיגורציות, אלא גם מדיניות שמירה, סכימת תיוג משאבים, מטריצת הרשאות ונוהל תגובה — הכול לצד הקוד, ולא בהתכתבות.
מדיניות, תיוג ותפקידים
- מדיניות שמירה: תוחלת חיים לכל מחלקת משאבים — דיסקים שאינם בשימוש, snapshot, תמונות ישנות, אשכולות בדיקה, מאזני עומס וכתובות «יתומים».
- סכימת תיוג משאבים: תגי חובה של בעלים, סביבה ותוחלת חיים; בלעדיהם המשאב נכנס לדוח, ולא למחיקה.
- מטריצת הרשאות ותפקידים: מי משנה מדיניות, מי רק מתייג משאבים, מי מאשר מחיקה בלתי הפיכה.
- רשימת תגים מוגנים וחריגים: חלונות ראווה, נתונים עם תוקף ארוך, משאבים לצורכי ביקורת וחקירת אירועים.
תיעוד ונהלים
- הוראות תפעול: היכן נמצאים הכללים, כיצד לבדוק הפעלה וכיצד להחזיר את המחיקה האחרונה.
- יומני אירועים ודוחות: מה נמחק, מה יזם זאת, מה עבר להסגר לפני המחיקה.
- נוהל תגובה של משמרת תורנות: סדר הפעולות במקרה של הפעלה שגויה, במקרה של משאב שהוחמץ, ובמקרה של עצירת משימות הניקוי.
ערכה כזו שורדת גם חילופי צוות וגם החלפת קבלן: הכללים נקראים לפי התיוג, ולא משוחזרים מזיכרון המהנדס.
מקרה בוחן: כיצד צומצמה התפשטות התשתית פי שלושה
הלקוח הגיע עם צריכה גדלה של משאבי ענן וללא תשובה לשאלה מה בדיוק צורך אותם. מיפוי המלאי הראה תמונה מוכרת: snapshot של דיסקים הצטברו לאחר כל בנייה, כרכים נותרו לאחר מחיקת סביבות בדיקה, ב-registry המקומי שקעו תמונות של כל הבניות, כולל מבוטלות.
אשכול האורקסטרציה חי עם זה כמה שנים — מספר האובייקטים גדל בכ-8% בחודש, ושליש מהם לא היה משויך לשום שירות פעיל.
לכל מחלקת אובייקטים תיארנו כלל של מחזור חיים ואספנו אותם לשני קווי מתאר בלתי תלויים — ענן ואשכול. snapshot מעבר לתוקף מוגדר נמחקים, כרכים ללא שיוך עוברים להסגר לשבוע, ב-registry נשארות עשר התמונות האחרונות לכל תג, והשאר מנוקה. בנפרד בדקנו שהכלל אינו פוגע במשאבים המתויגים כקבועים.
מה לא הלך לפי התוכנית
הגרסה הראשונה של הכללים מחקה כרכים שמהנדסים הקימו ידנית לחקירת אירועים: במהלך הלילה הוסרו חלק מסביבות האבחון יחד עם הלוגים.
עיבוד החריגים עובד מחדש — מה שמתויג כמוגן הכלל מתעלם ממנו, כל מחיקה עוברת דרך חלון הסגר, וכללים חדשים פועלים במשך שבוע במצב הרצה יבשה עם דוח על מה שהיה נמחק. לאחר מכן מקרי אובדן הנתונים לא חזרו על עצמם.
המדדים נלקחו על אותו מלאי לפני ואחרי:
- שיעור המשאבים שהתפנו — כשליש מהאובייקטים בקו המתאר;
- אובייקטים ללא בעלים: משליש ועד אחוזים בודדים;
- נפח ה-registry של התמונות הצטמצם פי שלושה;
- מיפוי מלאי לפני מיגרציה — יום אחד במקום שבוע.
התפשטות קו המתאר נעצרה: הגידול במספר האובייקטים הוחלף בירידה הדרגתית, והכללים ממשיכים לפעול ללא התערבות ידנית.
מה לעשות אם האשכול כבר התפשט?
קו מתאר שהתפשט לא ניתן לנקות בלחיצת כפתור אחת: מחיקת משאב שמישהו מחזיק «ליתר ביטחון» שוברת את הסביבה. לכן השאלה הראשונה אינה «אילו כללים להפעיל», אלא «מה כבר הצטבר ומי אחראי לכך».
מכאן שני נתיבים עובדים: ביקורת חד-פעמית של המצטבר, והטמעה הדרגתית של כללים שמנקים את המשאבים בהמשך בעצמם.
ביקורת חד-פעמית — מיפוי מלאי לפי תגים, מדדי צריכה ובעלים. מפרידים יתומים — כרכים מנותקים ב-Kubernetes, snapshot ישנים, כתובות בלתי תפוסות, קבוצות צמתים לא מנוצלות — מעומסים חיים ומוציאים רשימות לאישור הבעלים. המחיקה מתבצעת במנות, עם יומן וחזרה לאחור במקום שבו השחזור בכלל אפשרי.
הטמעה הדרגתית מתחילה במצב תצפית: הכללים פועלים, אך אינם מוחקים, אלא רק כותבים מה היו מוחקים. כעבור שבועיים היומן עצמו מראה את סדרי העדיפויות של הניקוי, ואת הכללים מעבירים למחיקה עם תוקף נדחה לפי תג — החל מסביבות לא קריטיות.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| ביקורת חד-פעמית | הצטבר היקף גדול של יתומים, יש חלון לבדיקה | נדרשות אישורים של בעלים, קיים סיכון לפגוע במשהו חי |
| הטמעה הדרגתית של כללים | קו המתאר פעיל, אין לעצור את הפרודקשן | האפקט נדחה, נדרשת תקופת תצפית |
| היברידי: ביקורת בתוספת כללים | כמה חשבונות וצוותים | יותר תיאום בין הבעלים |
סדר העבודות בדרך כלל זהה: תחילה מה שאינו משפיע על הפרודקשן — כרכים ו-snapshot יתומים, תמונות מיושנות, כתובות פנויות; לאחר מכן קיבולת לא מנוצלת; ורק אחר כך כללים לעומסי עבודה.
סיכוני מחיקה והגנה מפני הפעלות שגויות
הפעלה שגויה עולה יותר מהאחסון שנחסך: כלל שנבנה על גיל המשאב סופו להסיר פעם סביבה שהלקוח כבר נקשר אליה. לכן הניקוי מתבצע בשני קווי מתאר — תחילה האובייקט מסומן כמועמד למחיקה והבעלים מקבל התראה, המחיקה עצמה מתבצעת בשלב שני, לאחר חלון אישור. עבור סביבות עם מחזור חיים ארוך החלון נעשה גדול יותר, ולזמניות — קצר יותר.
משאבים מחוץ לתבניות וכל מה שנוצר ידנית — האוטומציה כברירת מחדל אינה נוגעת בהם: ללא תג של בעלים וסביבה האובייקט נכנס רק לדוח לבדיקה ידנית. חריגים מהכללים מוגדרים באותם תגים — כך קו מתאר חדש אינו נופל לניקוי במקרה.
כיצד הכלל יבחין בין משאב זמני לקבוע?
הסימן העיקרי — תגים: בעלים, סביבה, תוחלת חיים. אובייקט ללא תג אינו נמחק, אלא נכנס לרשימת החריגים ולדוח היומי — לכן סביבות ותיקות וקווי מתאר לבדיקות נותרים ללא פגע.
מה מגן מפני מחיקה במקרה של הפעלה שגויה?
הגנה מפני מחיקה על אובייקטים קריטיים, סכימה דו-שלבית ומצב בדיקה ללא החלה: הכלל תחילה מציג מה בדיוק יימחק, ורק אחר כך פועל. החזרה לאחור — מ-snapshot של הכרך שנוצר לפני המחיקה.
האם נוצרים עותקים ומה קורה ליומנים?
לפני מחיקת כרך נלקח snapshot, היומנים נטענים לאחסון אובייקטים עם תוחלת שמירה משל עצמם — נפרדת מתוחלת החיים של המשאב עצמו. הנתונים נותרים זמינים לבדיקה גם לאחר שהאובייקט נמחק.
נדון במשימה: מה נדרש מכם וכיצד נתחיל
«ניקוי אוטומטי של משאבי ענן» מתחיל לא מכללי מחיקה, אלא ממיפוי מלאי: כדי שהמדיניות לא תפיל כרך או אשכול פעילים, יש לדעת בדיוק מה יש לכם ומי אחראי לכך. לכן סדר הפתיחה תמיד זהה — ניתוח נתוני המקור, הערכה ותוכנית עבודה, ותיאום פיילוט על קו מתאר אחד.
מה יועיל לנו מכם בפתיחה:
- רשימת חשבונות ענן, פרויקטים ואשכולות הנכללים במשימה;
- ייצוא מלאי או גישה לחיוב במצב קריאה — ממנו רואים מה באמת מצטבר;
- כללי תיוג ותגים קיימים: בלעדיהם הכלל «למחוק הכול ללא תג בעלים» מסוכן;
- רשימת משאבים שאין לגעת בהם לעולם — נתוני פרודקשן, גיבויים עם תוקף ארוך, ארכיונים רגולטוריים;
- חלונות תחזוקה ואחראי מצדכם, המאשר מחיקות;
- ערוץ התראות — לאן לשלוח דוח על כללים שפעלו.
מצדנו נדייק את גבולות השמירה לפי מחלקות משאבים, נפריד בין קווי מתאר שבהם הכלל רק רושם הפעלות, לבין אלה שבהם הוא כבר מוחק, ונגדיר את סדר החזרה לאחור: כמה גרסאות נשמרות, וכיצד משחזרים מחיקה שגויה.
לאחר מכן נחזור עם הערכה ותוכנית: שלבי העבודה, מה אנחנו מכסים, מה נותר מצדכם, והרכב הליווי בפיילוט. תארו את המשימה — ניתן תוכנית עם שלבים ואזורי אחריות.