AWS Fargate: היכן נשבר הניהול הידני של קונטיינרים
כל עוד הקונטיינרים חיים על צמתים שהצוות מזמין ומתחזק בעצמו, כל משימה מתחילה בהפתעה. עדכון אימג'ים של צמתים, פאצ'ים של הקרנל, השגת מכסות לעוד מאגר אינסטנסים — זה לא פיתוח מוצר, אלא תיקון תשתית. ככל שיש יותר שירותים, כך גדל הסיכוי שעד למועד השחרור לא תהיה די קיבולת והאשכול יצטרך להידחס בידיים.
סקיילינג ידני הוא היקר מכולם דווקא בשיא. עד שהמטריקה תגיע לתורן, עד שהוא יעריך את התמונה ויוסיף צמתים נוספים, עדיין צריך להכניס את המכונה החדשה לפעולה — וחלק מהבקשות כבר נכשלו. כך בדיוק השבתה של שירות הופכת לשיחת טלפון באמצע הלילה, לחקירת אירוע ולחוסר אמון בתשתית. תגובה אוטומטית לעומס היא כאן לא מותרות, אלא דרך להוציא את האדם מהמסלול החם.
סעיף ההוצאות השלישי הוא סביבות שמתפצלות. הסטנד, ה-preprod והפרודקשן חיים לפי חוקים שונים: במקום אחד מגבלת זיכרון אחרת, במקום אחר תלות מיושנת, ובמקום שלישי פרמטר קונפיגורציה שתוקן ביד "לזמן מה". דיבוג של פער כזה אוכל יותר זמן מאשר הפיתוח עצמו, ותפעול האשכול מפסיק להיות משוחזר.
אנחנו מפרקים איך זה נסגר: קונטיינרים ללא שרת והגדרת AWS Fargate מסירים מהצוות את העבודה עם הצמתים — נשארים תיאור השירות, מדיניות סקיילינג לפי עומס וסביבות זהות מהסטנד ועד לפרודקשן.
מה נותן הרצה מנוהלת של קונטיינרים
הרצה מנוהלת של קונטיינרים מעבירה את הדאגה לצמתי השרת לצד הפלטפורמה: הצוות מתאר את האימג' והמגבלות, בעוד הקצאת המשאבים, עדכון שכבת הבסיס וההעברה מחדש בעת כשל בצומת — באחריות הספק.
ב-AWS Fargate בתיאור המשימה מגדירים אימג', פורט, משתני סביבה וגבולות CPU וזיכרון — את המקום להרצה הפלטפורמה מוצאת בעצמה. בהמשך האפקט נמדד בארבעה גדלים: זמן הפריסה של השחרור, זמן ההתאוששות לאחר כשל, שיעור הכשלים בעומס יתר ומהירות התגובה לגידול בתעבורה.
מהירות פריסה וחזרה לאחור של שחרורים
גרסה חדשה נפרסת על ידי החלפת משימה, ולא התקנה מחדש על שרת: הפלטפורמה מקימה מופעים חדשים, ממתינה למעבר בדיקות המוכנות ורק אז מסירה את הישנים. זמן הפריסה נמדד בדקות ואינו תלוי במספר המכונות. חזרה לאחור היא חזרה לאימג' הקודם באותו מחזור, בלי תיקון ידני של הקונפיגורציה.
עמידות בעומסי שיא
סקיילינג אוטומטי נקשר למטריקות: מספר המשימות, עומס ה-CPU או אורך התור. כשהתעבורה גדלה, הפלטפורמה מוסיפה עותקים של השירות; כשהיא יורדת — מסירה את המיותרים, ולכן עמידות השירות בכשלים אינה תלויה בכך שמישהו תורן בלילה. עומס שיא מפסיק להיות אירוע עם התערבות ידנית.
בדיקות תקינות ופיזור המשימות בין אזורי זמינות נותנים זמן התאוששות צפוי: בעת כשל של מופע, התעבורה עוברת לעותקים החיים, ומופע חדש עולה אוטומטית. שיעור הכשלים בעומס יתר יורד, כי התקרה למספר המשימות נקבעה מראש — במקום תור של בקשות שנפלו, השירות פשוט מתרחב.
דרכי הרצה של קונטיינרים: השוואת גישות
הבחירה בדרך ההרצה של קונטיינרים קובעת כמה זמן הנדסי הולך לתשתית וכמה למוצר. להלן ארבע חלופות אמיתיות שבוחרים ביניהן כבר בהתחלה: כל מעבר נוסף אחר כך עולה מיגרציה נפרדת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| קונטיינרים מנוהלים ללא שרת | עומס משתנה, אין מהנדס ייעודי לאשכולות | אין גישה לצומת: שירותי רקע עצמאיים ומצבים מורשים אינם זמינים |
| אשכול עצמאי על צמתים ייעודיים | עומס גבוה קבוע, צריך מאיצים או מודולי רשת עצמאיים | עדכונים, סקיילינג ועמידות הצמתים בכשלים — באחריותכם |
| מכונות וירטואליות עם אורקסטרציה ידנית | נכסי מורשת שאין טעם לארוז מחדש בקונטיינרים | אין התאוששות עצמית: תהליך שנפל לא יעלה מעצמו, עדכונים ביד |
| שירות פלטפורמה לאפליקציות טיפוסיות | אפליקציות ווב ו-API סטנדרטיים בלי דרישות מיוחדות לסביבה | מסגרת נוקשה: תלויות ופורטים לא סטנדרטיים לא ייתמכו |
מתי קונטיינרים מנוהלים מנצחים
אם העומס משתנה — משקט בלילה ועד שיאים בשעות הדיווח — החזקת צמתים במצב בטלה אינה רציונלית. הרצה מנוהלת מסירה את עדכון הסביבה, את פיזור המשימות בין הצמתים ואת החלפת המופעים שנכשלו, והסקיילינג מתבצע לפי המטריקות של השירות עצמו.
מתי אשכול עצמאי מוצדק
צמתים ייעודיים נדרשים כשהאפליקציה זקוקה לגישה לחומרה, למודולי רשת עצמאיים או לביצועים צפויים תחת עומס גבוה ואחיד. אז הצוות מקבל על עצמו ביודעין את הרֶזֶרוו והניטור של הצמתים, בתמורה לשליטה מלאה בסביבה. הקריטריון פשוט: אין דרישות מיוחדות לסביבה — האשכול מוסיף תחזוקה בלי תמורה.
שלבי ההעברה של העומס לקונטיינרים מנוהלים
העברת העומס ל-Fargate אינה תיקון של שורה בקונפיג, אלא רצף שלבים שבו כל שלב נשען על התוצאה של הקודם. אם מדלגים על האודיט או על הבדיקה תחת עומס, הכשל יצוף כבר בסביבת העבודה, כשאין לידך לא סטנד ולא זמן לחקור.
אודיט ותרשים של הסביבה היעדית
- מלאי: מה רץ כרגע, כיצד השירותים תלויים זה בזה, היכן המצב נשמר על דיסק הקונטיינר, מי קורא להם ובאילו פורטים. מיד מסמנים שירותים שדורשים השלמה לפני ההעברה.
- תכנון הארכיטקטורה היעדית: אילו משימות עוברות ל-Fargate, כיצד הן מתפרסות בין תת-הרשתות, היכן נקודות הכניסה והמאזן, כיצד השירותים מוצאים זה את זה. התוצאה — תרשים הסביבה עם אזורי זמינות.
- רשתות וגישה: תת-רשתות פרטיות בלי יציאה ישירה החוצה, תעבורה יוצאת דרך שער מנוהל, הרשאות המשימה לפי הסט המינימלי הנדרש, סודות מחוץ לאימג'ים.
בדיקה תחת עומס לפני העלאה לפרודקשן
- העברת שירותים אחד-אחד תוך שמירה על אפשרות חזרה לאחור: קודם קוראים, אחר כך כותבים, כך שבכל רגע ניתן לחזור לסביבה הקודמת לפי חישוב פרטני בדיקת עמידות בכשלים: מכבים משימה בודדת ואזור זמינות שלם, בודקים אם מספר העותקים הנדרש מתאושש ואם השירות עומד בזמן התגובה היעד בשיא. בנפרד בודקים את הסקיילינג האוטומטי לפי מטריקה.
- מסירה לתפעול: נהלי תורנויות, התראות על מטריקות מפתח, נוהל חזרה מהירה לגרסה הקודמת ותיעוד לאירועים טיפוסיים.
סדר כזה נותן תוצאה צפויה: הסביבה נבנתה לפי התרשים, נבדקה תחת עומס אמיתי וברורה לצוות שנשאר לתחזק אותה.
מה נשאר לצוות אחרי ההטמעה
מסירת התשתית אינה מסתיימת בשירות עובד ב-AWS Fargate. אנחנו משאירים לצוות סט ארטיפקטים שלפיהם אפשר לפתח את המערכת ולחקור תקלות בלעדינו: הקונפיגורציה מתוארת כקוד, שינויים עוברים בדיקה לפני הפריסה, וההתנהגות בעת כשל בצומת צפויה.
- תיאור השירותים — אילו אימג'ים רצים, מגבלות משאבים, נקודות כניסה ותלויות בין הרכיבים.
- תרשים הרשת ומסלולי התעבורה — תת-רשתות, קבוצות אבטחה, מאזן, מסלול הבקשה מהלקוח ועד הקונטיינר.
- מדיניות גישה ותפקידים — מי יכול לשנות מה, היכן ההרשאות מוגבלות לקריאה בלבד, כיצד ניתנות הרשאות זמניות.
- כללי סקיילינג — לפי אילו מטריקות, עם אילו ספים, מה קורה כשהקיבולת נגמרת.
- נוהל עדכון אימג'ים — כיצד נפרסת גרסה חדשה וכיצד חוזרים לקודמת.
- נוהל תורנות — למי מגיעה ההתראה, מה בודקים קודם, ומתי מגייסים את השאר.
הרכב התיעוד והנהלים
התיעוד נמצא לצד הקונפיגורציה באותו ריפו, ולכן אינו מתרחק מהמצב בפועל. הוא כולל הוראות לתקלות טיפוסיות, תרשים אסקלציה, צ'ק-ליסט לחזרה לאחור של שחרור ויומן שינויים בתשתית.
נוהל התורנות מקבע את תחומי האחריות ואת סדר מסירת המשמרת — מהנדס חדש נכנס למשמרת לאחר שקרא את המסמכים האלה, ולא מפרק את המערכת לפי לוגים.
מקרה בוחן: עומסי שיא בלי התערבות ידנית
עומס השיא על החנות מתרחש בחלונות עונתיים קצרים: התעבורה גדלה פי כמה תוך דקות, ותורי ההזמנות מצטברים מהר יותר ממה שמאגר שרתים קבוע מצליח להשיב. המהנדסים החזיקו תורנות מסביב לשעון והוסיפו כוח ביד, אבל חלק מההזמנות בכל זאת אבד באישור — הלקוח ראה שגיאה והלך.
מה שינו
ביצוע ההזמנות הועבר לקונטיינרים מנוהלים ב-AWS Fargate: המשימות מתוארות באופן דקלרטיבי, והפלטפורמה בעצמה מתאימה את מספר המופעים לעומס ומסירה את המיותרים כשהשיא חלף.
הסקיילינג האוטומטי הוגדר לפי עומק התור ולא לפי עומס ה-CPU, מסלול התשלום הקריטי הופרד למשפחת משימות נפרדת, ונוספו בדיקות מוכנות וניסיונות חוזרים בכשלים קצרים.
מטריקות לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| הזמנות שאבדו בשיא העונתי | כל עשירית | מקרים בודדים |
| תגובה לגידול בתעבורה | 30–60 דקות, ביד | פחות מדקה |
| מהנדס תורן בעונה | מסביב לשעון | לא נדרש |
| חזרה לגרסה הקודמת | 20–30 דקות | כדקה |
גידול של פי כמה בתעבורה עובר כעת בלי התערבות ידנית: הפלטפורמה מוסיפה קיבולת לפי מטריקת התור, והמהנדסים שהתפנו עוסקים בפיתוח המוצר ולא בתורנות.
במה קונטיינרים מנוהלים נבדלים מאשכול עצמאי
באשכול עצמאי כל שכבת הצמתים מוטלת עליכם: עדכון המערכת והסוכן במופעים, החלפת מכונות כשהאימג' מתיישן, הוצאה תקינה משימוש עם העברת עומס, הגדרת רשת בין פודים, תכנון קיבולת והתמודדות עם פיצול משאבים.
שכבת הניהול בדרך כלל סגורה על ידי הספק, אבל כל מה שמעליה הוא עבודת תפעול מתמדת, והיא גדלה ליניארית עם מספר המאגרים והסביבות.
פלטפורמה מנוהלת כמו AWS Fargate מסירה את השכבה הזו לגמרי: צמתים כישות אינם קיימים, כל משימה עולה בסביבה מבודדת משל עצמה, והסקיילינג נעשה ברמת המשימות ולא המכונות.
השאלה "האם יספיקו הנודים לשיא" מוחלפת בשאלה "האם יספיקו המגבלות של המשימה" — והתשובה נלקחת מהמטריקות, לא מחישוב של מרווח מלמעלה.
אזור האחריות של צוות הלקוח לא נעלם בכך: האימג' וגודלו, מגבלות ה-CPU והזיכרון למשימה, תפקידי גישה, סודות, תת-רשתות וקבוצות אבטחה, בדיקות חיים, מדיניות סקיילינג אוטומטי, הוצאת לוגים ומטריקות, אסטרטגיית פריסה.
הפלטפורמה מכסה את התחתון — בידוד, הפעלה מחדש של משימות שנפלו, החלפת חומרה — אבל לא את ארכיטקטורת השירות ולא את הקונפיגורציה שלו.
עלות הבעלות נמדדת לפי זמן ריצת המשימות ולא לפי מופעים בטלים: בזמן שקט לא משלמים על רזרבה. תחת עומס גבוה ואחיד צמתים ייעודיים עשויים להיות משתלמים יותר, ולכן בוחרים לפי פרופיל התעבורה ולא לפי הרגל.
מהירות השינויים גדלה באופן צפוי: גרסה חדשה היא רוויזיה של תיאור המשימה ופריסה בלי להמתין למכונות ובלי מיגרציה של עומס.
ספקות טכניים לפני העברת העומס
הספקות לעתים רחוקות נוגעים להרצת הקונטיינרים עצמה — קשה יותר להחליט להעביר את מה שכבר עובד. במעבר ל-AWS Fargate השאלות בדרך כלל אותן שאלות: מה לעשות עם התשתית הקיימת, כיצד לפצל את העבודה לשלבים ובמה לחזור לאחור אם השחרור יתנהג לא יציב. להלן תשובות קצרות, שבהן אנחנו פותחים את ניתוח המשימה.
מה לעשות עם התשתית הקיימת?
אין צורך לכתוב אותה מחדש. הסביבה החדשה מוקמת לצדה, השירותים מועברים אחד-אחד, והתעבורה מועברת דרך המאזן במנות — מאחוזים בודדים ועד לנפח מלא. כל עוד המנה אינה אפס, הסביבה הישנה נשארת פעילה ויכולה לקבל את העומס בחזרה.
כיצד נראית תוכנית המיגרציה וההעברה בשלבים?
נשענים על מלאי התלויות: אילו שירותים מתקשרים באופן סינכרוני, היכן התורים, אילו חוזים חיצוניים. את סדר ההעברה בונים כך שכל שלב ישמור על תאימות לאחור עם שירותים שעוד לא עברו. לכן המעבר נעשה בגלים ולא בשחרור אחד.
כיצד בנויה חזרה לאחור של שחרור לא יציב?
תיאור המשימה מנוהל בגרסאות, והרוויזיה הקודמת נשארת זמינה. חזרה לאחור היא חזרה אליה, ולא בנייה מחדש: דקות במקום מחזור תיקונים. את קריטריוני החזרה לאחור מקבעים מראש — לפי שיעור השגיאות וזמן התגובה, כדי שההחלטה תתקבל על ידי הניטור ולא על ידי תורן בלחץ.
AWS Fargate: נדון במשימה ונחזור עם תוכנית
כדי לחזור לא עם מילים כלליות, אלא עם הערכה ותוכנית שלבים, אנחנו צריכים מינימום של נתוני פתיחה — אותם בדרך כלל סוגרת שיחה טכנית אחת. לאחר מכן אנחנו מקבעים את גבולות העבודה, התלויות החיצוניות ואת החלונות שבהם מותרים שינויים בסביבה הפעילה.
בהתחלה מספיק מצדכם:
- גישה לסביבה או תיאורה: חשבון, רשתות, תפקידים, ומה כבר עובד תחת עומס;
- רשימת השירותים: אילו קונטיינרים מעבירים, אילו נשארים על המשאבים שלהם ומדוע;
- מגבלות על חלונות עבודה: שעות שבהן מותר לגעת בסביבה החיה, ותקופות שסגורות לשינויים;
- דרישות לעומס ולזמן תגובה: ערכי שיא, זמן התאוששות מותר, ומה נחשב לירידת ביצועים;
- נוהל הפריסה וכללי החזרה לאחור: כיצד משחררים גרסאות כעת וכמה מהר צריך לחזור לגרסה הקודמת;
- מי מצד הלקוח מקבל את התוצאה בכל שלב ולמי לפנות להחלטות בנושא התשתית.
את התשובה נמסור כמתווה שלבים: הכנת הסביבה והגישות, העברת השירותים הראשונים לסביבת ניסוי, בדיקת עמידות בכשלים וחזרה לאחור, העלאה למצב ייצור. לכל שלב — גבולות, ארטיפקט בפלט ונקודת קבלה, כדי שלא יהיו עבודות בלי תוצאה ביניים. תארו את המשימה — ונחזור עם הערכה ותוכנית שלבים.