הגדרת Yandex Managed PostgreSQL, MySQL, MongoDB לסביבת פרודקשן

הגדרת Yandex Managed PostgreSQL: כשלים אופייניים של האשכול

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אפשרויות פריסה ועמידות בתקלות של PostgreSQL

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

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

סדר העבודה: מביקורת עומס ועד מסירת נהלים

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

אנו הולכים ממדידות לשינויים — עבור PostgreSQL, MySQL ו-MongoDB הרצף זהה, שונים המטריקות וסט הפרמטרים.

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

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

מה נשאר אצלכם: תצורות, סכמות, הרשאות, נהלים

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

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

עבור MySQL ו-MongoDB הסט זהה — משתנים רק קבוצות הפרמטרים ואופן השכפול.

מקרה בוחן: אשכול לעומס שיא לאחר מעבר

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

נקודת התחלה

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

מה שינינו

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

מה התקבל

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

במה שונה אשכול מנוהל מהרכבה עצמאית?

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

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

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

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

ספקות טכניים נפוצים של צוותי הנדסה

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

איך אתם מחלקים הרשאות גישה לנתונים?

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

איך להבין שהשחזור יעבוד?

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

האם הפרמטרים משפיעים על ההתנהגות בשיא?

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

מה מקבל הצוות שלנו?

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

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

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

מה נדרש מכם כדי לדון במשימה לגופו של עניין:

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

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