הגדרת מסדי נתונים מנוהלים ב-Yandex Cloud: Terraform, ניטור, התראות

Yandex Managed Databases: היכן נשברת התפעול של בסיסי נתונים

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

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

הכשל הנפוץ ביותר הוא חוסר סנכרון של רפליקות. צומת הקריאה מפגר אחרי הראשי, היישום מחזיר נתונים מיושנים, ואת סף ההשהיה никто לא הגדיר, כי «הרפליקה מדביקה את הפער בעצמה».

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

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

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

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

מה משנה תפעול מנוהל של בסיסי נתונים עבור הצוות

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

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

ב-Yandex Managed Databases מצב הקלאסטר מתואר באופן דקלרטיבי, ואותה תצורה נפרסת על סביבה שנייה בשלמותה.

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

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

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

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

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

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

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

סדר ההטמעה: מהביקורת ועד המסירה לתמיכה

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

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

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

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

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

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

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

מקרה בוחן: קיצרנו את זמן השחזור של בסיס הנתונים לאחר תקלה

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

מה שינינו

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

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

מה השתנה

זמן השחזור הצטמצם מ-3–4 שעות ל-5–10 דקות: את ההחלפה מבצעת הפלטפורמה, המהנדס רק מאשר את התוצאה וחוקר את הסיבה. מספר התקריות באותה תקופה ירד מ-5–6 לאחת-שתיים, שיעור הפעולות הידניות בעת תקלה — מכ-100% לכ-15%, וזה כבר לא שחזור אלא בדיקה.

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

קלאסטר מנוהל או עצמאי: במה לבחור

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

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

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

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

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

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

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

כיצד מופרדות הרשאות הגישה?

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

מה כלול בתוכנית החזרה?

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

האם יהיה צורך לשנות את היישום עבור בסיס נתונים מנוהל?

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

מה לדון בו בהתחלה: כיצד אנו מגיעים לתוכנית העבודה

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

הרשאות ונתוני פתיחה הנדרשים מכם:

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

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