מדיניות מחזור חיים באחסון אובייקטים — מחיקה אוטומטית וארכוב

Lifecycle policies: מדוע האחסון גדל ללא בקרה

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

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

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

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

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

מה משתנה לאחר הטמעת כללי שמירה

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

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

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

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

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

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

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

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

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

סדר ההגדרה של lifecycle policies: שלבי העבודה

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

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

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

ערכת תיעוד, סכימות ותקנות

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

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

מקרה בוחן: כיצד מאגר הקבצים הפסיק לגדול

מצב התחלתי

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

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

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

מה הוגדר

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

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

מדדים לפני ואחרי

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

במה כלל מחזור חיים שונה מניהול גרסאות?

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

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

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

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

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

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

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

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

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

כיצד להחזיר אובייקט שנמחק בטעות?

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

כיצד לבדוק כלל בלי לאבד נתונים?

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

האם אפשר לשנות את תקופת השמירה לאחר הפעלת הכלל?

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

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

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

מה להכין לשיחה:

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

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