הגדרת Fastly Compute@Edge: מחשוב קצה ב-WASM

Fastly Compute@Edge: מדוע משתמשים מרוחקים ממתינים לתגובה

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

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

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

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

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

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

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

מה נותן המעבר של הלוגיקה לפריפריית הרשת

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

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

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

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

אפשרויות מיקום הלוגיקה: מתי מה מתאים

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

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

כיצד אנו בונים את שכבת ה-edge: שלבי עבודת ההנדסה

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

1. ביקורת עומס. מנתחים יומנים על פני תקופה אופיינית: יחס בין סטטיקה לדינמיקה, גיאוגרפיה, חזרתיות של תשובות, ובאיזה קטע אובד הזמן. בפלט — רשימת מסלולים שמרוויחים מהפריפריה ואלה שזול יותר להשאיר כפי שהם.
2. סכמת ניתוב. קובעים אילו נתיבים מטופלים בשכבת ה-edge, אילו עוברים למקור, לפי אילו מפתחות נשמרת התשובה במטמון ומה קורה בהחמצה. את הסכמה מאשרים לפני העבודה: לשנות מסלולים באתר חי יקר יותר מאשר על הנייר.
3. הגדרת שירות edge. מרכיבים מודולים ב-Fastly Compute@Edge: הלוגיקה נדחסת ל-WASM ומופעלת לצד המשתמש. סביבת הבדיקות וסביבת הייצור מופרדות, והקונפיגורציה מתוארת בקוד — הסביבה משוחזרת, ולא מוגדרת ביד.
4. בדיקה על תעבורת ייצור. מפעילים על חלק קטן מהבקשות ומשווים לנתיב הנוכחי לפי זמן תגובה, שיעור שגיאות והחמצות מטמון. סף החזרה לאחור נקבע מראש: חריגה — חזרה אוטומטית למסלול הקודם.
5. מסירה לתפעול. מוסרים תיעוד של המסלולים, מדיניות מטמון, לוחות ניטור, התראות ונוהל חזרה לאחור. לאחר מכן את כללי הניתוב משנה הצוות שלכם — בלי מעורבות שלנו.

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

ערכת המסירה: קונפיגורציות, סכמות ותקנות

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

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

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

מקרה בוחן: עלייה במהירות התגובה עבור קהל מבוזר

מה היה לפני העברת הלוגיקה לפריפריה

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

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

מה שינו ומה נהיה

לפריפריה הועברו התאמה אישית, הלחמת תשובה מקטעים, חישוב מפתחות מטמון וניתוב בין אזורים; מודולים ב-WASM מופעלים בצמתים הקרובים למשתמש. המקור נשאר לכתיבת נתונים ולבקשות עם אימות — שיעור הפניות אליו ירד מ-100% ל-18%, והחציון של זמן התגובה באזורים המרוחקים — ל-0.12 שניות.

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

את הבנייה והשוואת המטריקות לפני ואחרי ניהלנו על Fastly Compute@Edge — ולכן מקרה דומה של חישובי edge משוחזר בפרויקט אחר על ידי העברת קונפיגורציות, ולא על ידי שכתוב הלוגיקה.

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

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

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

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

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

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

ספקות טכניים לפני העברת הלוגיקה לפריפריה

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

כיצד לעדכן את הלוגיקה בלי השבתה?

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

האם אפשר לבדוק שינויים לפני עלייה לייצור?

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

כיצד להגביל גישה לשירותים פנימיים?

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

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

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

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

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