הגדרת אחסון לוגים לטווח ארוך (S3/Glacier/Cold Storage)

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

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

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

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

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

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

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

מה נותנת רוטציה מנוהלת: מהירות חיפוש ומחלקות כשל

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

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

מהירות חיפוש: כיצד משתנה זמן חקירת התקרית

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

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

נפח המסלול החם ומחלקות הכשל שנעלמות

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

מסלולים פושרים וקרים: כיצד משתנה הגישה ללוגים

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

מסלול חם: גישה מיידית לניתוח פעיל

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

שכבה קרה: פשרה בין השהיה לנפח

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

שלבי הפרויקט: מניתוח זרמים ועד מסירת תקנונים

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

ביקורת זרמים והערכת נפח

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

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

בדיקת שלמות וקבלת הייצוא

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

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

מה נשאר בידיים: תרשימי זרמים, מדיניות גישה, תקנונים

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

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

מדיניות גישה והפרדת תפקידים

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

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

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

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

מה היה לפני ההטמעה ומה השתנה

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

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

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

צמצום האחסון החם נתן לא רק מקום: החיפוש אחר האירוע הנדרש בתקרית הואץ מ-15–20 דקות ל-20–40 שניות, מפני שהשאילתה פועלת על אינדקס שנאסף מראש לתקופה הנגועה, ולא על כל המערך. שיעור הייצואים שהסתיימו באי-התאמות ירד מ-7–8% לאפס, וחקירת תקלות כבר אינה תלויה בניחושים ידניים של התורן.

מה לעשות אם חלק מהלוגים כבר אבד ללא אפשרות שחזור?

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

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

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

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

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

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

שלמות, גישה ושחזור: ספקות טכניים

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

מי מקבל גישה לארכיון?

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

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

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

מה להציג לבודקים ואיך לא לשלם על מיותר?

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

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

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

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

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