אוטוסקיילינג של ראנרים ל-CI/CD: הגדרה ואופטימיזציה

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

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

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

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

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

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

מהירות המשוב

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

ניצולת הראנרים

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

זמן ההשבתה של הבנייה

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

חיזוי הפריסה

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

מחלקת כשלים שנעלמה

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

מצבי סקיילינג: מאגר קבוע, לפי דרישה, היברידי

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

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

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

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

השוואת סכמות

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

הטמעה בשלבים: ביקורת התור, סכמה, בדיקה, מסירה

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

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

תצורות, סכמות ותקנונים שנשארים אצלכם

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

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

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

קייס: כיצד הסרנו את תור הבניות ואת ההשבתה של הצינורות

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

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

מטריקות לפני ואחרי: ההמתנה בתור — מ-21 דקות ל-40 שניות, מספר הסוכנים שפועלים במקביל — מ-4 ל-34 בשיא העומס, שיעור הבניות שנכשלו — מ-12% ל-1.5%. ריצת הבדיקות המלאה התקצרה מ-34 ל-12 דקות, והזמן מהשינוי במאגר הקוד ועד לארטיפקט המוכן חדל להיות תלוי בשעת היום.

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

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

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

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

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

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

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

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

מטמון, סודות ובידוד בניות: מגבלות טכניות

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

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

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

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

מה יקרה אם הסוכן נפל באמצע המשימה?

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

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

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

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

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