Edge functions: היכן הפריפריה נשברת תחת עומס
עיבוד בקשות בפריפריה נראה כמו האצה בחינם: הקוד קרוב יותר למשתמש, המקור פרוק מעומס, התגובה אחידה יותר. זה נשבר על שלושה דברים — אתחול המטפל, גישה למצב משותף ועקביות עם מקור הנתונים.
Cloudflare Workers וסביבות הרצה קרובות נבנו עבור פעולות קצרות ללא זיכרון; ברגע שמופיעה בהן לוגיקה עם מצב, מתגלים גבולות הפלטפורמה.
זינוק בתעבורה מכה ראשון: הצומת משרת מטפלים רבים במאגר משותף, ובזמן שחלקם מתחממים, האחרים ממתינים בתור. אחר כך נכנס לתוקף המגבלה על תת-בקשות חיצוניות — המטפל עובר לשגיאה, והלקוח במקום הפניה מחדש או מחיר מעודכן מקבל תשובת 5xx.
שגיאות בזינוק מגיעות בקבוצות, לא בפיזור: צומת שמיצה את המשאב מסרב לכל הבקשות ברצף, כולל אלו שיכלו להיענות מהמטמון.
צוואר הבקבוק השני של CDN — כתיבות מקבילות למצב משותף. מונה תצוגות, מגבלה לפי כתובת, עגלת קניות: כל מה שנשמר בזיכרון המטפל, בבקשות מקבילות על צמתים שונים נקרא ונכתב מחדש בו-זמנית, וחלק מהשינויים נעלם בלי שורת לוג אחת.
זה נסגר על ידי הוצאת המצב לאחסון משותף ומפתח לפי משתמש, אבל כל פנייה אליו מוסיפה השהיה — אותה צריך לקנות בחזרה באמצעות שכבה מקומית עם זמן חיים קצר.
סוג הכשל השלישי — חוסר סנכרון עם מקור הנתונים. כללי המטמון ורגע הפרסום בשרת אינם קשורים כלל: בזמן שהפריפריה מחזיקה גרסה ישנה, הקונה רואה מוצר שהוסר מהמכירה, והתמיכה מקבלת פניות שיכלו לא להיות. אי-תוקף לפי תג וייצור גרסאות של המפתח סוגרים זאת, אבל דורשים משמעת ביצירת שם האובייקט.
יחד עם זאת, עומס יתר של צומת פריפריאלי הוא אות כן: אם שיעור הכשלים עולה בעומס קבוע על המקור, הבעיה אינה בתעבורה אלא במבנה הלוגיקה. מפרקים איך זה נסגר — מדיאגרמת המצב ועד התנהגות בזמן דעיכה.
מה משתנה בעבודת השירות לאחר הוצאת הלוגיקה לפריפריה
לוגיקה שהוצאה לפריפריה מבוצעת בצומת הרשת הקרוב ביותר למשתמש, ולא במקור. לשם עוברים בדיקת טוקן, הפניות מחדש, נרמול כותרות, פיצול תעבורה בין וריאנטים וסינון פניות מיותרות — כל מה שלפני כן תפס חיבור עם הקונטור הראשי.
Cloudflare Workers וסביבות קרובות מריצות קוד כזה בכל צומת, ולכן הוא מתרחב יחד עם הגיאוגרפיה של הקהל, ולא עם עוצמת המקור.
זמן התגובה מפסיק להיות תלוי במרחק למקור: התשובה נבנית באותו אזור שבו נמצא המשתמש. סטטיקה ותשובות במטמון מוגשות מיד, דינמיות מחושבות במקום, והמקור מקבל רק את מה שדורש גישה למסד הנתונים. הפער בין אזורים קרובים לרחוקים מטשטש, ופניות שגרתיות מואצות פי כמה.
שיעור הבקשות שאינן מגיעות למקור — המדד העיקרי לאפקט. הפניות מחדש, הגשת מטמון, בדיקת סשן וסינון תעבורה טפילה נסגרות בפריפריה: המקור מקבל חלק ניכר קטן בהרבה מהפניות, ושיעור זה נשמר ביציבות ברמת עשרות אחוזים מסך הזרימה.
במקביל נעלם סוג שלם של כשלים — המקור מפסיק להיות נקודת הכשל היחידה שאליה מתכנסות כל הבקשות בבת אחת. בשיאים — מבצע, פרסום, זינוק חיצוני — הצמתים סופגים את העומס וממשיכים להגיב בזמן שהמקור מתאושש, והמקור עצמו מקבל זרימה אחידה במקום גל. העומס עליו יורד עד כדי כך שזינוקים עונתיים מפסיקים לדרוש מלאי כוח מחושב מראש.
גישות לעיבוד בקשות: השוואת מצבים ומגבלות
כללי מטמון בצד ה-CDN סוגרים את רוב המשימות בכלל בלי קוד: מטמון לפי נתיב וסיומת, נרמול מפתח המטמון, הפניות מחדש, זמן חיים שונה לסטטיקה ולסימון. כל עוד הלוגיקה אינה תלויה בתוכן הבקשה, קצה הרשת צפוי יותר מכל סביבת הרצה — אין מה לבנות, אין מה לעדכן ולחזור אחורה.
ברגע שמופיעה לוגיקה — דריסות גיאוגרפיות, חלוקת A/B, חתימת קישורים, בניית תשובה ממספר מקורות — נדרשים חישובי פריפריה. פונקציות קלות בקצה מכוונות לתיקון קצר של בקשה או תשובה, סביבות הרצה מלאות כמו Cloudflare Workers מספקות ריצה רגילה, אבל עם מגבלות משלהן.
סט המגבלות הכולל של סביבת ההרצה זהה: אין ספריות שרירותיות בלי בנייה, אין גישה ישירה למסד הנתונים, מודלים נפרדים של פריסה, לוגינג וחזרה אחורה.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| כללי מטמון ללא קוד | סטטיקה, הפניות מחדש, מפתח מטמון, כותרות | הלוגיקה אינה תלויה בתוכן הבקשה; סדר הכללים קשה לתחזוקה |
| פונקציות קלות בקצה | תיקון כותרות, בדיקת חתימה, הפניה מחדש | מגבלה קשיחה על זמן וגודל קוד, אין קריאות רשת מהפונקציה |
| סביבת הרצה בקצה | התאמה אישית, חלוקת A/B, תשובה ממספר מקורות | מגבלות זמן מעבד וזיכרון, בנייה ופורמט מודולים משלך |
| שכבת שרת לפני המקור | לוגיקה כבדה, גישה למסד הנתונים, חישובים ארוכים | השהיית רשת, נקודה נוספת של התרחבות וכשל |
שכבת השרת מסירה את מגבלות הפריפריה, אבל מוסיפה השהיית רשת ונקודת כשל שנייה — מציבים אותה היכן שהקצה טכנית לא מחזיק. תרשים עבודה הוא בדרך כלל היברידי: הקצה שומר במטמון ומסנן רעש, השכבה עושה את הכבד, וכללי המטמון של CDN והדריסות בקצה אינם מתנגשים.
שלבי ההטמעה: מניתוח תעבורה ועד מסירה לתפעול
את העבודה מובילים ברצף: תחילה מודדים מה באמת מגיע לפריפריה, אחר כך מתכננים כללים, ורק לבסוף כותבים קוד. כך הלוגיקה הפריפריאלית לא שוברת סשנים ומטמון קיימים, והתוצאה נראית במדדים, לא בתחושות.
- ביקורת תעבורה. אוספים סטטיסטיקה לפי בקשות: שיעור סטטיקה ודינמיקה, גיאוגרפיה, חזרתיות תשובות. בנפרד סופרים אילו נתיבים ניתן לשרת בפריפריה ואילו חייבים לעבור למקור.
- דיאגרמת ניתוב. מכינים מפת כללים: היכן פועל המטמון, איזה נתיב מטפל בו הפונקציה, כיצד מועברות כותרות ו-cookie, כדי לא לשבור הרשאה והתאמה אישית.
- הגדרת לוגיקה פריפריאלית. מיישמים פונקציות: הפניות מחדש וכתובות קנוניות, נרמול כותרות, הגבלת תדירות, הגשת תוכן מהנקודה הקרובה. מביאים בחשבון מראש מגבלות זמן הרצה וזיכרון.
- בדיקה בקונטור בדיקות. מריצים תרחישים על עותק של התצורה, משווים תשובות הפריפריה והמקור, בודקים התנהגות בזמן אי-זמינות המקור — חייב לפעול נתיב גיבוי תקין.
- בדיקה בתעבורה חיה. תחילה מפעילים במצב לוגינג, אחר כך על שיעור בקשות קטן. משווים זמן תגובה, שיעור פגיעות במטמון ומספר שגיאות; חזרה אחורה — בהחלפת כלל אחד.
- מסירה לתפעול. מוסרים את התצורה למאגר, פריסה דרך צינור, דשבורדים והתראות, תקנון חזרה אחורה והוראות למשמרת התורנות שלכם.
חפצי ההטמעה: תצורות, מדיניויות, תקנונים
לאחר הטמעת edge-functions נשאר לצוות לא דוח למען סימון וי, אלא ערכה עובדת: קבצים במאגר, דיאגרמות ותקנונים. לפיהם ניתן להוציא שינוי ולחזור אחורה בלי מעורבותנו — זו הבדיקה שהמסירה אכן התרחשה.
- תצורת נתיבים. קישור נתיבים ומארחים למטפלים, סדר הפעלתם, חריגים לבקשות שירות וסטטיות. הקובץ יושב לצד הקוד ועובר ביקורת יחד איתו.
- דיאגרמת עיבוד בקשה. המסלול מהדפדפן דרך נקודת הנוכחות ועד המקור: היכן מוחדרות כותרות, היכן נקרא המטמון, היכן הבקשה עוברת לשרת האפליקציה.
- מדיניויות גישה ומפתחות. תפקידים, תחומי ראייה של טוקנים, הפרדת סביבות, סדר רוטציה של סודות ואחסונם במאגר מאובטח במקום בקוד הפונקציה.
- מערכי בדיקות. בדיקות התנהגות הפונקציות בסביבה טרום-פרודוקטיבית, השוואת כותרות וקודי תשובה, ריצה על נתיבים שבמטמון תחת עומס.
- תקנון חזרה אחורה. החזרה מדורגת של מערך הכללים הקודם, תנאי הפעלה וסימן שלפיו רואים שהפריפריה שבה למצב עבודה.
- תקנון שחרור. כיצד שינוי מגיע לפרודקשן: ענפים, ביקורת, סדר פריסה, מי מאשר את המוכנות.
- תיעוד תשתית. תיאור סביבות, משתנים, תחומי אחריות ופעולות שגרתיות — כדי שמהנדס חדש יבין בלי התכתבות עם מחבר הפתרון.
מקרה בוחן: כיצד קיצרנו את זמן התגובה והסרנו סוג של כשלים
מה היה במקור
המקור הגיש לא רק נתונים אלא גם את כל מסגרת הבקשה: הפניות מחדש, כותרות אבטחה, בחירת שפה ומטבע, סטטיקה, סימון לבדיקות ממשק. כל תשובה כזו עברה מסלול מלא עד המקור, ובשעות מבצעים הוא נתקל במגבלה לא בנתונים אלא במספר החיבורים. שיעור התשובות עם שגיאה הגיע ל-2.4%, וזמן התגובה באחוזון ה-95 גדל פי שלושה לעומת שעות שקטות.
מה הועבר לפריפריה
לפריפריה של Cloudflare הועברה שכבה שאינה זקוקה למסד הנתונים: נרמול כתובות והפניות מחדש, כותרות אבטחה, ניתוב גיאוגרפי ולשוני, הגשת סטטיקה, סימון לבדיקות ממשק. מפתח המטמון נבנה מאזור, שפה וסימן הרשאה — תשובות אישיות עדיין נבנות במקור, השאר מוגש מנקודת הנוכחות הקרובה למשתמש. חלק מהלוגיקה על edge functions מכבה זינוקים קצרים לחלוטין, בלי להגיע למקור.
מה נהיה לאחר ההעברה
החציון של זמן התגובה התקצר פי כמה, האחוזון ה-95 — פי שלושה. שיעור התשובות השגויות ירד מ-2.4% ל-0.15%, כלומר סוג הכשלים שהתגלה קודם דווקא בשיא נעלם. העומס על המקור בשעות מבצעים ירד ביותר מפי שניים באותה תעבורה, ויום השיא עבר בלי דעיכה והתערבות ידנית.
שינויים בפריפריה מועלים בשחרור נפרד ומוחזרים אחורה תוך דקות, ולכן תיקונים בלוגיקה כבר אינם דורשים בנייה מחדש של האפליקציה הראשית. מדדי זמן התגובה ושיעור השגיאות לפי אזורים מוצגים בדשבורד משותף — רגרסיה נראית לפני שהקונים מבחינים בה.
במה edge functions נבדלות משכבת שרת
פרוקסי הפוך לפני המקור ולוגיקה פריפריאלית פותרים משימות שונות, אף שמבחוץ הן נראות דומה. הפרוקסי מקבל בקשה, מעשיר כותרות, מסנן רעש ומעביר הלאה — העיבוד עדיין מתבצע בשרת מסוים, ומסלול הרשת עד אליו נשאר מלא. פונקציה פריפריאלית מבוצעת היכן שהמשתמש מוסר חיבור: בצומת הנוכחות, לצד נקודת סיום ה-TLS והמטמון.
ההשהיה מתקצרת באופן שונה. הפרוקסי מסיר מעבר אחד עד המקור וחלק מהעומס מהאפליקציה, אבל לא את העיבוד עצמו. לוגיקה פריפריאלית מסירה גם אותו — כל עוד החישוב סגור על נתונים שנמצאים בצומת. ברגע שנדרשת כתיבה למסד הנתונים או קריאה מהמקור, הבקשה בכל זאת עוברת חזרה, והרווח נמס באותו מעבר.
גישה לנתונים — המגביל העיקרי. בפריפריה קיימים מאגרי "מפתח-ערך" מבוזרים עם עקביות בסופו של דבר: בלי נעילות, טרנזקציות ארוכות וחיבורי SQL רגילים. לשם מעבירים ניתוב, בדיקת חתימת טוקן, וריאנטים של ממשק, נרמול כותרות. פעולות עם יתרות, הזמנות והרשאות נשארות במקור.
ניפוי שגיאות של לוגיקה מבוזרת יקר יותר. סביבה מקומית משחזרת צומת באופן חלקי: התנהגות המטמון, הגיאוגרפיה והמגבלות שונות, ומחסנית הקריאות נבנית מיומנים של מספר צמתים והמקור. בפרוקסי נשאר תהליך אחד עם דיבאגר רגיל ולוג צפוי.
עלות הבעלות נמדדת לפי תחזוקה הנדסית, ולא לפי תעריף לפי בקשות. קוד פריפריאלי מנצח בנפחים גדולים של תעבורה שגרתית, אבל מוסיף נקודות כשל ודורש משמעת פריסה נפרדת. פרוקסי קל יותר לתחזוקה, אולם הוא נשאר נקודה יחידה בנתיב הבקשה. הגבול עובר לפי הנתונים: לוגיקה בלי מצב עקבי — פריפריה, עם — מקור.
ספקות טכניים לפני ההרצה: סביבה, מגבלות, חזרה אחורה
לפני הרצת edge-functions, המנהל הטכני בודק לא את הקוד, אלא את התנהגות המערכת בתנאים גרועים: אי-זמינות המקור, עומס שיא, נתיבים שהועברו חלקית. שאלות אלו אנחנו מפרקים בהתחלה ומקבעים תשובות בתצורה, ולא בהתכתבות.
סביבת ההרצה נשכרת מספק ענן, אבל האחריות על ההגדרות, המגבלות וההתנהגות תחת עומס נשארת על הצוות. לכן לפני הפריסה מגדירים את בעל התצורה, מקום אחסון הסודות ומקורות הטלמטריה.
מה יקרה אם המקור יפסיק להגיב?
כל כלל מקבל פסק זמן והתנהגות גיבוי: להגיש תשובה מהמטמון, להחזיר מציין מקום או להעביר את הבקשה ישירות. את פסק הזמן מגדירים קצר מתקציב ההמתנה של הלקוח, כדי שהמבקר לא ימתין לכשל.
האם ניתן להעביר לפריפריה רק חלק מהנתיבים?
כן — הניתוב מוגדר לפי קידומות נתיב: מדור אחד עובר לפריפריה, השאר פועלים כמו קודם. כך אנחנו משווים מדדים של שני קונטורים על אותה תעבורה ומרחיבים את הכיסוי בהדרגה.
איך נראית חזרה אחורה של שינוי?
התצורה חיה במערכת בקרת גרסאות, הפריסה עוברת בדיקה עם שמירת המצב הקודם. חזרה אחורה — החזרה לרביזיה קודמת ופריסה מחדש: דקות לשחזור במקום שעה של תיקונים ידניים.
מה יקרה בעומס שיא?
מגבלות ההרצות במקביל מוגדרות מראש; עם מיצוין, הבקשות נענות על ידי הקונטור הראשי של האפליקציה — דעיכה במקום כשל. לפני ההרצה מריצים פרופיל עומס ובודקים את שיעור השגיאות וזמן התגובה.
נדון במשימה: מה נדרש להערכה ולתוכנית עבודה
הפרק שלהלן עוסק באופן שבו המשימה הופכת להערכת עבודה ותוכנית הטמעה. כדי שהחישוב יישען על מצב ממשי של ההיקף, ולא על שיקולים כלליים, אנחנו זקוקים לגישות ולנתוני קלט: אז אנחנו רואים כללי מטמון אמיתיים, היקף התצורה והמגבלות הפעילות.
מה יידרש מכם בקלט:
- גישה לקריאה בלבד לפאנל ה-CDN ולאזור ה-DNS — נסתכל על רשומות, כללי מטמון, הפניות מחדש וקישור תעודות.
- מאגר עם תצורת ההיקף וצינור הבנייה: נעריך מה נפרס אוטומטית ומה מתוקן ידנית.
- רשימת דומיינים ותת-דומיינים עם תפקידים — אילו מגישים סטטיקה, אילו עובדים עם API וחשבונות אישיים.
- תרחישים ל-edge-functions: חלוקת A/B, הפניות גיאוגרפיות, בדיקת טוקנים, טרנספורמציה של כותרות, הגשת מציין מקום בזמן תקלה ב-backend.
- פרופיל עומס: בקשות שיא, שיעור תשובות דינמיות, גיאוגרפיה של משתמשים ורגישות להשהיה.
- מגבלות: חלונות שינוי בקונטור החי, דרישות לחזרה אחורה ומדיניות אבטחה עם לוגינג.
- אחראים: מי מחזיק ב-DNS ומי מאשר פריסה לפרודקשן.
בפלט תקבלו הערכת עבודה, דיאגרמת השלמה עם תחומי אחריות ותוכנית הטמעה לפי שלבים — עם קונטור בדיקות, נקודות חזרה אחורה ובדיקות בכל שלב. תארו את המשימה ושלחו גישות — נחזור עם הערכה ותוכנית.