AWS RDS לסביבת ייצור: Terraform, Multi-AZ, ניטור

הגדרת AWS RDS: היכן מסד הנתונים בייצור מאבד עמידות

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

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

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

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

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

נבחן את נקודות הכשל הללו ואת האופן שבו כל אחת מהן נסגרת.

מה משתנה לאחר סידור התצורה

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

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

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

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

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

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

מצבי עמידות בכשלים של RDS והמגבלות האמיתיות שלהם

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

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

שלבי פריסה ובדיקת תצורה

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

1. ביקורת תצורה — מסירים את סוג המופע, מצב Multi-AZ, חלון הגיבוי, parameter group, גישה מרשתות ציבוריות, תקופת שמירת הצילומים.
2. תכנון סכמה — רשתות משנה פרטיות בשני אזורי זמינות, security group, הצפנת אחסון, רפליקה לקריאה, חלון תחזוקה מחוץ לשעות שיא.
3. תשתית כקוד — מופע, subnet group, parameter group, כללי התראות ומדיניות גיבויים מתוארים במודול Terraform; המצב — בבקאנד מרוחק עם נעילה, שינויים רק דרך סקירה.
4. בדיקה תחת עומס — משחזרים פרופיל שאילתות אמיתי, אוספים מדדים ב-CloudWatch: השהיה, מספר חיבורים, תור לכתיבה. בנפרד בודקים מעבר בעת כשל של צומת ראשי.
5. מעבר הייצור — מעבירים תעבורה דרך רפליקה וצילום, חלון הכתיבה מינימלי, סדר החזרה לסכמה הקודמת מתואר מראש.
6. מסירה — לוחות בקרה, ספי התראות, נוהל לשינוי פרמטרים מתוכנן והוראות לשחזור מצילום.

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

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

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

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

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

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

נקודת פתיחה

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

מה שינו

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

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

מה קרה בסוף

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

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

במה מסד נתונים מנוהל שונה ממסד נתונים על שרתים בבעלותכם

הבחירה בין מסד נתונים מנוהל לבין שרתים בארון שלכם היא прежде всего שאלה של היכן נגמרת אחריות הספק. שירות מנוהל כמו Amazon RDS לוקח על עצמו חומרה, כשל דיסק, התקנת עדכוני מנוע, גיבויים ומעבר לצומת גיבוי באזור זמינות אחר. לכם נשארים סכמת הנתונים, אינדקסים, הרשאות גישה, עומס ומוכנות האפליקציה לניתוק קצר של חיבורים.

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

יהיה צורך לשכתב את האפליקציה עבור רפליקות קריאה?

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

נפח הגיבויים יגדל בלי סוף?

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

כיצד מתבצעת מסירת התחזוקה?

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

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

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

נתוני פתיחה שלפיהם מחושב היקף העבודה:

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

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

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