הגדרת OpenFaaS: היכן נשבר מתאר ללא שרת
כשל במתאר ללא שרת לעתים רחוקות נראה כקריסה — לעתים קרובות זו דעיכה שקטה. תחילה גדל עומק תור הקריאות: מקורות האירועים ממשיכים לשלוח אותם, המטפל לא מספיק, והחזרות בעת שגיאה מכפילות את העומס במקום להחליק אותו.
לאחר מספר דקות האינטגרציה החיצונית מתחילה להשיב בפסק זמן, והאירועים הולכים לאיבוד באופן בלתי הפיך — האישור נשלח לפני העיבוד בפועל, ואין מי שישחזר אותם.
כשל טיפוסי שני — התרבות בלתי מבוקרת של עותקים. פלטפורמת הפונקציות מתכווננת לפי עומס, ואם הגבול העליון אינו מוגדר, פרץ בקשות מרים מאות מופעים, אשר בו-זמנית מכריעים את מסד הנתונים ואת הממשקים החיצוניים.
השירות החיצוני חוסם גישה לפי מכסה, העותקים עוברים להתנעה קרה, זמן התגובה גדל, וטיפול בהשלכות אורך שעות של עבודה ידנית.
הגדרת OpenFaaS מתחילה לא בהתקנה, אלא בגבולות: מכסת עותקים במקביל, סף תור, פסק זמן עיבוד, מספר החזרות וכלל השלכה. בנפרד אנו בודקים אידמפוטנטיות — משלוח חוזר של אותו אירוע לא צריך ליצור רשומה שנייה או תשלום שני. בלי המגבלות האלה, פלטפורמת הפונקציות פועלת בדיוק עד השיא הראשון.
להלן נפרט כיצד זה נסגר: לפי אילו מדדים אנו מזהים דעיכה לפני המשתמשים ומה בדיוק נכלל בהגדרת המתאר.
האפקט של מתאר מוגדר: תגובה, קנה מידה ובידוד כשלים
במתאר מוגדר על OpenFaaS התוצאה הראשונה נראית בגרף זמן התגובה של הפונקציות. מאגר מוכן של מופעים וסף החזקה של עותקים חמים מסירים את ההתנעה הקרה מתרחיש המשתמש: הפנייה הראשונה לאחר הפסקה מטופלת בשברירי שנייה, ולא ממתינה לבנייה ולהפעלת הסביבה.
המדד השני — יכולת חיזוי של קנה המידה. את הכללים אנו מגדירים לפי מספר הקריאות במקביל ואורך התור: בעלייה בעומס מתווספים מופעי פונקציה, ובירידה עודפים מוסרים לפי סף אי-פעילות. הקיבולת גדלה יחד עם הזרימה, ולא לאחר שהתגובה כבר נפגעה, ולכן השיא לא הופך לסדרה של התערבויות ידניות.
השלישי — בידוד כשלים. כל פונקציה חיה בסביבה משלה עם מכסות זיכרון וזמן ריצה, ולכן דליפה או תקיעה בתוך אחת אינה פוגעת בשכנות. מופע כשל מוצא מהרוטציה, הבקשה עוברת למופע תקין, והניסיונות החוזרים וטיפול התור לא מתאספים למפולת על כל הפלטפורמה.
כסוג, נעלמים הכשלים שנהגו לדרוש תורן בשיא: הצפת זיכרון של שירות ארוך-חיים, נפילה משורשרת של שירותים קשורים, וירידה בתגובה בעת זינוק חד. נשארת התנהגות ניתנת לבדיקה — זמן התגובה של הפונקציות מחזיק מעמד בשיא, קנה המידה ניתן לשחזור, והכשל מוגבל לפונקציה אחת ואינו יוצא מגבולותיה.
הגדרת OpenFaaS: השוואת מצבי פריסה
מצב פריסה קובע כמה זמן הצוות משקיע בתחזוקה וכמה מהר פונקציה חדשה מגיעה לפעילות. להלן ארבע סכמות שבאמת בוחרים ביניהן באשכול, עם החוזקות והמגבלות הכנות שלהן.
איננו נצמדים לאפשרות אחת: הפלטפורמה נבחרת לפי פרופיל העומס ובגרות הצוות, והמעבר בין הסכמות נעשה בהדרגה — פונקציה אחת בכל פעם, בלי לעצור את המוצר.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פלטפורמת פונקציות מוכנה (OpenFaaS, Knative) | משימות קצרות בהיקף גדול, פרצי עומס, יש צורך בקנה מידה עד אפס | הפלטפורמה מכתיבה מודל בנייה והרצה, מוסיפה התנעה קרה, ודורשת צוות בוגר לניפוי שגיאות |
| תוספת מבוססת אירועים מעל האשכול | כבר קיים אשכול ואוטובוס אירועים, הפונקציה מופעלת לפי הודעה או לוח זמנים | מעקב אחר השרשרת נעשה מורכב יותר, וסדר ההודעות והחזרות שלהן צריך לטפל בהם ברמת האפליקציה |
| סכמת קונטיינרים ידנית | תלויות לא סטנדרטיות, מדיניות רשת משלך, שליטה מלאה בתמונת הקונטיינר | קנה מידה, בדיקות חיות, רוטציית סודות ועדכונים — באופן ידני, וגדל חלק השגרה |
| מכונות וירטואליות | תלויות כבדות, דרישות בידוד, העברת מערכות קיימות | אין גדילה מהירה לפרץ, זמן השבתה בעדכון, ניצולת משאבים נמוכה |
הניסיון מלמד: כשצריך מהירות הפעלה של משימות חדשות, פלטפורמה מוכנה מנצחת. אנו מגדירים אותה כך שצוות הפיתוח יתאר רק את לוגיקת הפונקציה ולא יגע בתשתית, ושכבת האירועים ושירותי הקונטיינרים יתקיימו בשלווה זה לצד זה באותו אשכול.
סדר העבודה: מביקורת עומס ועד מסירת המתאר
הטמעת פלטפורמת פונקציות מתחילה לא בהתקנה, אלא בביקורת: עומס ממוצע אינו אומר דבר על התנהגות המתאר בשיא. טעות היא להתאים תצורה לצריכה ממוצעת: בשעות שקטות הכול מחזיק מעמד, ובפרץ התור גדל והקריאות נושרות בגלל פסק זמן. להלן סדר העבודה, שבו כל שלב נשען על המספרים של השלב הקודם.
- ביקורת עומס. אוספים פרופיל קריאות: תדירות, משך, שיאים, חלק המשימות ברקע והמשימות הנדירות. מסמנים מה מעבירים לפונקציות ומה זול יותר להשאיר כקונטיינרים עם צריכה קבועה.
- סכמת ניתוב. מקבעים נקודות כניסה, כללים לפי נתיבים וכותרות, פסקי זמן ומגבלות על גודל בקשה. קובעים אילו קריאות סינכרוניות ואילו נשלחות לתור.
- הגדרת המתאר. מתכננים מאגרי צמתים, מכסות משאבים, גבולות כיוונון אוטומטי בשיא ובאי-פעילות. פורסים את הפלטפורמה על OpenFaaS, מחברים מאגר תמונות, בנייה ממאגר הקוד, סודות והפרדת הרשאות גישה.
- בדיקת עמידות בכשלים. מריצים פרופיל גבוה פי כמה מהמשוער: גידול התור, זמן ההמתנה, התנהגות בעת כשל צומת, ויכולת המתאר להשתקם בעצמו. צווארי הבקבוק נסגרים לפני העלאה למצב עבודה.
- נראות תפעולית. מדדים, יומנים והתראות לפי סימני דעיכה. נוהל תורנות: מה נחשב תקין ומה דורש התערבות.
- מסירה והדרכה. תיעוד של תצורה וסכמות, הרשאות גישה, וניתוח פעולות אופייניות: פריסת פונקציה חדשה, חזרה אחורה, שינוי מכסות. מדריכים את הצוות כך ששינויים יבוצעו בלעדינו.
תצורות, סכמות ניתוב ונוהלי תפעול
לאחר ההטמעה נשאר אצל צוות הלקוח לא אוסף של סקריפטים מפוזרים, אלא ערכה עובדת: תצורות פונקציות, סכמות קישור בין שירותים, כללי גישה ונוהל תפעול. לפי החומרים האלה אפשר לעדכן את הפלטפורמה, להרחיב אותה ולהעביר אותה למהנדסים חדשים בלי לפנות אלינו.
- תצורות פונקציות — תיאורים של כל פונקציה עם מכסות זיכרון ומעבד, זמן חיים של מופע, פרמטרים של כיוונון אוטומטי וספי התנעה קרה, המקובעים במערכת בקרת גרסאות.
- סכמות אינטגרציה — מפה של קריאות סינכרוניות, טריגרים מבוססי אירועים, תורים ומקורות חיצוניים, כולל כיוון זרימת הנתונים ונקודות כשל.
- מדיניות גישה — תפקידים ותחומי נראות לצוותים, הפרדת מתארים, כללים להנפקה ורוטציה של פרטי גישה, ונוהל עבודה עם ערכים חסויים.
- נוהל תפעול — תדירות עדכון הפלטפורמה, חלונות עבודה, סדר חזרה לגרסה קודמת וקריטריונים שמפעילים את החזרה.
- סדר שחרור פונקציות — סקירת שינויים, מתאר בדיקות, העלאה הדרגתית של גרסה חדשה לחלק מהבקשות ותנאים למעבר מלא.
- נראות תפעולית — מערך מדדים, יומנים והתראות עם ספי הפעלה, הקשורים לפונקציות מסוימות ולא לפלטפורמה כולה.
- הוראות למשמרת תורנית — כשלים אופייניים, סדר אבחון ופעולות לכל אחד מהם, כולל בדיקת תורים ומופעים תקועים.
- יומן בדיקות — תוצאות של הרצות עומס והתאוששות עם תאריכים, תרחישים ופערים מתועדים.
כל מסמך קשור לתצורה אמיתית במאגר, ולכן פער בין התיאור לפלטפורמה שעובדת נראה מיד. המסירה נעשית יחד עם הסבר: מראים מה נמצא היכן, איך לבצע שינויים ואיך לבדוק את התוצאה.
מקרה בוחן: מתאר פונקציות לעומס שיא של חנות מקוונת
עומס השיא הגיע בגלים: פתיחת מבצע עונתי ומכירות לילה שילשו את זרימת הפניות בתוך דקות. המונוליט החזיק אותן באמצעות מאגר עובדים משותף, זה הגיע לתקרה, וחלק מהקונים קיבלו שגיאה בשלב האחרון של השלמת ההזמנה — העגלה אבדה כבר אחרי התשלום.
הרחיבו ידנית, אבל המחזור ארך עשרות דקות: השיא הספיק להסתיים לפני שהשרתים החדשים עלו. ננתח את המתאר שהסיר את התלות הזו.
מה שינו
תרחישי רקע וקצרים — בדיקת קוד קופון, חישוב משלוח, שליחת התראות, יצירת תצוגה מקדימה — הועברו לפונקציות על OpenFaaS. כיוונון אוטומטי הוגדר לפי מספר קריאות במקביל, ולא לפי עומס צמתים: המתאר מוסיף מופעים בתוך שניות ומחזיר אותם באותה מהירות.
את המצב הוציאו מהפונקציות לאחסון משותף, כדי שמופעים יישארו ניתנים להחלפה, ועל כל פונקציה הוטלה מכסה לזמן ולזיכרון — פעולה איטית אחת כבר לא מחזיקה את התור. הקונטיינרים מתחממים מראש, ולכן התנעה קרה לא נופלת על השניות הראשונות של השיא.
מה השתנה
שיעור הקריאות המוצלחות עלה מ-87% ל-99.9% בשיא, וזמן התגובה התקצר מ-4–6 שניות ל-0.3–0.6 שניות. כשל של צומת בודד מטופל כעת על ידי תזמון מחדש: ההתאוששות אורכת 20–40 שניות במקום 25–30 דקות של עבודה ידנית. השיא עובר בלי התערבות תורן, ומתאר הפונקציות חי על מספר קטן יותר של מכונות תפוסות באופן קבוע.
מה לעשות אם מתאר פונקציות דומה כבר פרוס
קודם כול — ספירת מלאי: אילו פונקציות באמת נקראות, באיזו תדירות ומה מפעיל אותן — בקשה, אירוע מתור או לוח זמנים. ברוב המתארים חלק מהשירותים הפרוסים לא מקבל תנועה חודשים, אותם מעבירים אחרונים או מוציאים משימוש. בסוף מקבלים מפת תלויות וסדר העברה.
רכיב מפתח במעבר — נקודת כניסה אחידה לפני המתאר הישן והחדש. הניתוב מתואר בכללים: נתיבים מסוימים או חלק מהבקשות עוברים לסביבה החדשה, ואת השאר משרתת הסכמה הקודמת.
שתי התצורות — מתאר OpenFaaS פעיל והחדש — חיות במקביל, והמעבר מצטמצם לתיקון כלל, ולא לשכתוב הקריאות אצל הלקוחות והצרכנים הפנימיים.
לאחר מכן מעבירים פונקציה אחת בכל פעם, החל מאלה שאינן שומרות מצב ואינן מחזיקות חיבורים ארוכים — אותן קל יותר להשוות למופת. סודות ומשתני סביבה הפונקציה לוקחת מאותו אחסון, הבנייה נעשית מאותו מאגר, ולכן הפער בין המתארים נשאר בשליטה.
חזרה אחורה מובנית בסכמה עצמה: כלל הניתוב חוזר לכתובת הקודמת בתוך שניות, בלי זמן השבתה וקטיעת חיבורים. את המתאר הקודם לא מוציאים משימוש עד שהגרסה החדשה תעבוד תחת עומס ייצור ותצטבר סטטיסטיקה של שגיאות והשהיות בשתי הסכמות.
יומנים ומדדים של שני המתארים מרכזים במקום אחד, כדי להשוות מדדים זהים — זהו הקריטריון למוכנות לשלב הבא. כך המעבר הופך לסדרה של שינויים הפיכים, ולא להחלפה חד-פעמית.
שאלות טכניות: התנעה קרה, מכסות וחזרות אחורה
בעת הגדרת OpenFaaS הצוות הטכני של הלקוח שואל אותן שאלות: כיצד המתאר יתנהג בשיא, מה מגביל את הפונקציות, האם אפשר לחזור אחורה ומה יישאר ביומנים לאחר כשל. להלן תשובות קצרות לכל אחת.
התנעה קרה: מה יקרה לתגובה בשיא?
הפנייה הראשונה מרימה קונטיינר — זוהי התנעה קרה. אנו מחזיקים מאגר מינימלי של מופעים מחוממים, ואת סף הכיוונון שמים נמוך מהשיא המשוער, כדי שהפלטפורמה תספיק מראש. פונקציות עם קריאות נדירות מעבירים לפעילות תמידית, אם ההשהיה שלהן קריטית.
איך מוגבלים המשאבים של פונקציה?
לכל פונקציה אנו קובעים תקרה למעבד ולזיכרון ופסק זמן קשיח: פונקציה כבדה אחת לא לוקחת משאבים מהשכנות. פגיעה במכסה נראית במדדים — זה אות לצוואר בקבוק, ולא דעיכה של כל המתאר.
האם אפשר לחזור לגרסה קודמת בלי זמן השבתה?
כל שחרור — גרסה נפרדת ובלתי משתנה, והתנועה מועברת ביניהן. חזרה אחורה היא החזרת התג לגרסה הקודמת, כלומר שניות. תמונות נשמרות עד לאישור יציבות, ולכן אפשר לחזור אחורה גם אחרי כמה ימים.
מה קורה בעת תקרית ואיך מנתחים אותה?
יומנים, מדדים ומסלולי מעקב קשורים לגרסת הפונקציה — רואים איזה שחרור גרם לכשל. הניתוח נעשה לפי כרונולוגיה: פרץ קריאות, שגיאות, זמן תגובה, רגע המעבר. התוצאה — רשומה עם הסיבה והתיקון, כדי שאותו סוג כשל לא יחזור.
נדון במשימה: מה להבהיר לפני תחילת העבודה
כדי לחזור עם הערכה מציאותית, ולא עם טווח «מכאן ועד כאן», אנחנו צריכים נתוני פתיחה על הסביבה והעומס. להעריך פלטפורמה בנפרד ממה שירוץ עליה זה חסר טעם: אותו מתאר למשימות רקע נדירות ולזרימת אירועים ממאות התקנים נבנה באופן שונה.
- היכן נמצאים כעת השירותים: אשכול עצמאי, ענן או סכמה משולבת, ומי אחראי על השכבה הבסיסית;
- אילו משימות עוברות לפלטפורמה: עיבוד אירועים, תורים, קריאות לפי בקשה, הפעלות מתוכננות;
- פרופיל עומס: תדירות שיא של פניות, חלק הפעולות הארוכות, דרישות לזמן הפעלת עותק חדש;
- כללי גישה ובידוד: מדיניות רשת, עבודה עם סודות, הפרדת הרשאות בין צוותים;
- כיצד בנוי שחרור עדכונים כעת ומה צריך לשמר: מאגר תמונות, סביבות, חזרה לגרסה קודמת;
- איסוף יומנים ומדדים: לאן כותבים, מה נחשב סימן לדעיכה, מי מקבל התראות;
- קריטריוני קבלה ואיש קשר מצד הלקוח שמאשר את הקריטריונים האלה.
לאחר מכן העבודה מתנהלת בשלבים: מנתחים את הסכמה שלכם ואת המגבלות הנוכחיות, מתאמים תצורת OpenFaaS יעד, מוסרים הערכה לפי היקף העבודות, ואחר כך — תוכנית עם שלבים ומועדים. תוצאת ביניים של כל שלב היא מתאר עובד, ולא דוח על מה שנעשה.
תארו את המשימה בצורה חופשית: מה אתם מריצים כעת, מה מפריע ואיזו תוצאה נחשבת בעיניכם מוכנה. נחזור עם הערכה ותוכנית עבודה.