הגדרת GCP Cloud Storage לאחסון אובייקטים

מה נשבר ב-GCP Cloud Storage כשהעומס גדל

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

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

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

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

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

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

מה נותן אחסון מוגדר: מהירות, אמינות, שליטה

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

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

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

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

מצבי גישה ומחלקות אחסון: השוואת אפשרויות

לאובייקט ב-GCP Cloud Storage יש שני החלטות בלתי תלויות: מי רשאי לקרוא אותו וכמה מהר הוא צריך להיות מוגש. הראשון קובע מצב גישה — מדיניות אחידה לכל הדלי או רשימות לפי אובייקט; השני — מחלקת אחסון.

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

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

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

סדר ההגדרה: מביקורת ועד מסירה לתפעול

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

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

תיעוד, סכמות וחוקי גישה לאחסון

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

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

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

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

מה היה לפני

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

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

מה שינו

סביבות הופרדו לפרויקטים ודליים נפרדים, כדי שהרשאות לא יחפפו. ב-Google Cloud Storage הגדירו חוקי מחזור חיים: לאחר 30 יום האובייקט עובר ל-Nearline, לאחר 90 — ל-Coldline, לאחר שנה — ל-Archive, עם חריג עבור עשר הגרסאות האחרונות של כל ארטיפקט.

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

מה נהיה

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

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

במה שונה Cloud Storage מאחסון קבצים

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

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

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

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

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

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

ספקות טכניים בבחירת אחסון אובייקטים

שאלות בשלב הערכה לעתים רחוקות עוסקות ביכולות האחסון — לרוב בסיכוני המעבר. ארבע מהן צפות постоянно.

מה עם גישות כשהרכב הצוות משתנה?

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

האם האחסון יעמוד בעומס שיא?

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

במה מאוששת שלמות הנתונים?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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