חיזוי עומסים ואוטו-סקיילינג פרואקטיבי ב-MongoDB

לעיתים קרובות ניתן לחזות עלייה בעומס לפני שהיא מתרחשת. אולי זה קורה באותה שעה בכל יום, או שתמיד יש עלייה בחצות ביום שישי כשמריצים משימת batch מסוימת. לחלופין, ייתכן שזה לא מחזורי, אך העומס עולה בהתמדה, וסביר להניח שהוא ימשיך לעלות לזמן מה. מנגנון ה-auto-scaler התגובתי של MongoDB Atlas מטפל בעליות אלו, אך הגדלת ה-instance לגודל הנכון אורכת מספר דקות. מה אם MongoDB Atlas יכול היה להשתמש בדפוסים זמניים אלו – מחזורים ומגמות – כדי להגדיל את ה-replica set עוד לפני שהוא הופך עמוס מדי?

בשנת 2023 יצרנו אב-טיפוס ל-predictive auto-scaling. רצינו לראות אם ניתן לחזות עליות וירידות בעומס על גבי ה-replica sets של MongoDB Atlas. חקרנו אילו מודלים של למידת מכונה מספקים את התחזיות הטובות ביותר, והערכנו עד כמה predictive auto-scaler יכול לשפר את הביצועים ולחסוך ללקוחותינו כסף. MongoDB השיקה כעת את ה-predictive auto-scaling. גרסת ה-production של האלגוריתם שונה בתכלית מהאב-טיפוס, ועד כה, היא מבצעת Scale-up ל-replica sets בלבד לפני עלייה צפויה בעומס; אנחנו מסתמכים על האלגוריתם התגובתי הקיים כדי לבצע Scale-down לאחר מכן. כעת, כשה-predictive auto-scaling נמצא בייצור, ברצוננו להביט לאחור על פרויקט המחקר שהוביל לכך.

⁦MongoDB Atlas⁩

MongoDB הוא מוצר חינמי וזמין בקוד פתוח (source-available); ניתן להוריד אותו ולפרוס מסד נתונים באופן עצמאי, ורבים אכן עושים זאת. עם זאת, לקוחות רבים משתמשים בשירות הענן שלנו, MongoDB Atlas. לקוחות Atlas מחליטים כמה שרתים לפרוס, באילו ספקי ענן ואזורים, ומה גודל השרת: כמה CPUs, כמה RAM וכן הלאה. כל שרת ב-replica set חייב להשתמש באותה שכבה (Tiers), למעט חריגים. אנו מחייבים לקוחות בהתאם לבחירותיהם – מספר השרתים, גודלם ומספר השעות שהם פעילים. כמובן שאנו מפצים את ספקי הענן שלנו (כולל AWS, Microsoft Azure ו-Google Cloud) לפי מספר השרתים וגודלם. אנו מציעים את גדלי השרתים ב-MongoDB כקבוצת "שכבות" (Tiers) – בשמות כמו M10, M20 וכן הלאה – אשר ממופים לגדלי מופעים (instances) ספציפיים אצל כל ספק ענן.

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

עוד בשנת 2023, ה-autoscaling של MongoDB Atlas היה תגובתי בלבד. אלגוריתם ה-auto-scaling התגובתי מבצע Scale-up לאחר מספר דקות של עומס יתר, או Scale-down לאחר מספר שעות של עומס נמוך. הוא מבצע שינויים רק בין שכבות (Tiers) סמוכות; לדוגמה, אם ה-replica set מסוג M60 אינו עמוס מספיק, Atlas יקטין אותו ל-M50, אך לא ישירות לשכבה קטנה מזו. אם הביקוש של הלקוח משתנה באופן דרמטי, נדרשות פעולות שינוי קנה מידה רבות כדי להגיע לגודל השרת האופטימלי. המשמעות היא ששרתים עלולים להיות עמוסים מדי או לא עמוסים מספיק למשך זמן מה. שרת לא עמוס עולה ללקוח יותר מהנדרש. שרת עמוס יתר על המידה פוגע בביצועים, ואם העומס כבד במיוחד, הוא עלול להפריע לפעולת ה-scaling עצמה.

האלגוריתם התגובתי שואף לשמור על ה-replica sets בגודל מושלם, אך הוא לא מגיב באופן מיידי לכל שינוי כדי להימנע מפעולות scaling תדירות מדי. מעבר לכך, לא משנה כמה מהר האלגוריתם מגיב, פעולת ה-scaling עצמה אורכת מספר דקות. כדי לשפר משמעותית את ה-auto-scaling, היינו זקוקים לאלגוריתם שמסוגל לראות את העתיד.

קנה מידה אוטומטי חזוי

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

איור 1. אלגוריתם קנה מידה אוטומטי מושלם דמיוני.

ניסוי קנה מידה חזוי

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

הניסוי התאפשר בזכות העובדה ש-Atlas שומר את מדדי ביצועי העבר של השרתים. עבור מדגם אקראי של 10,000 replica sets, חילקנו את ההיסטוריה לתקופת אימון ותקופת בדיקה, כמקובל בלמידת מכונה, ואמנו מודלים לחיזוי הביקוש וניצול ה-CPU. (CPU הוא המדד הפשוט והחשוב ביותר; בסופו של דבר, נוכל לחזות גם RAM, דיסק I/O וכן הלאה.)

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

• חזאי: מנסה לחזות את עומס העבודה העתידי של כל סט העתק

• מעריך: מעריך ⁦CPU⁩% עבור כל עומס עבודה, בכל גודל מופע

• מתכנן: בוחר את המופע הזול ביותר שעונה על הביקוש החזוי

איור 2. רכיבי ניסוי ה-predictive auto-scaling.

עבור כל replica set, היסטוריית הנתונים שלו משמשת כקלט ל-Short-Term Forecaster ול-Long-Term Forecaster. (נסביר בקרוב מדוע יש לנו שני Forecasters). יש לאמן את ה-Forecasters מחדש כל כמה דקות, ככל שמגיעות דגימות חדשות. דגמנו 25 מיליון נקודות זמן מ-replica sets אקראיים ב-MongoDB Atlas. כל אחת מהדגימות הללו כוללת מספר פעולות לשנייה, גודל מופע (instance size) וניצול ה-CPU באותו רגע. השתמשנו בנתונים אלו כדי לאמן את ה-Estimator, שמסוגל לחזות את ניצול ה-CPU עבור כל רמת ביקוש וכל גודל מופע. זוהי בעיה מורכבת, שכן איננו יכולים לראות את השאילתות של הלקוחות או את הנתונים שלהם, אך עשינו כמיטב יכולתנו. את ה-Estimator יש לאמן מחדש לעיתים רחוקות – כאשר זמינה חומרה חדשה או גרסה יעילה יותר של תוכנת MongoDB. (בעתיד אנו מתכננים לאמן Estimator עבור כל גרסה של MongoDB).

ה-Forecasters וה-Estimator משתפים פעולה כדי לחזות את עתיד ה-CPU של כל replica set עבור כל גודל מופע זמין. לדוגמה, הם עשויים לחזות כי בעוד 20 דקות, ה-replica set ישתמש ב-90% מה-CPU אם הוא ירוץ על שרתי M40, וב-60% מה-CPU אם ירוץ על שרתי M50 עוצמתיים יותר.

קנה מידה חזוי: מתכנן

בואו נסתכל על ה-Planner בפירוט רב יותר. להלן עומס עבודה חזוי; הוא צפוי לעלות ואז לרדת.

איור 3. התאמת גודל השרת בדיוק בזמן.

קנה מידה חזוי: חזאי ⁦Long-term⁩

המטרה שלנו היא לחזות את ניצול ה-CPU של הלקוח, אך איננו יכולים פשוט לאמן מודל המבוסס על התנודות האחרונות ב-CPU, שכן זה ייצור תלות מעגלית: אם נחזה עלייה ב-CPU ונבצע scaling בהתאם, נבטל את העלייה ובכך נהפוך את התחזית ללא רלוונטית. במקום זאת, אנו חוזים מדדים שאינם מושפעים מה-scaling, אותם אנו מכנים "מדדים מונעי לקוח" (customer-driven metrics) – למשל, שאילתות לשנייה, מספר חיבורי לקוח וקצב הסריקה של אובייקטים (scanned-objects rate). אנו מניחים שמדדים אלו אינם תלויים בגודל המופע או בפעולות ה-scaling. (לעיתים הנחה זו אינה מדויקת; שרת רווי מפעיל לחץ אחורי על השאילתות של הלקוח, אך מדדים אלו הם בדרך כלל אקסוגניים).

איור 4. חיזוי שינויים עונתיים בביקוש.

מודל החיזוי שלנו, MSTL (פירוק מגמה רב-עונתי באמצעות LOESS), מחלץ רכיבים מסדרת הזמן עבור כל מדד מונחה לקוח ב-replica set בודד. הוא מפריד בין מגמות ארוכות טווח (למשל, עומס השאילתות גדל בהתמדה) לבין רכיבים "עונתיים" (יומיים ושבועיים), תוך בידוד השאריות. אנו מטפלים בשאריות אלו באמצעות מודל אוטורגרסיבי פשוט ממשפחת ARIMA.

איור 5. ⁦MSTL⁩ (פירוק מגמה רב-עונתי באמצעות ⁦LOESS⁩).

על ידי שילוב רכיבים אלו, אנו חוזים כל מדד בנפרד ויוצרים "Long-Term Forecaster" לכל אחד מהם. למרות השם, ה-Long-Term Forecaster אינו חוזה רחוק אל העתיד; הוא מאומן על נתונים של מספר שבועות כדי לזהות דפוסים, ואז מבצע תחזית לכמה שעות קדימה.

לרוב ה-replica sets ב-MongoDB Atlas יש עונתיות יומית. לכ-25% מהם יש עונתיות שבועית. באופן כללי, אם ל-replica set יש עונתיות שבועית, תהיה לו גם עונתיות יומית. עונתיות ברמה השעתית היא נדירה, ובכל מקרה, היא אינה מועילה לתכנון פעולת scaling שנמשכת רבע שעה. replica sets בעלי עונתיות יומית/שבועית מספקת ניתנים לחיזוי על ידי ה-Long-Term Forecaster.

בתרשים להלן, ה-Long-Term Forecaster לומד מהשבועיים האחרונים (משמאל לקו האדום המקווקו האנכי) וחוזה במדויק את השעות הבאות (התחזית בירוק בקצה הימני).

אך רק לחלק מה-replica sets יש עונתיות! עבור אלו שאינם עונתיים, תחזית ה-Long-Term Forecaster למדדים מונעי לקוח אינה שימושית.

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

קנה מידה חזוי: חזאי ⁦Short-term⁩

מה ניתן לעשות כאשר ה-Long-Term Forecaster אינו אמין? לא רצינו לחזור ל-scaling תגובתי בלבד; אנחנו עדיין יכולים להגיע לתוצאות טובות יותר.

לכן יצרנו אב-טיפוס ל-"Short-Term Forecaster"; מודל זה משתמש בנתונים של השעה או השעתיים האחרונות בלבד ומבצע אינטרפולציה של מגמות. השווינו אותו ל-Forecaster בסיסי (נאיבי), שמניח שהעתיד ייראה כמו התצפית האחרונה, ומצאנו שאינטרפולציה של מגמות מנצחת את קו הבסיס ב-68% מהמקרים (ירידה של 29% בשגיאות).

איור 8. ⁦Approximation⁩ של מגמות מקומיות לתחזית קרובה לעתיד.

קנה מידה חזוי: הערכה

ה-Forecasters מנבאים את דרישות הלקוחות, אך עדיין עלינו לדעת אם ניצול ה-CPU יהיה בטווח היעד (50-75%). זהו תפקידו של ה-Estimator. ה-Estimator מקבל את הביקוש החזוי ואת גודל המופע (המוגדר לפי CPU וזיכרון), ומוציא את ניצול ה-CPU המשוער.

באמצעות מודל רגרסיה המבוסס על עצי החלטה (boosted decision trees) שאומנו על מיליוני דגימות, השגנו תוצאות מדויקות למדי. עבור כ-45% מה-replica sets, שיעור השגיאה שלנו הוא מתחת ל-7%, מה שמאפשר לנו לקבל החלטות scaling מדויקות. עבור 42% נוספים, המודל פחות מדויק אך עדיין שימושי במקרים קיצוניים. את 13% הנותרים מה-replica sets, שבהם שיעורי השגיאה גבוהים יותר, איננו כוללים ב-predictive scaling.

איור 9. ⁦Example⁩ של קלט ופלט של ⁦Estimator⁩.

קנה מידה חזוי: חיבור הכל ביחד

עם תחזיות והערכות CPU, ה-Planner יכול לבחור את גודל המופע הזול ביותר שאנו מניחים שיוכל להתמודד עם 15 הדקות הבאות של דרישת הלקוח מבלי לחרוג מ-75% ניצול CPU. הניסוי שלנו הראה ש-predictive scaler זה, בהשוואה ל-scaler התגובתי שהיה בשימוש בתקופת הבדיקה, היה נשאר קרוב יותר ליעד ה-CPU ומפחית ניצול יתר או תת-ניצול. עבור ה-replica set הממוצע, הדבר חסך 9 סנט לשעה. זה עשוי להסתכם במיליוני דולרים בשנה אם ה-predictive scaler יופעל עבור כל משתמשי MongoDB Atlas.

קנה מידה אוטומטי חזוי בייצור

הניסוי שלנו הראה ש-predictive auto-scaling יכול לעבוד ב-MongoDB Atlas, ולמדנו עובדות חשובות: רק חלק מה-replica sets ניתנים לחיזוי, ומגמות לטווח קצר הן לרוב איתותים טובים יותר מאשר מחזורים יומיים ושבועיים.

בשנתיים שחלפו מאז, MongoDB השתמשה בתוצאות אלו כדי לפתח predictive auto-scaler ברמת production. האלגוריתמים שונים והקוד חדש – הניסוי הוא יותר "סנדק" למוצר מאשר הורהו. בנובמבר 2025 התחלנו בהפצה שלו ב-MongoDB Atlas. כל הלקוחות שהפעילו auto-scaling (כשליש מהם) יקבלו בקרוב הן את ה-predictive והן את ה-reactive auto-scaling. גרסה ראשונה זו היא שמרנית ומשתמשת בתחזיות רק כדי לבצע Scale-up ל-replica sets. אם העומס יורד, ה-reactive auto-scaler יבצע Scale-down ל-replica set בחזרה לאחר מספר שעות.

אנו גאים בכך שצוותי המחקר ומדעי הנתונים של MongoDB תרמו תכונה ל-Atlas שתסייע לעשרות אלפי לקוחות, ואנו נרגשים לראות כיצד ה-predictive auto-scaler יתפתח.