הגדרת מופעי Spot/Preemptible למשימות אצווה

Spot אינסטנסים נקטעים באמצע חישוב באצווה

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

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

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

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

האפקט של הפסקות מבוקרות בחישובי אצווה

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

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

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

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

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

Spot אינסטנסים מול ייעודיים ושמורים

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

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

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

סדר היישום: מניתוח עומס ועד מסירה

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

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

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

ערכת תצורות ונהלים בפלט

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

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

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

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

מה היה

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

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

מה שינו

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

מה נהיה

• שיעור המשימות שאיבדו תוצאה בעת שלילת משאב: 15% → 0.
• זמן הפעלה מחדש: 25–30 דקות של עבודה ידנית → 40 שניות אוטומטית.
• התערבויות ידניות: 3–5 בלילה → אף אחת במשך רבעון של תצפיות.
• חלון הלילה הצטמצם בשליש: מופעים ניתנים להפרעה קולטים את השיא שבעבר המתין לשחרור הייעודיים.

במה שונה אינסטנס ניתן להפרעה ממשאב שמור

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

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

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

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

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

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

האם יהיה צריך לכתוב מחדש את קוד המשימות?

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

האם זה תואם לסטאק ולאחסון הנוכחיים?

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

מי אחראי על בקרת הביצוע?

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

מה אם יש יותר מדי שלילות וההרצה לא נכנסת לחלון?

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

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

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

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

לאחר מכן העבודה מתקדמת בשלבים:

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

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