הגדרת BunnyCDN: היכן נשברת הגשת סטטיקה ווידאו
כל עוד התעבורה קטנה, הגשת סטטיקה ווידאו נראית תקינה: קבצים יוצאים ישירות מהנקודה שבה נמצאת האפליקציה, ואף אחד לא מבחין בהחלפה. אבל ברגע שהקהל מתפזר לפי אזורים, התמונה משתנה — משתמש מאזור אחר מושך קבצים כבדים במסלול ארוך, ישירות משרת המקור.
הדבר הראשון שנראה במדידות — הזמן עד לפריים הראשון בווידאו והזמן עד לרינדור בתמונות גדלים יחד עם המרחק. הנגן עובר לבאפרינג, חלק מהבקשות נקטעות בגלל חריגה מזמן ההמתנה, ובתמיכה מגיעות תלונות על «איטי» בלי פירוט. שיעור הפגיעות במטמון בפריפריה נשאר כמעט אפסי: התוכן לא נשמר בקרבת המשתמש.
השני — העומס על שרת המקור. בשיאים רוחב הפס מתמלא לחלוטין, ויחד עם הווידאו מדרדר כל השאר: תגובות האפליקציה, ייצוא נתונים, פניות למסד הנתונים. הגשת וידאו איטית מפסיקה להיות בעיה נפרדת והופכת לטריגר לכל השירות — המקור עסוק בהפצת קבצים במקום לשרת את הלוגיקה.
הסיבה בדרך כלל אינה בעוצמת השרת, אלא בקונפיגורציה של ההפצה: כותרות מטמון לא מוגדרות, פרמטרי בקשה הופכים כל כתובת לייחודית, ואזורי ההפצה לא מופרדים לפי סוגי תוכן. הגדרת BunnyCDN מתחילה באבחון של התמונה הזו — נפרק כיצד לסגור כל אחת מנקודות הכשל.
מה נותן שכבת CDN שנבנתה נכון: אפקטים ומטריקות
שכבת CDN שנבנתה נכון נמדדת לא לפי עצם ההפעלה, אלא בשלושה מספרים: שיעור הפגיעות במטמון, זמן ההגשה מהנקודה הקרובה ביותר ונפח התעבורה שבכלל לא מגיע למקור. להלן מה נותן כל אפקט ובזכות מה הוא מושג בהגדרת BunnyCDN.
שיעור הפגיעות במטמון וזמן ההגשה
בהתחלה שיעור הפגיעות בדרך כלל נשמר על 60–70%: מפריעים צורת מפתח מטמון שונה עם פרמטרי בקשה, TTL קצרים ונתיבים דינמיים שאי אפשר לשמור במטמון.
נרמול המפתח, העברת סטטיקה ל-TTL ארוכים וכללים מדויקים בקצה מעלים את הנתון ל-90–95% — הקצה מגיש תוכן מהנקודה הקרובה, העמוד מגיע מהר יותר באופן ניכר, ובקשות חוזרות לא מגיעות למקור בכלל.
חימום מטמון לאחר ריליס מסיר את הכשל הקלאסי: המבקרים הראשונים לא צריכים לחכות עד שהקצה יתמלא. ההגשה נשארת יציבה גם ברשתות סלולריות, שבהן כל השהיה מיותרת נראית מיד.
פריקת העומס מהמקור ומתעבורת היציאה
מטמון בקצה חותך את עיקר תעבורת היציאה של המקור: השרת מגיש רק פספוסים, עדכוני תוכן ודינמיקה. המקור מפסיק להיות צוואר בקבוק בשיאים — מבצע מכירות, דיוור המוני או פרסום בתקשורת כבר לא הופכים לתור בקשות ולסירובים.
במקביל נעלם סוג שלם של תקלות: פגיעה במגבלות חיבורים, טיימאאוטים בזמן התפרצות, סירובים תחת עומס. הפצת הווידאו מועברת לאזור נפרד, והזרם הכבד לא מתחרה עם האתר על משאבי המקור — השיא מתפזר בין נקודות נוכחות, ולא על שרת אחד.
כיצד זה נבנה בפועל — אזורים, כללים בקצה וסכימת הפצת וידאו — נפרק בהמשך.
הגדרת BunnyCDN: אזורי Pull, אזורי Push ו-Edge Rules
בחירת מצב ההפצה קובעת מהיכן הפריפריה לוקחת תוכן ומה היא עושה איתו בדרך. ב-BunnyCDN זה מוגדר לפי סוג האזור וקבוצת כללים — מהם תלויים גם מהירות ההגשה וגם ההתנהגות בעת עדכון קבצים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אזור Pull | התוכן ב-origin שלכם, העלאה בפריסה: סטטיקה, בילדים, תמונות | המטמון מתחמם בבקשה הראשונה באזור, בפספוסים ה-origin סופג את השיא |
| אזור Push | נדרשת הפצה בלי שרת אינטרנט משלכם: הקבצים נמצאים באחסון | פרסום דרך API או פאנל, אין קשר אוטומטי למאגר הקוד |
| אזור Pull + Edge Rules | כותרות, נתיבים ומדיניות מטמון משתנים בלי שינויים באפליקציה | הלוגיקה חיה בפריפריה — קשה יותר לנפות תנאים מורכבים |
| היברידי: Pull + אחסון לווידאו | הווידאו מופרד מתוכן האינטרנט, מחזור פרסום משלו והפצה לפי טווחים | שני מסלולי הגדרות, סנכרון שמות ואינוולידציה |
מטמון לפי סיומות וקודי תגובה
כללים מוגדרים במסכות עם עדיפויות: עבור סגנונות, גופנים ובילדים — זמן ארוך עם תג immutable, עבור פלייליסטים וסגמנטים של וידאו — שניות, עבור HTML — זמן קצר או מטמון מושבת.
בנפרד מפרטים קודי תגובה: 200 ו-301 נשמרים, 404 — לזמן קצר, כדי לא להעמיס על origin, 5xx ו-403 לא נשמרים במטמון. אינוולידציה של מטמון היא נקודתית — לפי URL או תג; ניקוי מלא של האזור מאפס את החימום ומחזיר את העומס ל-origin.
Edge Rules: כותרות, שכתוב נתיבים, מגבלות
Edge Rules מתקנים את הבקשה והתגובה: מוסיפים Cache-Control, CORS ו-HSTS, מסתירים כותרות שירות, משכתבים נתיב עבור בילדים עם גרסאות, עושים הפניות תוך שמירת פרמטרים. פועל ההתאמה הראשונה, לכן תנאים פרטיים מוגדרים מעל כלליים. המגבלות — מספר סופי של כללים לאזור והיעדר קוד שרירותי: לוגיקה מורכבת מוציאים ל-origin.
סדר היישום: מביקורת תעבורה ועד מסירה
מסלול היישום של BunnyCDN נבנה כך שההפצה תוחלף בלי השבתה ובלי הפתעות לשרת המקור. תחילה מתעדים כיצד התעבורה מופצת כעת, אחר כך מתכננים אזורים ורק לאחר בדיקה מעבירים את הקהל.
ביקורת סכימת ההפצה הנוכחית
- מיפוי הפצת התעבורה. משרטטים מפת בקשות: שיעור סטטיקה, תמונות ווידאו, גיאוגרפיה, שעות שיא, אילו נתיבים מגיעים לרוב לשרת המקור. בפלט — טבלת נפחים ודרישות למטמון.
- תכנון אזורים. לסטטיקה ווידאו — אזורי Pull, לקבצים גדולים עם עדכונים נדירים — אזורי Push עם טעינה מראש. כאן גם מגדירים מפתחות מטמון, זמני שמירה והפרדה לפי סוגי תוכן.
- הגדרת כללים בקצה. כותרות מטמון, טיפול בפרמטרים בכתובת, דחיסה, גישה לשרת המקור לפי חתימה וסדר רענון כפוי של המטמון.
בדיקה בפרופיל עומס מציאותי
- בדיקת עומס. משחזרים שיא: בקשות מקבילות לווידאו, התפרצות על קובץ פופולרי אחד, מטמון קר לאחר ניקוי. בודקים שיעור פגיעות, השהיית תגובה ועומס על המקור.
- החלפת תעבורה. מעבירים בחלקים דרך רשומות עם זמן חיים קצר, תוך מעקב אחר שגיאות ותגובת המקור. הסכימה הקודמת נשארת פעילה עד סוף ההעברה — החזרה אחורה אורכת דקות.
- מסירת תיעוד. מוסרים תיאור אזורים וכללים, נוהל רענון מטמון, סכימת הפצה, הרשאות וסדר פעולות שגרתיות.
מה הלקוח מקבל לידיו: קונפיגורציות ונוהלים
לאחר היישום נשאר לצוות לא אוסף הגדרות בפאנל האינטרנט, אלא ערכה שלפיה אפשר להקים מחדש את התשתית ולהעביר למשמרת תורנית. כל הארטיפקטים נמצאים במאגר הקוד ועוברים רוויו — שינויים ידניים בממשק לא נשארים בלי מעקב.
סכימת זרימות וקונפיגורציית אזורים
- קונפיגורציות דקלרטיביות של אזורים: שרתי מקור, סוג האזור (pull או push), כללי מטמון לפי סוגי תוכן, טיימאאוטים וניסיונות חוזרים.
- כללים בפרימטר: הפניות, כותרות אבטחה, מגבלות לפי מתודה וגיאו, מגבלות על גודל בקשה ותדירות פניות.
- סכימת זרימות תעבורה: מסלול הבקשה מהלקוח עד המקור, נקודות הפעלת מטמון, סגמנט הפצת וידאו וסדר הגשת טווחי קובץ.
- מדיניות קישורים חתומים וטוקנים לגישה: זמן חיים של חתימה, הצמדה לכתובת הלקוח או למקור ההפניה, רוטציית מפתחות בלי השבתה.
נוהל רענון מטמון ותפקידי גישה
- נוהל אינוולידציה: מה מנקים נקודתית, מה לפי קידומת, מה נשמר עד תום התוקף, וזמן ההכנה הצפוי.
- מטריצת תפקידים והרשאות: מי משנה קונפיגורציה, מי רק מבצע אינוולידציה, מי רואה אנליטיקה וייצוא נתונים.
- הנחיות למשמרת תורנית: צ'ק-ליסט אבחון לפי שכבות, תקלות אופייניות וסדר החזרות אחורה.
- סדר החלפת מקור בחירום ותוכנית דגרדציה של הפצת וידאו.
מקרה בוחן: הסרנו ירידות בהגשה בעומסי שיא
הלקוח — שירות מדיה עם קטלוג וספריית וידאו: הקלטות הרצאות, ניתוחים, הקלטות שידורים. האספקה עבדה ישירות משרתי האפליקציה, ובשיאי ערב, כשהתחברו בו-זמנית אלפי צופים, חלק מהבקשות הסתיימו בסירוב, והקטלוג נפתח לאט יותר מהרגיל באופן ניכר. ניתחנו והעברנו את האספקה ל-BunnyCDN.
מה היה לפני
אותה מערכת הגישה קטעי וידאו, תמונות קטלוג ונתוני ממשק. כותרות מטמון על סגמנטי וידאו לא הוגדרו כלל, ותצוגות מקדימות נדרשו שוב מהאפליקציה בכל רענון פיד. שיעור הפגיעות במטמון עמד על כ-55%, בשיא ירד ל-40% — כמעט כל התעבורה עברה לשרתי האפליקציה, וזמן התגובה באחוזון ה-95 גדל פי כמה. בשעות החמות ביותר סירובים בהגשה הגיעו ל-2% מהבקשות.
מה קרה אחרי
פיצלנו את האספקה לפי ייעוד: וידאו — לאזור Pull עם זמן שמירה ארוך של סגמנטים במטמון, סטטיקה — לאזור נפרד עם גרסאות לפי שם קובץ, כדי שעדכון הקטלוג לא יאפס את כל המטמון. לוגיקה מותנית הועברה לכללים בפרימטר: זמן חיים משל עצמו לתמונות, נפרד למניפסטים, מטמון כפוי לבקשות בלי כותרות. בנפרד סגרנו הגנה מפני התפרצויות: הגבלת תדירות פניות למקור ועדיפות לקטעי וידאו על פני בקשות שירות.
החלפנו בהדרגה — תחילה חלק קטן מהתעבורה, אחר כך לגמרי, עם החזרה אחורה מוכנה בצעד אחד. מדדנו לאחר התייצבות: שיעור הפגיעות במטמון עלה ל-94%, העומס על שרתי האפליקציה בשיא ירד בסדר גודל, זמן התגובה באחוזון ה-95 הצטמצם פי שלושה, סירובים בהגשה — מ-2% ל-0.05%. ירידות בשיאי ערב הפסיקו לחזור גם עם גידול כפול בצופים בו-זמנית.
מה לעשות אם CDN כבר פרוס, אבל המטמון לא עובד
מטמון «לא עובד» לעתים קרובות לא בגלל הגדרות האחסון, אלא потому שהמקור אוסר שמירה. בודקים כותרות תגובה: Cache-Control עם ערכים no-store, private או max-age=0, Set-Cookie על סטטיקה, Vary לפי נתוני משתמש — כל אחד מהם מאלץ את הפריפריה לפנות למקור עבור כל קובץ.
בדיקת הקונפיגורציה מתחילה בשתי בקשות לאותה כתובת — מה מגיש המקור ומה מגיש הצומת לאחר חימום; פער בכותרות מראה היכן אובדת השמירה.
הסיבה השנייה — כתובות שונות לאותו קובץ. פרמטרי גרסה, תגי קמפיין, סלאש בסוף, וריאציות עם www ובלי — עבור המטמון אלה אובייקטים שונים, לכן שיעור הפגיעות יורד, והמקור מקבל תעבורה שלא אמורה להגיע אליו. זה מטופל בקנוניקליזציה: כתובת אחת למשאב וכללים שמתעלמים מפרמטרים מיותרים בחישוב המפתח.
השלישית — עקיפת הפריפריה בצד האפליקציה. תבניות בונות קישורים ישירות למקור, האפליקציה עוברת על פני הצומת, עמודים ישנים שומרים כתובות מוחלטות. המטמון מוגדר כראוי, אבל לא משתמשים בו — זה נראה ביומני המקור: שיעור הבקשות מכתובות פריפריה לאחר חימום לא עולה.
הרביעית — היעדר כללים לדינמיקה. אם HTML ותגובות API מטופלים באותן הגדרות כמו תמונות וסקריפטים, הם לא נשמרים במטמון: בלי כלל נפרד עם זמן קצר והתחשבות ב-cookies כל עמוד הולך למקור.
וגם בודקים אינוולידציה — אחרי ריליס אובייקטים ישנים צריכים להתאפס באופן ממוקד, אחרת שינויים לא מגיעים למשתמשים.
ספקות טכניים שאנחנו מסירים לפני התחלה
לפני ההתחלה מהנדסים ומנהלי תחום שואלים כמעט את אותן שאלות — על עמידות ההפצה, גישה לקבצים סגורים ומהירות עדכונים. להלן תשובות קצרות בלי שיווק: כפי שזה עובד עם אזורי Pull ו-Push בפועל.
מה יקרה להפצה אם צומת או אזור שלם ייכשלו?
התעבורה עוברת אוטומטית לצמתים החיים הקרובים, והמטמון בפריפריה ממשיך להגיש סטטיקה כל עוד המקור לא זמין. אנחנו מכפילים את המקור — שרת שני או אחסון אובייקטים — לכן עבור סטטיקה התקלה נשארת בלתי מורגשת למשתמש.
איך להגביל גישה לקבצים סגורים?
קישורים חתומים עם זמן חיים מוגבל ובדיקת טוקן בפריפריה, בתוספת איסור פנייה ישירה למקור לפי כתובת. הקישור מפסיק לעבוד בתום התוקף, ודומיין זר לא יוכל להפיץ את התוכן שלכם.
כמה מהר מתעדכן תוכן אחרי ריליס?
סטטיקה עם האש בשם הקובץ מפורסמת מיד — הכתובת החדשה פשוט לא נמצאת במטמון. לכל השאר מגדירים זמן חיים מטמון נשלט ואיפוס ממוקד לפי מסכה מצינור הבנייה.
האם יהיה צורך לבנות מחדש את התשתית וה-DNS?
לא. השכבה מתייצבת לפני המקור: הדומיין מועבר ל-CNAME, תעודות מונפקות ומתחדשות אוטומטית. החזרה אחורה — על ידי החזרת הרשומה, זה עניין של דקות, לא חלון השבתה.
מה משתנה לעומת הפצה ישירות מהשרת?
סטטיקה עוברת לפריפריה, העומס על המקור יורד — השרת עוסק בדינמיקה וב-API. הדפדפן מקבל קבצים מהצומת הקרוב, וכללים בפריפריה מסירים בקשות מיותרות לפני שהן מגיעות לבקאנד.
תארו את סכימת ההפצה שלכם ואת מגבלות הגישה — נחזור עם הערכה ותוכנית עבודה.נדון במשימה: אילו נתונים דרושים להערכה
כדי לחזור עם הערכה, ולא עם טווח «מכאן עד כאן», אנחנו צריכים נתוני מקור על ההפצה שלכם. ככל שפרופיל התעבורה והסכימה הנוכחית מדויקים יותר, כך יש פחות הנחות בהערכת העבודה ובתוכנית היישום — ולכן פחות הפתעות בשלב ההחלפה.
- פרופיל תעבורה: עומס ממוצע ושיא, תנודות יומיות ושבועיות, שיעור הבקשות שבכלל ניתנות למטמון.
- גיאוגרפיה של משתמשים: אזורים עם עיקר הנפח, דרישות לקרבה של צמתי הפצה ולהשהיית ההגשה.
- סוגי תוכן: סטטיקה, קבצים גדולים, וידאו — עם ציון משך וצורך בדילוג בתוך הזרם.
- סכימת הפצה נוכחית: מקורות תוכן, דומיינים, כיצד מוגדרות כותרות מטמון וכיצד מתבצע כעת איפוס של תוכן מיושן.
- מגבלות: לוחות זמנים, חלונות אי-זמינות מותרים, דרישות לזמינות ולהתנהגות האתר בעת כשל של צומת בודד.
- הרשאות גישה: פאנל ניהול, ממשק תכנותי מנהל ואזורי DNS, אם התעבורה מוחלפת בצד שלנו.
בסוף אתם מקבלים הערכת עבודה, סכימת אזורים וכללי הפצה, וכן תוכנית יישום עם סדר החלפת תעבורה ונקודת החזרה אחורה לסכימה הקודמת. תארו את המשימה בצורה חופשית — מה נמצא איפה ומה כואב. נחזור עם הערכה ותוכנית.