Azure Blob Storage: היכן נשבר אחסון האובייקטים
אחסון אובייקטים נראה כמו השירות הפשוט ביותר בענן: יצרתם קונטיינר, נתתם הרשאה, העליתם קבצים. הבעיות מתחילות מאוחר יותר — כשכלי Azure Blob Storage הופך למזבלה של לוגים, ייצוא נתונים, קבצים מצורפים של משתמשים ודאמפים של בסיסי נתונים.
התפשטות הנתונים מתרחשת בלי משים: הקונטיינר גדל, אבל תשובה ברורה לשאלה «מה כאן נחוץ» אין לא לפיתוח ולא לתפעול.
התפשטות הנתונים פוגעת בשני מקומות בבת אחת. התשלומים עבור אחסון ותפעול עולים, והמלאי של התוכן הופך לבדיקה ידנית של שעות רבות.
קטגוריית סיכון נפרדת — קישורים ציבוריים לקבצים: קונטיינר עם גישה פתוחה לקריאה מוסר קובץ מצורף לכל מי שיודע את הכתובת, וזה מתגלה, בדרך כלל, בבדיקת אבטחה, ולא לפני כן.
הכשל הטיפוסי השלישי — פעולות ידניות במקום קונפיגורציה. קבצים מועלים בסקריפטים בלי ניהול גרסאות, הרשאות ניתנות דרך הפורטל «בעין», כללי מחזור החיים אינם מוגדרים, וגרסאות ישנות יחד עם העלאות שלא הושלמו מחויבות בתעריף במשך שנים. במקביל, אין במה לשחזר rollback או ביקורת גישה: אין היסטוריה, אין תפקידים ואין תרשים שניתן לשחזר.
אנחנו מפרטים כיצד זה נסגר: הגדרת אחסון קבצים כקוד, כללי מחזור חיים לפי תגיות וגיל אובייקטים, גישה דרך תפקידים וטוקנים קצרי-מועד במקום מפתחות רחבים.
מה נותן אחסון אובייקטים מנוהל
אחסון אובייקטים מנוהל אינו שירות נפרד, אלא שכבת מדיניות מעל Azure Blob Storage: קונטיינרים, הרשאות וכללי מחזור חיים מתוארים בקוד ומנוהלים בגרסאות יחד עם שאר התשתית.
המהנדס אינו נכנס לקונסולת האינטרנט כדי ליצור אחסון או לתת הרשאה — השינוי עובר בדיקה ומגיע לסביבה באותו נתיב שבו מגיעה האפליקציה.
זמן שחזור הנתונים מתקצר משעות לדקות. ניהול גרסאות של אובייקטים שומר מהדורות קודמות של הקובץ, ומחיקה הפיכה משאירה עקבות גם אחרי פקודת מחיקה: שחזור לאחר כשל בייצוא או סקריפט כושל הוא החזרת גרסה מסוימת, ולא חיפוש עותק בדיסקים זרים והתכתבות עם ספק.
מחלקה נפרדת של כשלים נעלמת יחד עם ניהול קבצים ידני. ההרשאות ניתנות דרך תפקידים ברמת הקונטיינר, מפתחות גישה אינם מפוזרים בקונפיגורציות ובהתכתבויות, ומדיניות אינה נערכת ידנית — לכן «מחקנו את הלא-נכון» ו«ההרשאה נשארה אצל ספק שפוטר» מפסיקים להיות סיפורים שגרתיים. הגישה נבדקת לפי תפקיד, ולא לפי מי שנשאר לו המפתח.
הפחתת הוצאות האחסון מושגת לא בקיצוץ, אלא בכללים: נתונים שנתבקשים לעיתים רחוקות עוברים לשכבות קרות, גרסאות ישנות ובלוקים שלא הושלמו מנוקים לפי לוח זמנים, והנפח מפסיק לגדול מעצמו. הצמיחה הופכת לצפויה — רואים כמה תופס כל כיוון נתונים ואיזו תוספת נותן מקור חדש.
אפשרויות פריסה ומצבי גישה
בחירת התרשים נקבעת בשתי שאלות: מאיפה מגיעות הפניות לנתונים וכמה בקפדנות יש לבודד את התעבורה. אותו שירות יכול להתקיים במעגל ציבורי, מאחורי ערוץ פרטי או בתרשים היברידי — לכל אפשרות המגבלות שלה, והן מתגלות לא בהתחלה, אלא בעת הרחבה או ביקורת חיצונית.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| גישה ציבורית לפי מפתח או כתובת חתומה | ספקים חיצוניים, החלפות חד-פעמיות, דיבאג | המפתח דולף יחד עם המאגר או הלוגים; רוטציה ידנית; התעבורה עוברת דרך האינטרנט |
| הגבלה לפי רשתות משנה וכתובות | שירותים פנימיים בענן וגישה מהמשרד | הכללים מתקיימים בנפרד מהקוד; במעבר או בשינוי כתובות הגישה נשברת בשקט |
| רשת פרטית עם נקודת חיבור | נתונים אישיים, דרישות רגולטור, מערכות פנימיות | יקר יותר לתחזוקה: אזור DNS פרטי, תיאום נתיבים, נתיב נפרד לאבחון |
| מספר חשבונות אחסון | סביבות, צוותים או מחלקות נתונים שונים | גדל מספר המקומות שבהם מגדירים כללים וחשבונות; יש צורך בתבנית אחידה וביומן משותף |
| תרשים היברידי: נתונים חמים בענן, ארכיון בתשתית שלכם | דרישה לשמור חלק מהנתונים מקומית | שני סטים של מדיניות ושני מוניטורים; ללא סנכרון תגיות ותקופות שמירה הנתונים מתפזרים |
בפועל מרכיבים את התרשים מכמה שורות בטבלה: שכבה חמה בענן מאחורי רשת פרטית, ארכיון בחשבון נפרד עם תקופות שמירה ארוכות, והגישה ניתנת דרך תפקידים לקונטיינר מסוים, ולא לחשבון כולו. סט כזה מתואר בקוד, לכן מצב הגישה משתנה בעריכת התבנית, ולא בהגדרה ידנית בקונסולה.
שלבי הטמעת האחסון: מביקורת עד מסירה
העבודה מתנהלת ברצף: כל שלב עוקב נשען על התוצרים של הקודם. כך המעבר אינו הופך לניסוי על מעגל הפרודקשן, וכללי הגישה והאחסון מתוארים לפני שב-Azure Blob Storage יופיע האובייקט הראשון.
-
ביקורת אחסון הנתונים. מלאי של קונטיינרים, נפחים, פרופילי קריאה וכתיבה, מקורות נתונים ותקופות החיים שלהם. אנחנו מתעדים מה שייך לנתונים חמים, מה לארכיון, ואיפה יש כעת כפלים או סטים «מיותמים».
-
תרשים האחסון. חלוקה לקונטיינרים ולרמות גישה: איזה סט לאן מגיע, באיזו תדירות פונים אליו, מהן הדרישות לאחסון ולמחיקה. התרשים מאושר לפני כתיבת הקוד.
-
תיאור התשתית כקוד. מודולי Terraform לחשבון, לקונטיינרים, למגבלות רשת ולניהול גרסאות. כל שינוי עובר ביקורת, והסביבה משוחזרת מאפס בפקודה אחת.
-
תפקידים והרשאות גישה. הפרדה ברמת המינוי, קבוצת המשאבים והקונטיינר, חשבונות נפרדים לאפליקציות ולאנשים, סט ההרשאות המינימלי הנדרש. אנחנו בודקים שלשירות אין גישה מיותרת.
-
מדיניות מחזור חיים. כללים להעברת אובייקטים לרמות קרות, מחיקת גרסאות קודמות ובלוקים שלא הושלמו, תקופות שמירה. המאגר מפסיק לגדול ללא שליטה, והשחזור למצב קודם נשאר אפשרי.
-
העברת נתונים. תחילה סט פיילוט: מודדים מהירות, שלמות לפי סכומי ביקורת, התנהגות בעת ניתוק החיבור. לאחר מכן הזרם הראשי — עם אפשרות להשלמה ללא עצירת המקורות.
-
בדיקה ומסירה. בדיקות גישה ועמידות בתקלות, הגדרת ניטור והתראות, תיעוד השינויים. אנחנו מוסרים קוד, תרשים והוראות לצוות שלכם — התחזוקה נשארת בפנים.
מה אנחנו מוסרים לידיים לאחר ההטמעה
אנחנו מוסרים לא סט קונפיגורציות «כמו שיצא», אלא מערכת עובדת שהמהנדס שלכם יוכל לפתח ולתחזק בלעדינו. להלן מה שנותר פיזית במאגר ובנהלים, ומה שאנחנו עוברים יחד בקבלה.
- תרשים מיקום הנתונים — אילו קונטיינרים וחשבונות נוצרו, היכן הגבולות של השכבות החמות והארכיוניות, כיצד המשאבים מחולקים לפי סביבות.
- קונפיגורציית האחסון — מתוארת באופן הצהרתי: מודולים, משתנים לכל סביבה, מצב מבודד. פריסה מאפס משחזרת את הפרודקשן ללא עריכות ידניות.
- תפקידי גישה — רשימת ההקצאות לפי קונטיינרים, חשבונות שירות של אפליקציות, הרשאות מינימליות מספיקות. מפתחות אינם נשמרים בקוד ובקונפיגורציות.
- מדיניות מחזור חיים — כללים להעברה לשכבות קרות, ניהול גרסאות, מחיקה רכה והגנה מפני מחיקה המונית. המאגר מפסיק לגדול ללא שליטה.
- נוהל גיבוי — מה מגובה, באיזו תדירות, היכן נמצאת העותק, מי מאשר את השחזור ולפי אילו בדיקות.
- תיעוד האחסון — מפת משאבים, תרשים קשרים, אחראים, סדר הוספת קונטיינר חדש ופעולות טיפוסיות.
- ניטור והתראות — סט אותות לפי זמינות, כשלי הרשאה והתמלאות, עם שיוך למשמרת תורנית.
בקבלה אנחנו עוברים על הרשימה יחד עם המהנדס שלכם: פורסים את האחסון מאפס, נותנים ומבטלים הרשאה, משחזרים אובייקט מעותק. סעיפים שאינם משוחזרים נשארים בעבודה עד לתיקון.
מקרה בוחן: מעבר של אחסון קבצים, מדדים לפני ואחרי
הלקוח עבד על דיסק רשת משותף: הרשאות לתיקיות ניתנו ידנית, ומשימות ההעתקה הליליות לא הספיקו אחרי גידול הנתונים. שחזור לגרסה קודמת של קובץ היה אפשרי רק מגיבוי וארך שעות, וחלק ממסמכי העבודה התקיימו בעותק יחיד.
פרשנו את מבנה הדיסק לקונטיינרים ולקידומות ב-Azure Blob Storage, העברנו את הגישה לתפקידים ברמת הקונטיינר, ואת כללי האחסון תיארנו באופן הצהרתי — מדיניות מחזור החיים נמצאת כעת במאגר ועוברת בדיקה לפני יישום.
מה השתנה במספרים
| מדד | לפני | אחרי |
|---|---|---|
| זמן השבתה בעת המעבר | שעות בחלון תחזוקה | 0 — הכתיבה לא הופסקה |
| שלמות הנתונים | בדיקה מדגמית ידנית | השוואת סכומי ביקורת לכל האובייקטים, אין אי-התאמות |
| שחזור לגרסה קודמת | שעות מגיבוי | דקות: הגרסאות נשמרות אצל האובייקט עצמו |
| הרשאות גישה | הקצאה ידנית לפי תיקיות | תפקיד לקונטיינר, שינוי דרך המאגר |
| גידול הנפח | קבוע, ניקוי לפי לוח זמנים | כללי מחזור החיים משחררים גרסאות ישנות בעצמם |
ביצענו את המעבר ללא עצירת הכתיבה: הדיסק הישן נשאר זמין לקריאה עד שהשוואת סכומי הביקורת אישרה שהכול הועבר. האנשים המשיכו לעבוד בנתיבי הרשת הרגילים — הם חוברו לאחסון החדש, ולכן ההדרכה הצטמצמה להוראה אחת.
בתפעול נשארה מחלקת משימות אחת במקום שלוש: הגדרות האחסון, הגישה וכללי הניקוי מתוארים במאגר ומשוחזרים בעת הפריסה. הוצאות האחסון הפסיקו לגדול באופן ליניארי — גרסאות ותמונות מצב יוצאות לפי מדיניות, ולא לפי הזיכרון של מישהו.
מה לעשות אם ב-Azure כבר פרוס אחסון קבצים
אין צורך לעצור שירותים לצורך המעבר. לשני סוגי הגישה מאותם נתונים, והצרכנים מועברים בזה אחר זה: אפליקציות שעובדות עם נתיבי קבצים ממשיכות לראות אותם. מעל אחסון האובייקטים מתיישבת שכבת תאימות שנותנת קריאה וכתיבה רגילות.
השאלה אינה במעבר עצמו, אלא אילו נתונים להשאיר באחסון הקבצים ואילו להעביר לאחסון האובייקטים. התרשים המעשי כאן הוא משולב, וזה אינו שלב זמני לשבוע אחד.
ספריות עם כתיבה מחדש תכופה, נעילות והוספה לכתיבה נשארות באחסון הקבצים: באחסון האובייקטים פעולות כאלה אינן קיימות באופן מקורי, ושכבת התאימות מוסיפה השהיה בקבצים קטנים.
ארכיונים, ייצוא נתונים, עותקים ומדיה עוברים לאחסון האובייקטים — ב-Azure Blob Storage הם נקראים כאובייקטים שלמים ומשתנים לעיתים רחוקות, והוצאות האחסון מפסיקות לגדול יחד עם הנפח.
ההגירה ההדרגתית מתנהלת לפי צרכנים, ולא בכל המעגל בבת אחת. תחילה מופעלת ההעתקה, לאחר מכן השוואה לפי סכומי ביקורת וגדלים — היא מראה מה לא הגיע או מה השתנה בתהליך. לאחר מכן עוברים לאחסון האובייקטים דוחות, אנליטיקה וגיבויים.
המעגל הישן נשאר פתוח לקריאה עד הצעד האחרון: החזרה היא החלפת נתיב, ולא שחזור מעותקים. מעבר ללא השבתה נשען על כתיבה כפולה בשלב המעבר, על בקרת שלמות ועל הרשאות גישה זהות בשני המעגלים.
ספקות טכניים נפוצים לפני ההתחלה
הצוות ההנדסי של הלקוח לפני ההתחלה שואל בדרך כלל את אותו סט שאלות: האם ניהול גרסאות ישבור אפליקציות קיימות, כיצד להגביל גישה לפי רשת והאם יהיה צורך לכתוב את הקוד מחדש. ב-Microsoft Azure שלושת הנושאים נסגרים בהגדרות האחסון, ולא בעיבוד מחדש של השירותים — להלן תשובות קצרות לכל אחד.
האם הפעלת ניהול גרסאות תשבור רשומות קיימות?
לא. ניהול גרסאות ומחיקה הפיכה מופעלים ברמת הקונטיינר ואינם משנים את פורמט האובייקטים — האפליקציות כותבות וקוראות את אותם נתונים.
רק הנפח גדל, ולכן את גורל הגרסאות הישנות מתארת מיד מדיניות מחזור חיים: לשמור את מספר הגרסאות האחרונות ולמחוק את השאר לפי גיל, כדי שהמאגר לא יגדל ללא שליטה.
האם הגבלת גישה לפי רשת תחייב התאמה של אפליקציות?
עבור שירותים בתוך הרשת הווירטואלית ההגבלה שקופה: הגישה עוברת דרך נקודת חיבור פרטית, ומחרוזת החיבור נשארת כשהייתה.
התאמה נדרשת במקומות שבהם האפליקציה פונה לאחסון לפי מפתח גישה או מרשת חיצונית — מקומות כאלה אנחנו מעבירים לזהויות מנוהלות ולתפקידים, כדי שמפתחות לא ישכבו בקונפיגורציות.
מה יקרה אם כללי מחזור החיים ימחקו משהו נחוץ?
כשמחיקה הפיכה מופעלת, האובייקט משוחזר בתוך התקופה שהוגדרה. לכן את תקופת השמירה של נתונים שנמחקו אנחנו קובעים ארוכה יותר מהמרווח בין בדיקות וגיבויים, ואת הכללים החדשים מריצים תחילה במצב דוח ובודקים מה היה נכנס תחת המחיקה.
נדון במשימה שלכם ונחזור עם הערכה ותוכנית
השיחה הראשונה היא איסוף נתוני פתיחה, שבלעדיהם תוכנית ההטמעה תהיה מקורבת. צריך להבין את הנפח והפרופיל של הנתונים, כיצד הם מתפלגים לפי תדירות הפניות, מי ובאילו ערוצים מקבל גישה.
בנפרד אנחנו מבררים את הדרישות לתקופות שמירה, להגנה מפני מחיקה ולשחזור — הן בדיוק קובעות את מבנה הקונטיינרים והמדיניות.
הנה מה שאנחנו מפרטים בשיחה:
- נפח ופרופיל הנתונים: כמה נשמר כעת, איזה גידול צפוי, איזה חלק מהאובייקטים נקרא באופן קבוע ואיזה שוכב כמשקל מת;
- מודל הגישה: מי קורא וכותב, אילו שירותים פונים לאחסון, כיצד ההרשאות מופרדות לפי תפקידים;
- מחלקות אחסון וכללי מחזור חיים: מה מועבר למחלקה קרה ולארכיונית, מה נמחק ולפי איזה סימן;
- ניהול גרסאות והגנה: האם נדרשות גרסאות קודמות של אובייקטים, נעילה מפני מחיקה, מחיקה רכה ותקופות שחזור;
- תשתית כקוד: היכן נשמר מצב Terraform, מי מבצע עריכות בקונפיגורציה, כיצד הן עוברות בדיקה לפני יישום;
- גישת רשת וזהויות: נקודה ציבורית או חיבורים פרטיים, מפתחות גישה או זהויות מנוהלות של שירותים;
- מגבלות המעגל שלכם: תאימות עם מערכות קיימות, חלונות שינוי מותרים, דרישות לשחזור לקונפיגורציה הקודמת.
בסופו של דבר תקבלו תוכנית הטמעה: רצף השלבים, הרכב הקונפיגורציה, קריטריוני קבלה והערכת היקף העבודה עם חלוקה לפי לוחות זמנים. תארו את המשימה בפורמט נוח לכם — נחזור עם תוכנית והצעה לסדר העבודה.