הגדרת Cloudflare Workers: היכן נשברת מסירת התוכן
כל עוד העומס יציב, צוואר הבקבוק אינו נראה: השרת מספיק לספק גם את הסימון, גם את הסטטיקה וגם את תגובות הממשק. בעומס שיא מספר הפניות המקבילות גדל פי כמה, תור העיבוד מתארך, וזמן התגובה של השרת חורג מהמגבלות שהוגדרו בתכנון.
זה מורגש לא לפי גרפים אלא לפי התנהגות המשתמשים: הממשק נתקע בדיוק בשעות שבהן מגיע עיקר התעבורה, חלק מהבקשות נקטעות בגלל חריגת זמן ההמתנה ועוברות לניסיון חוזר — והניסיון החוזר נופל שוב על אותו צומת עמוס.
החצי השני של הבעיה — גאוגרפיה. בקשות מאזורים מרוחקים עוברות את כל המסלול עד לצומת היחיד, ורק שם מתחיל העיבוד. כל מעבר במסלול מוסיף זמן לתגובה, וניתוק ערוץ בקטע אחד משאיר אזור שלם בלי שירות.
מסירת סטטיקה מעצימה את האפקט: תמונות, סקריפטים ופונטים מתבקשים בנפרד מהסימון ובכל פעם עוברים את אותו מסלול למרכז. בין גרסאות התוכן שלהם לא משתנה — הם אינם נחוצים לצומת שעוסק בלוגיקה ובעבודה עם מסד נתונים.
כך נוצרת נקודת כשל: שרת אחד אחראי גם על החישובים, גם על הפצת התוכן וגם על בקשות מכל האזורים בבת אחת. נבחן כיצד Cloudflare Workers מסיר את העומס הזה מהמרכז ומעביר חלק מהעיבוד קרוב יותר למשתמש — לשם, שבו הוא פותח את הדף.
מה משתנה לאחר העברת הלוגיקה לקצה הרשת
כאשר עיבוד הבקשה מועבר לצומת הרשת הקרוב ביותר למשתמש, השרת הראשי מפסיק להיות נקודת הכניסה לכל התעבורה. הפניות מחדש, ניתוח כותרות, פיצולי וריאנטים לבדיקות, הרכבת קטעי עמוד ומסירת סטטיקה נפתרים בפריפריה — Cloudflare Workers מריץ את הקוד הזה באותו צומת שבו נמצא החיבור של המשתמש. לשרת מגיעות רק בקשות שבאמת זקוקות למסד הנתונים.
ההקלה נמדדת לפי שיעור התעבורה שהוסר: בקטלוג טיפוסי או בדף קידום, 60–80% מהבקשות אינן מגיעות לשרת — חוקי המטמון בקצה סוגרים אותן. מפתח המטמון נקבע לפי חוקים: מה לחשב לפי כתובת העמוד, מה להתחשב ב-cookies, ומה לא לשמור כלל. משם גם נלקח זמן התגובה — צומת חישוב באזור המשתמש מגיב מהר פי כמה משרת ביבשת אחרת.
העמידות בשיאים משתנה מבחינה מבנית. בעבר פרץ מדיוור או פרסום נתקע במספר תהליכי העבודה ובתור הבקשות; כעת החלק הכבד של החישובים מתרחב בצד הקצה, והשרת מקבל זרימה אחידה. אנו מוציאים בנפרד כללים למסלולים „חמים” — כך הפרץ אינו הופך למפל של תגובות איטיות ושגיאות.
אפקט נפרד — עלות ההשבתה. אם השרת הראשי אינו זמין, הקצה ממשיך למסור דפים וסטטיקה מהמטמון: הוויטרינה נשארת קריאה, המבקר אינו רואה מסך ריק ואינו עובר למתחרה. זה אינו מחליף גיבוי, אך מעביר את התקלה מסוג „האתר למטה” ל„חלק מהתרחישים אינם זמינים”, והשחזור מסתכם בדקות במקום בשעות.
מצבי עבודה ונקודות חיבור: השוואת גישות
בקצה פותרים את הבעיה בשלוש דרכים, והבחירה נקבעת לא לפי אופנה אלא לפי המקום שבו נגמר התיאור הדקלרטיבי ומתחיל הקוד. מטמון וכללי ניתוב מתוארים בקונפיגורציה — אותם עורך מי שמנהל את התשתית. לוגיקה משלנו — זה קוד הרצה: הוא פועל קרוב יותר למשתמש, אך לוקח על עצמו אחריות להתנהגות.
ההבדל נראה ברגע הכשל. מצבים דקלרטיביים צפויים ומשוחזרים מקובץ קונפיגורציה, אך אינם מקבלים החלטות לפי תוכן הבקשה. קוד יודע יותר — ולכן דורש בדיקות, ניהול גרסאות ותוכנית נסיגה: שגיאה משוכפלת לכל נקודות הנוכחות בבת אחת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מטמון בקצה | סטטיקה, תמונות, תגובות API, זהות לכולם | אינה מתאימה לתגובות מותאמות אישית: ההחלטה מתקבלת לפי כתובת וכותרות, גוף הבקשה אינו מנותח |
| כללי ניתוב | העברת תעבורה, הפרדת סביבות, הפניה מחדש, חלקי קנרית | הלוגיקה ליניארית: אין הסתעפויות לפי נתונים ופניות לשירותים חיצוניים |
| לוגיקה משלנו בקצה | אימות טוקנים, החלפת וריאנטים, הרכבת תגובה ממספר מקורות | סביבת הרצה מוגבלת ומגבלות זמן וזיכרון; קשה יותר לנפות שגיאות |
בפועל משלבים בין המצבים: הניתוב שולח לפונקציה רק את הנתיבים שבהם באמת נדרשת לוגיקה, והשאר נמסר למטמון. ב-Cloudflare Workers כל שלושת הרבדים מתוארים בקובץ קונפיגורציה אחד, ולכן המגבלות של כל גישה נשארות מקומיות ואינן הופכות למשותפות לכל התעבורה.
הגדרה והפעלה: שלבי עבודת הנדסה
סדר העבודות בהגדרת Cloudflare Workers חשוב יותר ממהירות: שינויים בפרימטר רואים כל המשתמשים בבת אחת, ולכן הולכים מהעובדות אל הקונפיגורציה. תחילה מנתחים את התעבורה בפועל — אילו מסלולים יוצרים עומס, איזה שיעור מהבקשות ניתן לשמור במטמון, ומאין מגיעים הלקוחות. תרשים הפתרון נבנה על הנתונים האלה, ולא מתוך הרגל „לעשות כמו תמיד”.
- ניתוח תעבורה. מוציאים לוגים, מקבצים בקשות לפי מסלולים וסוגים, ומסמנים היכן המסירה נחלשת ראשונה — המקור, נקודת הכניסה או מסלול עמוס אחד.
- תרשים הפתרון. קובעים מה עובר לפרימטר, מה נשאר במקור, כיצד מנותבות הבקשות ולפי איזה תרחיש מתבצעת הנסיגה. התרשים מאושר לפני התיקון הראשון בקונפיגורציה.
- סביבת בדיקות. מרימים סביבת תצוגה מקדימה עם העתק של כללי העבודה ומריצים תרחישים: מטמון קר, עדכון תוכן, שיא עומס. הדומיין הראשי אינו נפגע מהסביבה.
- הגדרת קונפיגורציה. מתארים ניתוב, כללי מטמון, כותרות וטיפול בשגיאות; ערכים מוציאים למשתני סביבה כדי שסביבת הבדיקות וסביבת העבודה לא ייפרדו.
- בדיקת כשלים. מכבים את המקור, מוסרים מטמון מיושן, שוברים מסלול נפרד — בודקים מה רואה המשתמש וכיצד הסביבה משתחזרת מעצמה.
- השקה לסביבת עבודה. מעבירים חלק מהתעבורה, עוקבים אחרי מדדים ולוגים, ובסטיות מחזירים את הגרסה הקודמת בפעולה אחת.
- מסירה. מוסרים קונפיגורציות, תרשים ונוהל נסיגה, ומראים לצוות כיצד לבדוק את מצב הפרימטר לאחר תיקונים.
סדר כזה נותן השקה צפויה: כל שלב מסתיים בתוצאה ניתנת לבדיקה, ולא בהבטחה.
מה נשאר במאגר ובמסמכים לאחר המסירה
מסירה היא לא הרגע שבו התעבורה עברה דרך גבול הרשת, אלא מצב המאגר שבו התיקון הבא בטוח למהנדס שיפתח אותו בעוד חצי שנה. לכן רשימת הארטיפקטים מתואמת לפני ההתחלה ונסגרת לפי צ'ק־ליסט: בלי כל סעיף, העבודה אינה נחשבת להסתיים.
- קונפיגורציית הפרויקט במלואה, עם הפרדה בין סביבת בדיקות לסביבת ייצור: הפריסה משוחזרת בפקודה אחת, בלי תיקונים ידניים בפאנל;
- כללי ניתוב — אילו נתיבים ומארחים עוברים אל Cloudflare Workers, מה נשאר בשרת הראשי, וכיצד נקבע סדר העדיפויות של התאמות;
- קוד המקור של המטפלים עם תיאור נקודות הכניסה: בקשה, משימה לפי לוח זמנים, תור;
- תרשים הפתרון: מסלול הבקשה מ-DNS עד התגובה, גבולות המטמון, זמן החיים של הנתונים ברבדים, נקודות כשל;
- קונפיגורציות של מאגרים וקשירות: מרחבי מפתח-ערך, מאגר אובייקטים, המגבלות שהוגדרו;
- נוהל עדכון ונסיגה: כיצד מוציאים גרסה, כיצד מתחלפת התעבורה, תוך כמה זמן חוזרים לקודמת;
- כללי עבודה עם סודות: מה נמצא במשתני סביבה, למי יש גישה, כיצד מתבצעת רוטציה;
- תיעוד: הרצה מקומית, תרשים הסביבות, סדר הניטור ופרטי הקשר של האחראים.
בבלוק נפרד מוסרים את סדר הנראות: מדדים, ספי התראות לפי שגיאות והשהיה, קישורים ללוחות ניטור. מערך כזה מאפשר לשנות מסלולים ולוגיקה בלעדינו — התיקון אינו הופך לחקירה של פרויקט זר.
מקרה בוחן: קיצרנו את זמן התגובה והסרנו עומס מהשרת
לפני
הפרויקט — שירות עם אזור אישי וממשק תוכנה חיצוני: כל הלוגיקה ישבה באשכול אחד באזור אחד. כל בקשה, כולל סטטיקה ונתוני עזר, הגיעה לשרת, ובשעות שיא הפניות הסתדרו בתור.
זמן התגובה באחוזון ה-95 עמד על 0.8 שניות, אצל משתמשים מאזורים מרוחקים — מעל שנייה; שלושה רבעים מכוח השרת הושקעו בתגובות חוזרות.
אחרי
חישובים עבור בקשות ללא מצב הועברו לקצה, אל Cloudflare Workers: ניתוב, הפניות מחדש, בחירת גרסת ממשק, הרכבת תגובה מהמטמון ומנתוני עזר. מפתח המטמון נבנה תוך התחשבות בכותרות ובסימני סשן, כדי שתגובות מותאמות אישית לא יתערבבו בין משתמשים.
לבקשות שזקוקות למסד נתונים הושאר פרוקסי לשרת עם הגבלת ניסיונות חוזרים וזמני המתנה — אי-זמינות של הקצה אינה הופכת לשגיאה אצל הלקוח.
זמן התגובה באחוזון ה-95 — 0.18 שניות, בקצה מעובדים 72% מהבקשות, מספר הפניות לשרת הצטמצם פי ארבעה. האשכול הפסיק להיות צוואר בקבוק: כשהתעבורה הוכפלה, לא נוצר תור בשרת. בנפרד נעלם סוג של כשלים הקשור לעומס יתר בבקשות חוזרות.
מה לעשות אם התוכן כבר מופץ דרך פרוקסי הפוך
לרוב גבול החישוב לא מתחיל ממקום ריק: התעבורה כבר עוברת דרך פרוקסי הפוך, שבו מסתיימת ההצפנה, ויושבים מטמון, דחיסה, הפניות מחדש וכללי גישה. אין צורך להרוס את התרשים הזה — שכבת הקצה משתלבת מעליו, ולא במקומו.
השלב הראשון — ספירת מלאי: מוציאים את כללי הניתוב מקונפיגורציית הפרוקסי ומשווים אותם למה שבאמת נראה בלוגים. חלק ניכר מהכללים מתגלה כמורשת שאיש אינו מעז למחוק, ודווקא בהם הכי קל לתפוס אי-התאמה בהתנהגות לאחר ההעברה.
לאחר מכן מופעל מצב מראה: הבקשה נשלחת גם לגבול החדש וגם לתרשים הקיים, והתגובות מושוות לפי קוד, כותרות וגוף. אי-ההתאמות נראות לפני שהמשתמשים רואים אותן, ולא אחרי.
העברה מדורגת הולכת מהפשוט למורכב: תחילה עוברים לקצה סטטיקה, הפניות מחדש ומסירת תמונות, לאחר מכן מסלולים עם אימות, ורק אחר כך כל השאר. נסיגה בכל שלב — תיקון של כלל ניתוב אחד, ולא פריסה מחדש של התשתית.
בפרוקסי נשארות משימות ששם מקומן: שירותים פנימיים, בדיקת הרשאות, אינטגרציות עם מערכת סגורה. הניתוב במקרה זה מתכנס לנקודת אמת אחת — כפילויות מהקונפיגורציה מוסרות, ההתנהגות נבדקת בתעבורה חיה, ו-Cloudflare Workers מפסיק להיות אי נפרד לצד ההפצה הראשית.
ספקות טכניים: מגבלות, כשלים ונוהל נסיגה
מגבלות הפלטפורמה אינן ננעצות בתעבורה, אלא במשך עיבוד הבקשה, בנפח הקוד שנבנה ובמספר הפניות בו-זמניות לשירותים חיצוניים. קריאה סינכרונית כבדה בתוך המטפל נתקלת ראשונה בתקרת הזמן: הלקוח מקבל שגיאה במקום תגובה. לכן אנחנו מוציאים את הכבד מחוץ לבקשה — למטמון, לתור ולמשימות רקע, ומשאירים במטפל רק ניתוב והגשה.
מה קורה כאשר הוורקר נופל?
כל בקשה מבוצעת בסביבה מבודדת נפרדת, ולכן כשל של קריאה אחת אינו מפיל את השכנות ואינו עוצר את השירות כולו. הפלטפורמה מרימה את הביצוע בבקשה הבאה, אך כבר בלי המצב שהיה בזיכרון. המשמעות היא שכל מה שקריטי — מונים, סלים, התקדמות — צריך לחיות במאגר חיצוני, ולא במשתני המודול.
כיצד לחזור לגרסה הקודמת?
היסטוריית הפריסות נשמרת בצד הפלטפורמה: החזרה נעשית באמצעות מעבר לבנייה קודמת, ולא בנייה מחדש מהמאגר. אנחנו מחזיקים ניתוב לפי חלקי תעבורה, ולכן הנסיגה נבדקת תחילה על חלק קטן מהבקשות ורק אחר כך מופעלת במלואה. חלון הנסיגה מוגבל: גרסאות ישנות נדחקות עם הזמן, ולכן גרסאות משמעותיות אנחנו מצמידים בנפרד.
איך להבין שמשהו השתבש?
מסתכלים על שלושה גדלים: שיעור התגובות עם שגיאה, זמן התגובה ומספר החריגות במטפל. האירועים עוברים לזרימה משותפת, שבה לפי מזהה הבקשה משחזרים את כל השרשרת — מהמסלול ועד הפנייה למאגר. התראה שמים על עלייה בשגיאות מעל הרקע הרגיל, אחרת רעש מתקלות בודדות מסתיר הידרדרות אמיתית.
נדון במשימה ונחזור עם הערכה ותוכנית
ההערכה נעשית עניינית כשיש מה להעריך: כיצד בנוי זרם הבקשות הנוכחי, איזו לוגיקה צריכה לפעול בקצה, לאילו שירותים ומאגרים היא פונה. לכן הצעד הראשון — ניתוח קצר של המשימה יחד עם הצוות שלכם, בלי שינויים בסביבת העבודה. מכם דרושים תיאור המשימה, סביבת בדיקות והרשאות; השאר — העבודה שלנו.
בתגובה נחזיר:
- הרכב העבודות — מפורק לפי כיוונים: ניתוב וחלוקת תעבורה, מטמון תגובות, בדיקת גישה בקצה, טיפול בכשלים ולוגים.
- תוכנית הטמעה — בשלבים עם תוצאה ניתנת לבדיקה בכל אחד: פיילוט במסלול אחד, העברת חלק מהתעבורה, הוצאה מלאה. בין השלבים נשארת נקודת חזרה לתרשים הקודם.
- לוחות זמנים — לכל שלב, עם סימון נפרד של מה שתלוי בצד שלכם: רשומות DNS, תעודות, חלון שינויים, נתוני בדיקה.
- קונפיגורציות ומדיניות — כללי מטמון, הגבלות קצב בקשות, הפרדת סביבות, תרשים נסיגת פריסה לגרסה קודמת.
- קריטריוני קבלה — אילו מדדים נחשבים לתוצאה: זמן תגובה, שיעור בקשות שעובדו בקצה, היעדר עלייה בשגיאות לאחר המיתוג.
- סיכונים ומגבלות — מה בארכיטקטורה הנוכחית יפריע להעברה ובאיזו דרך נעקוף זאת.
תארו את המשימה — מה צריך להשתנות בהתנהגות המערכת ולמתי זה נדרש. נחזור עם הערכת העבודות, תוכנית הטמעה והרכב ברור.