הגדרת Spot Fleet לעיבוד אצווה (AWS)

מדוע Spot Fleet AWS מפסיק עיבוד באצוות

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

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

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

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

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

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

מה נותן פול מנוהל של קיבולת Spot

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

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

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

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

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

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

אפשרויות לפיזור קיבולת Spot ב-AWS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה שינו

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

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

במה שונה פול Spot מפול משולב ומהסקיילינג האוטומטי?

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

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

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

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

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

מגבלות של פולי Spot: קטיעות, מכסות, קיבולת

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

האם אפשר לבטל קטיעות לחלוטין?

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

כיצד לפזר את העומס בין אזורי זמינות?

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

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

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

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

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