הגדרת פריסת אתר ב-AWS (EC2/ECS/Lambda)

מדוע פריסה ב-AWS נשברת עם גידול בעומס

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

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

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

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

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

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

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

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

זמן שחרור שינוי

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

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

שיעור השחרורים המוצלחים בניסיון הראשון

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

זמן חזרה לגרסה עובדת

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

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

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

דרכי פריסה ב-AWS: השוואת מצבים ומגבלות

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

כיצד בוחרים מצב

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

מדוע מצבים משתלבים לעיתים קרובות

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

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

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

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

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

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

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

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

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

מה מוסרים: תצורות, סכמות ונוהלים

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

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

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

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

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

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

מה שינו

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

מדדים לפני ואחרי

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

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

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

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

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

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

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

שאלות טכניות נפוצות בנושא מהדורות וסביבות

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

היכן לאחסן סודות ומפתחות גישה?

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

סטנד ופרוד — להפריד או להחזיק כסביבה אחת?

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

כיצד לדעת שהמהדורה עברה כשורה?

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

כמה מהר לחזור לגרסה קודמת?

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

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

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

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

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