הגדרת Spot VM Pool לעיבוד באצווה ב-GCP

Spot VM GCP: היכן נשבר העיבוד באצוות

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

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

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

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

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

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

מה נותן מאגר מכונות Spot לעיבוד באצוות

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

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

צמצום חלון העיבוד

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

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

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

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

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

אפשרויות הקצאת משאבים: מתי מה מתאים

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

בחירת מצב לפי פרופיל העומס

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

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

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

סדר ההטמעה של המאגר: מביקורת ועד מסירה

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

ביקורת עומס ופרופיל הפסקות

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

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

בדיקות קבלה לפני מסירה

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

הרכב האספקה: קונפיגורציות, מדיניות, נהלים

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

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

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

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

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

העברנו את העיבוד באצוות לצמתים ניתנים להפסקה של Google Cloud: מאגר Spot VM עם סקיילינג אוטומטי ופיזור על פני כמה אזורים.

לפני ואחרי

• חלון עיבוד: 9–11 שעות → 4–5 שעות.
• צמתים שהופסקו בו-זמנית: עד 40% מהמאגר → 8–10% בזכות פיזור בין אזורים וסוגי מכונות.
• משימות להרצה חוזרת: כשליש → 2–3%.

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

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

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

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

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

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

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

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

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

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

מגבלות, מכסות ותקלות אופייניות במאגר

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

האם אפשר להחזיק צמתים רגילים וצומתי Spot באותו מאגר?

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

איך להימנע מעיבוד חוזר של חלקים מוכנים?

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

איזה עומס לא כדאי להעביר ל-Spot?

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