Fastly CDN: היכן נשבר המטמון ומדוע בקשות ממשיכות למקור
ככלל, זמן התגובה של Fastly CDN נקבע לא על ידי עוצמת השרתים, אלא על ידי שיעור הבקשות שמסתיימות בפגיעה במטמון. כל עוד שיעור זה גבוה, הדף מוגש מהצומת הקרוב ביותר ולמעשה לא מגיע לאפליקציה שלך. ברגע שהוא יורד, כל החמצה במטמון הופכת לבקשה מלאה למקור.
הסיבות להחמצות כמעט תמיד זהות. מפתח המטמון נבנה בפירוט רב מדי: לתוכו נכנסים תגים פרסומיים, קוקיז שירות, כותרות מיותרות ופרמטרי מיון, וכל מערך ייחודי יוצר גרסה נפרדת של האובייקט.
תוחלת חיים קצרה משלימה את התמונה — האובייקט מתפנה לפני שהספיקו לעשות בו שימוש חוזר, והצומת הולך למקור בשביל אותו הדבר.
לאחר מכן מופעל אפקט ההצטברות. המקור מיועד לזרימה ממוצעת, ולא לשיעור החמצות ברגע של מבצע או פרסום: זמן התגובה גדל, חלק מהבקשות נקטעות בגלל timeout, וניסיונות חוזרים מוסיפים עומס. כך תשתית שהחזיקה יום רגיל מפסיקה להגיב בשעת שיא.
אי-תוקף מטמון — מלכודת נפרדת. אם מנקים הכל לגמרי, המטמון מתרוקן לזמן מה וכל התעבורה עוברת למקור בבת אחת. אם ממתינים לפקיעת תוחלת החיים, המשתמש רואה נתונים מיושנים לאחר עריכת קטלוג או מחירים. הפתרון העובד הוא ניקוי ממוקד לפי אובייקטים ספציפיים וסוגי תוכן.
אנו מפרטים כיצד זה נסגר: על ידי תיוג מפתח המטמון, תוחלות חיים שונות לסטטי ולדינמי, אי-תוקף ממוקד והגנה על המקור מפני חזרה על מקבץ בקשות.
מה נותן העברת המטמון לצמתי הקצה: האפקט במספרים
מטמון קצה מציב את התגובה ליד המשתמש: הצומת הקרוב ביותר מגיש עותק מוכן תוך עשרות מילישניות במקום מאות, בזמן שהבקשה הולכת למקור. זמן התגובה מפסיק להיות תלוי בגיאוגרפיה, והמקור מפסיק להיות נקודה שכל פנייה נתקעת בה.
המדד המרכזי — שיעור הפגיעות: כמה בקשות נענו מהמטמון בלי לפנות למקור. הוא עולה לא על ידי "הגדרה למקסימום", אלא על ידי מפתחות מטמון ותיוג תוכן: אנו מנרמלים את המפתח, משליכים תגים פרסומיים, קובעים כללים לפי נתיבים וסוגי קבצים, ומפרידים TTL לסטטי ולדינמי. תגובה שלא ניתן לשמור במטמון במלואה, אנו מרכיבים בקצה משברים שמורים במטמון.
הסרת העומס נמדדת ישירות: כמה תעבורה לא הגיעה למקור. בתוכן טיפוסי זה רוב הבקשות — המקור מפסיק להיות צוואר בקבוק. עמידות בפני שיאים ניתנת באותו אופן: פרץ ממבצע או פרסום נבלע בצמתים, והמקור רואה זרימה אחידה במקום פי עשרה.
יחד עם זה נעלם סוג של כשלים — timeout ותורים במקור, שגיאות מדורגות תחת עומס, "האתר למטה" ברגע היקר ביותר. TTL גדול כאן מפסיק להיות סיכון: ניקוי ממוקד מסיר תוכן מיושן מהצמתים תוך שניות, העריכה יוצאת כמעט מיד, והמטמון החם לא נבנה מחדש במלואו.
ב-Fastly לוגיקת המטמון והניתוב מתוארת ב-VCL ויכולה להתבצע בצמתים עצמם — נרמול כותרות, הפניות, בדיקות גישה נפתרות לפני המקור. המקור מוקל לא על ידי "פרוקסי", אלא בכך שחלק מהעבודה פשוט לא מגיע אליו.
פורמטים של חיבור ומצבי עבודה של Fastly CDN
הבחירה בתרשים האספקה עבור Fastly CDN קובעת לא רק את שיעור הפגיעות במטמון, אלא גם אילו כותרות מטמון יהיה צורך לתמוך באפליקציה. בהתחלה בוחרים למעשה בין שלושה צירופים — הם נבדלים בנקודת הכשל ובנפח הלוגיקה שאתה מעביר לקצה.
שלושה צירופים עובדים
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פרוקסי הפוך מלא | כל התעבורה עוברת דרך הקצה, הדומיין מוחלף כולו; יש צורך ב-WAF, נרמול כותרות ונקודת לוגינג אחודה | דורש עבודה קפדנית עם כתובת המקור של הלקוח וכותרות Host; שגיאה בכללי הניתוב מפילה את כל האתר |
| מטמון לסטטי בלבד | נכסים, מדיה ופונטים מוגשים מהקצה, הדינמי עובר ישירות | העומס העיקרי נשאר על המקור; הרווח מוגבל לחלק היחסי של הסטטי בתעבורה הכוללת |
| היברידי עם תוכן דינמי | מרווחי מטמון קצרים ל-API ולתגובות מותאמות אישית, חלק מהלוגיקה עובר לקצה | יש צורך במפתחות איפוס ממוקדים וב-Cache-Control ו-Vary תקינים, אחרת נתונים פרטיים ייכנסו למטמון המשותף |
מצבי המטמון נבדלים במחיר הטעות: סטטי ניתן לשמור במטמון לאורך זמן וללא סיכון, דינמי — רק עם איפוס מיידי לפי מפתח. ההיברידי נותן את התפוקה הטובה ביותר, אך דורש כללי VCL ואי-תוקף מחושב היטב: בלי איפוס ממוקד, תוחלת חיים קצרה של התגובה הופכת לזרימה מתמדת של בקשות למקור. בהמשך נפרט כיצד זה מוגדר ונבדק תחת עומס.
כיצד מתבצעת ההטמעה: שלבי העבודה ההנדסית
את ההטמעה של Fastly אנו בונים כך שתרשים המטמון יופיע לפני הרליס הראשון, ולא ייבנה בדיעבד על פי אירועים. סדר השלבים זהה גם לפרויקט חדש וגם להעברה של אספקה קיימת.
- ביקורת תעבורה. אוספים סטטיסטיקה לפי נתיבים: שיעור הדינמי, התפלגות לפי אזורים, גודל תגובות, שיעור בקשות עם אימות ונתונים אישיים. בפלט — מפת זרימות ורשימה של מה שאסור לשמור במטמון בשום תנאי.
- תרשים מטמון. מגדירים מפתח מטמון, תוחלת חיים לכל סוג תוכן, כללי נרמול פרמטרי בקשה, הפרדה לפי שפות וסוגי מכשירים. בנפרד מתעדים מה מתאפס דרך Instant Purge ומה שורד רליס.
- כללי עיבוד. כותבים VCL: כתיבה מחדש של נתיבים, הפניות, עיבוד כותרות ושגיאות, תוחלת חיים שונה לסטטי ולתיוג. לוגיקה שצפופה מדי ב-VCL מעבירים ל-Compute@Edge.
- בדיקת עומס. מריצים תעבורה קרובה לשיא: בודקים שיעור פגיעות במטמון, זמן תגובה במטמון קר וחם, התנהגות כאשר המקור אינו זמין. בנפרד בודקים תרחישי איפוס וחימום, כדי שרליס לא יפיל את המקור.
- מסירה לתפעול. קונפיגורציות וכללים עוברים לריפוזיטורי, שינויים עוברים ריוויו ומופצים בין סביבות. מוסרים תיעוד, מפת מדדים ונוהל rollback — ניתן לשנות את התרשים בלי להרים מחדש את היסטוריית העבודה.
קונפיגורציות, תרשיםים ותקנות שנשארים אצלך
אנו מחשיבים את הפרויקט כסגור לא ברגע שהתעבורה עברה דרך רשת הקצה, אלא כאשר הצוות שלך יכול לשנות באופן עצמאי את התנהגות המטמון ולהבין את ההשלכות. לכן יחד עם הגישות אנו מוסרים סט ארטיפקטים שלפיהם העבודה ממשיכה בלעדינו.
- קונפיגורציית מטמון — קבצי VCL עם כללים לפי נתיבים וסוגי תוכן, תוחלת חיים של אובייקטים, איפוס לפי תגים וטיפול נכון בשגיאות מקור.
- מפת זרימות — תרשים מעבר הבקשה: ניתוב, כתיבה מחדש של נתיבים, נקודות חיבור של לוגיקת הקצה, מקום פגיעה והחמצה במטמון.
- מדיניות גישה — הגבלות לפי כתובות וטוקנים, קישורים חתומים, הפרדת סביבות ומטריצת תפקידים: מי יכול לשנות מה ובאיזו סביבה.
- לוגיקת קצה — קוד המקור של פונקציות עם תיאור כניסות, יציאות, תלויות חיצוניות ומשתני סביבה.
- תיעוד — מה נמצא היכן, לשם מה נחוץ כל בלוק כללים, כיצד להרים קונפיגורציה מאפס ולבדוק אותה מקומית.
- תקנון שינויים — סדר העריכות: ענף, ריוויו, הפצה לסביבת בדיקה, בדיקה על חלק מהתעבורה, החזרה לגרסה קודמת תוך דקות.
- נראות — סט מדדים (שיעור פגיעות, שגיאות, זמן תגובה), ספי התראות ורשימת פעולות תורנות בעת ירידה בביצועים.
את תקנון השינויים אנו מתאמים עם הצוות שלך לפני המסירה, כך שיתאים לתהליך הריוויו שלך, ולא יתקיים בנפרד ממנו. בפלט יש לך לא תוצאה חד-פעמית, אלא קונפיגורציה מנוהלת של Fastly עם נקודות כניסה ברורות למהנדסים חדשים.
מקרה בוחן: פריקת עומס מהמקור ומדדים לפני ואחרי ההטמעה
הלקוח — שירות קמעונאי מקוון עם שיאים חדים: תחילת מבצעים, תפוצות המוניות, קמפיינים ברשתות חברתיות. הפרימטר ב-Fastly שימש כמעט כפרוקסי שקוף: הגדרות ברירת מחדל, רק הסטטי נשמר במטמון, הקטלוג וכרטיסי המוצרים בכל פעם הלכו לנתונים במקור.
בשיא זה הפך למפולת של בקשות זהות לשרתי האפליקציה: בסיס הנתונים נתקע בחיבורים, וההגדלה האוטומטית של מכונות הדביקה את גידול העומס באיחור.
בניתוח התעבורה מצאנו שלושה צווארי בקבוק. מפתח המטמון לא התחשב בווריאציות של התגובה — שפה, מטבע, סימן אימות, ולכן שיעור הפגיעות עמד על 35–40%, וחלק מהמבקרים הסתכנו לקבל גרסה לא שלהם של הדף. הניקוי בוצע במלואו לפי לוח זמנים, ואחרי כל הפצה שיא הבוקר עבר על מטמון "קר".
בנוסף לא היה איחוד של בקשות זהות: בזמן שהראשונה הרכיבה את הדף, מאות במקביל חיכו לה והחזיקו חיבורים לבסיס הנתונים.
את הכללים ב-VCL כתבנו מחדש: מפתח המטמון נבנה לפי מאפיינים משמעותיים לתגובה, סטטי ודפי קטלוג הופרדו לפי תוחלת חיים, במקום ניקוי מלא עברנו לאי-תוקף ממוקד לפי תגים בעת עדכון כרטיס. הוספנו הגשת עותק מיושן בזמן שמאחורי הקלעים נבנה עותק חדש, וכיווץ בקשות זהות לפנייה אחת למקור. את לוגיקת נרמול הכתובות והגשת וריאציות הדף העברנו לפרימטר, כדי שהבקשה לא תגיע לאפליקציה.
- שיעור התגובות מהמטמון: 38% → 92%
- בקשות למקור בדקת שיא: פי 6 פחות
- זמן תגובה באחוזון 95: קצר פי שלושה
- שגיאות 5xx בשיא: 3.8% → 0.1%
- חוות שרתי האפליקציה לא הוגדלה, למרות שהשיא גדל פי שלושה
החזרה לאחור — החזרת סט הכללים הקודם, זה לוקח דקות. המקור הפסיק להיות צוואר בקבוק, והפרימטר כעת מחזיק את עומס השיא בלי גידול בתשתית האפליקציה.
במה שונה אי-תוקף מטמון מיידי מניקוי מלא
אי-תוקף מיידי מסיר מהמטמון אובייקטים ספציפיים — לפי כתובת או לפי תג שאנו מקצים לקבוצת אובייקטים בעת ההגשה. ניקוי מלא מאפס את מטמון הצומת כולו, ועד לחימום כל בקשה הולכת לשרת המקור. ההבדל במחיר הטעות: איפוס ממוקד משאיר את המטמון חם, מלא — מאפס אותו ופותח זרימת בקשות לבקאנד.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| לפי כתובת האובייקט | עריכת דף בודד, תמונה, קובץ קונפיגורציה | יש צורך בכתובת מדויקת תוך התחשבות בפרמטרים של מחרוזת השאילתה |
| לפי תג מטמון | קבוצת אובייקטים: קטלוג, מדור, תבנית, הפצת רליס | התג מוצב בשלב ההגשה — לא ניתן להוסיפו בדיעבד |
| ניקוי מלא | שינוי מבנה כתובות, שגיאה בכללים, דליפת נתונים | המטמון ריק עד לחימום, העומס על המקור גדל פי כמה |
תגי מטמון — הכלי העיקרי: אובייקט אחד יכול לשאת מספר תגים, לכן עדכון של קבוצת מוצרים מתבצע בפעולה אחת ואינו נוגע בשאר האתר. ב-Fastly CDN זמן ההתפשטות של אי-תוקף כזה ברשת — שברירי שנייה, לכן גרסאות התוכן מתחלפות ללא חלון המתנה.
ניקוי מלא נשאר מצב חירום: הוא נחוץ כאשר כללי הצבת התגים התבררו כלא נכונים או שיש צורך להבטיח החרגה של נתונים מיושנים. הסיכון כאן הוא שעד לחימום חלק מהבקשות מטופלות על ידי המקור, ובעומס שיא זה מורגש. לכן כברירת מחדל אנו בונים את התרשים על תגים, ואת הניקוי המלא מחזיקים כחריג מבוקר.
ספקות טכניים: קונפיגורציה, מגבלות, החזרת שינויים
לפני קבלת התשתית עולים אותם שאלות — לגבי מגבלות מטמון, החזרת כללים והתנהגות בעת כשל. להלן תשובות קצרות: כך רואים מה בדיוק אנו מתעדים בקונפיגורציה ובתקנון התורנות.
כיצד להחזיר כלל אם העריכה שברה משהו?
הקונפיגורציה מנוהלת בגרסאות: עריכה היא גרסה נפרדת, מרימים אותה בדומיין בדיקה ורק אחר כך מעבירים לתעבורה חיה. החזרה לאחור — מעבר לגרסה הקודמת, אורכת שניות ואינה דורשת בנייה מחדש. היסטוריית הגרסאות ונוהל ההחזרה מתוארים בתקנון, כדי שהתורן לא יחפש את העריכה ידנית.
אילו מגבלות מטמון אנו קובעים וכיצד התוכן מתעדכן?
תוחלת חיים וכללי עדכון אנו קובעים לפי סוגי תוכן: סטטי חי לאורך זמן, דפים — דקות. בזמן שהאובייקט נבנה מחדש במקור, המבקר מקבל את הגרסה הקודמת במקום להמתין. את הניקוי אנו עושים ממוקד לפי מפתח או תג — עריכת דף אחד לא מאפסת את כל המטמון.
האם בקשות של משתמשים מאומתים נשמרות במטמון?
כברירת מחדל לא — אחרת מבקר אחד יקבל את הנתונים של אחר. אם יש צורך במטמון, אנו מתייגים את המפתח כך שתגובות של חשבונות שונים לא יצטלבו. אנו בודקים זאת בבדיקות לפני הפצה לתעבורה חיה.
מה קורה כאשר צומת או אזור נופל?
התעבורה עוברת לצמתים החיים הקרובים, ואם גם הם לא זמינים — במסלול גיבוי למקור. פגיעות זמן והסדר של המעבר כתובים מראש, לכן הירידה בביצועים צפויה: האתר מגיב לאט יותר, אבל לא מחזיר שגיאה לכולם.
בואו נדון במשימה: מה להכין לשיחה
הערכת משימה של אספקת תוכן אינה תלויה בנפח הקונפיגורציה, אלא ב� полноте נתוני הפתיחה. ככל שתתאר בצורה מדויקת יותר את תרשים האספקה, פרופיל התעבורה ודרישות הטריות, כך נחזור מהר יותר עם תוכנית עבודה ואזורי אחריות ברורים — בלי סבבי הבהרות של שבועיים.
- תרשים אספקה. כמה מקורות תוכן והיכן הם ממוקמים, האם יש שכבות מטמון ביניים, מי מגיש את הסטטי היום. אם חלק מהנתיבים כבר עוברים דרך CDN, צרף את כללי המטמון הנוכחיים.
- פרופיל תעבורה. ערכי שיא של בקשות בשנייה, יחס בין סטטי לדינמי, שיעור כתובות ייחודיות, גיאוגרפיה של הקהל, כמה עומס יוצרים רובוטים של מנועי חיפוש וניטור.
- דרישות טריות. כמה שניות מותר להגיש תגובה מיושנת לכל סוג תוכן ואילו מדורים דורשים ניקוי מטמון מיידי לאחר פרסום. זה קובע היכן שמים תוחלות חיים ארוכות והיכן — איפוס לפי אירוע.
- כללי עיבוד בקשות. מה נדרש ברמת לוגיקת האספקה: הפניות, כתיבה מחדש של כתובות, נרמול, חתימת קישורים, הגבלת גישה לפי אזורים. בנפרד — אילו כותרות המקורות מחזירים כעת.
- נקודות אינטגרציה. קו ייצור והפצה, מערכת פרסום תוכן, איסוף מדדים ולוגים, DNS ותעודות, שירותי הגנה חיצוניים.
- התנהגות בעת כשלים. ציפיות למעבר בין מקורות, מה להציג למשתמש כאשר הם לא זמינים, אילו תרחישים נחשבים לירידה בביצועים ואילו לתקלה.
- גישות ותקנון. מי הבעלים של DNS והתעודות, אילו תפקידים נדרשים למהנדסים, האם יש מגבלות על חלונות שינויים ותיאום עריכות בפרודקשן.
שלח את מה שכבר קיים: תרשים, ייצוא לוגים ליום-יומיים ורשימת מדורים קריטיים. תאר את המשימה בצורה כזו — נחזור עם הערכה, תוכנית עבודה וסדר הטמעה.