קונטיינרים ב-AWS: ECS, אוטו-סקיילינג ו-CI/CD לסביבת ייצור

הגדרת AWS ECS: היכן קונטיינרים נופלים בפרודקשן

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

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

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

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

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

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

מה משתנה לאחר העברת שירותים לקונטיינרים מנוהלים

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

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

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

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

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

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

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

סדר היישום: מאודיט הסכימה ועד מסירה לתמיכה

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

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

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

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

4. Pipeline של build ו-delivery. מגדירים build, בדיקות ופריסה אוטומטיים עם חזרה ל-image הקודם בפקודה אחת. שלבים ידניים נשארים רק במקום שנדרשת החלטה אנושית.

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

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

מדיניות גישה, תרשימי רשת ונוהלי שחרור

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

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

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

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

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

מה שינינו בפריסה

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

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

מטריקות לפני ואחרי

• שחרור גרסה: 4-5 שעות עם הפסקה בשירות → 12-18 דקות בלי עצירת השירות;
• התאוששות מתקלה: 5-6 שעות של ניתוח ידני → 20-30 דקות בגלגול לאחור ל-image הקודם;
• שיעור השחרורים שהגיעו לאירוע: כל שלישי → אחד מעשרים.

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

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

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

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

האם תהיה השבתה בזמן ההעברה?

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

איך נסגרת האבטחה של הקונטיינרים?

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

מה עם התפעול והתמיכה לאחר המסירה?

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

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

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

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

לתוכנית העבודה ייכנסו תרשים היעד לפריסת השירותים, קונפיגורציות של משימות וכללי autoscaling, pipeline של build ו-delivery עם בדיקות בכל שלב, observability עם ספי התראה ברורים ונוהל גלגול לאחור. את הליווי מתארים בנפרד: מה אנחנו עושים, מה נשאר לצוות שלכם ואיך מעבירים ידע לאורך העבודה.

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

מה עושים אם חלק מהשירותים כבר פרוסים על שרתים?

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

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

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

הכלים הסטנדרטיים של AWS מספיקים לכך: registry של images, רוויזיות משימות עם גרסאות, ו-target groups להעברת תעבורה חלקה.

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