ניהול MongoDB: תצורה, אופטימיזציה, ניטור

ניהול MongoDB: איפה הביצועים נשברים

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

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

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

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

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

מה נותן סדר במסד: מהירות תגובה ויציבות

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

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

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

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

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

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

תרחישי פריסה: צומת בודד, רפליקה, אשכול משורד

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

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

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

ניהול MongoDB: שלבי יישום ובדיקה

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: הסרנו את הירידה בביצועים תחת עומס וייצבנו את זמן התגובה

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

מה היה צוואר הבקבוק

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

מה שינינו

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

מה התוצאה

החציון של זמן התגובה בשיא — 0.25 שניות, האחוזון ה-95 ירד מ-4 שניות ל-0.6. ה-timeouts בקריאה נעלמו ולא חזרו בכל תקופת הניטור, כולל במבצעי מכירות.

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

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

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

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

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

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

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

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

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

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

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

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

כיצד לוודא שגיבוי אכן משוחזר?

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

מתי הגיע הזמן לבצע שירדינג?

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

ומה אם צוואר הבקבוק אינו במקום שציפינו?

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

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

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

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

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