הגדרת WebAssembly Runtime (Spin/Fermyon) למיקרו-שירותים בענן

WebAssembly runtime בענן: היכן שירותים נשברים

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

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

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

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

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

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

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

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

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

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

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

השוואה בין מצבי הפעולה של WebAssembly runtime

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

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

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

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

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

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

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

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

קונפיגורציות, סכמות ומדיניות גישה במסירה

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

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

מקרה בוחן: העברת שירותים למודולים מבודדים

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

מה לא התאים ומה שינו

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

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

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

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

במה שונה בידוד מודולרי מקונטיינרים

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

בפועל הבחירה נשמעת לא כ«קונטיינרים או מודולים», אלא כ«מה עושים אם מתאר הקונטיינרים כבר עובד». התשובה — מתאר היברידי: לצד האורקסטרטור מוקמת סביבת הרצה למודולים (Fermyon Spin ומימושים תואמים), הניתוב נשאר משותף, והשירותים מועברים אחד-אחד.

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

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

שאלות טכניות נפוצות על בידוד מודולים

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

כיצד המודול מקבל סודות?

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

עדכון בלי השבתה — איך זה עובד?

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

מה עושים שירותים עם מצב קבוע?

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

נדבר על המשימה: מה לשלוח להערכה

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

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

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