הגדרת Yandex Object Storage (תואם S3) מקצה לקצה

מדוע Yandex Object Storage נשבר בעומס שיא

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

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

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

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

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

מה נותן אחסון אובייקטים בנוי היטב

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

מהירות מסירת נתונים צפויה

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

אמינות האחסון וגרסאות של אובייקטים

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

קיבולת שלא מתמלאת

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

סוג הכשלים שנעלם

חלק العمليات ללא התערבות ידנית גדל: ניסיונות חוזרים, חשבונות שירות נפרדים ובדיקת שלמות לאחר העלאה סוגרים תקלות אופייניות — ניתוק העברה, מפתח גישה שפג תוקפו, התנגשות דריסה. זמן שחזור קובץ נמדד בדקות, לא בשעות של חיפוש העותק הנכון.

מחלקות גישה ומדיניות של Object Storage

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

מצבי גישה לנתונים

מעבר נתונים בין מחלקות

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

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

איך מתבצעת ההגדרה: שלבי העבודה

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

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

תצורות, סכימות ונהלי גישה

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

מה נשאר אצל הצוות שלכם

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

נהלים לכל יום

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

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

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

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

איך זה היה קודם

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

מה השתנה

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

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

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

במה אחסון אובייקטים שונה מדיסקים ברשת?

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

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

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

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

מגבלות האחסון ושאלות נפוצות

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

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

הצפנת נתונים מופעלת כברירת מחדל?

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

איך בנויה גישה לפי תפקידים?

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

מה קורה כאשר השירות אינו זמין?

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

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

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

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

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