CDN מבוזרת: היכן נשברת ההפצה הקלאסית
עומס שיא כמעט תמיד נתקל באותו מקום — המקור. כל עוד יש מעט בקשות, הוא מגיש קבצים ישירות ומתמודד, אבל הפרץ הראשון הופך את צוואר הבקבוק של הפצת התוכן לבעיה ממשית: הגשת הקבצים מתחילה להתחרות בשאר משימות השירות, זמן התגובה גדל, וחלק מהבקשות נקטעות בגלל חריגה ממגבלת הזמן.
לכך נוספים עומס יתר על המקור ונקודת כשל יחידה. הסכמה הקלאסית נשענת על מערכת מצומצמת של צמתים, וכשל של אחד מהם, שגיאת תצורה או אי-זמינות של אזור אצל הספק שוברים את ההפצה כולה — גם כשהמקור עצמו חי. ערוץ היציאה נשאר בתשלום וצר: כל בקשה חוזרת לאותו קובץ שוב מגיעה למקור.
CDN מבוזרת משנה את המסלול: הפצה נלקחת על ידי צמתי רשת בלתי תלויים, ושלמות הנתונים מאומתת באמצעות מיעון לפי תוכן — גישה שאותה מקדמת IPFS. המקור מגיש את הקובץ פעם אחת, הצמתים ממשיכים להפיץ בעומסי שיא, וכשל של צומת בודד אינו קוטע את ההפצה. בהמשך נפרט כיצד זה נסגר בפועל.
אפקט מדיד: זמינות, מהירות, עמידות
המדדים של המערכת המבוזרת נלקחים באותם כלים כמו אצל מקור בודד — משתנה טבעם של צווארי הבקבוק. להלן רשימת בדיקה שלפיה משווים את הגשת התוכן לפני ואחרי המעבר: כל סעיף נבדק על תעבורה אמיתית ועל בקשות ביקורת מאזורים שונים, אחרת המספרים אינם ברי-השוואה.
- זמינות התוכן — שיעור הזמן שבו האובייקט מוגש לפחות מצומת אחד. מחשבים לפי יומני נקודות הקצה ומחסירים חלונות דעיכה: היעד — היעדר נפילות כאשר צומת אחד או שניים נופלים.
- מהירות הגשה — חציון ואחוזון 95 של זמן עד בית ראשון לפי אזורים. מסתכלים דווקא על זנב ההתפלגות: הממוצע מסתיר נפילות אצל חלק מהמשתמשים.
- שיעור בקשות מוצלחות — היחס בין תגובות ללא שגיאות וזמני קצוב לסך הכול. בנפרד מתחשבים בניסיונות חוזרים: הם מסתירים כשלים ומנפחים את התמונה.
- עמידות בפני כשלים — כיבוי מבוקר של צומת או של אזור שלם ומדידה תוך כמה זמן הניתוב מעביר את הזרימה והאם זמן התגובה חוזר לנורמה.
- עומס על המקור — שיעור הבקשות שהגיעו לשרת המקור. לאחר המעבר הוא יורד פי כמה, והמקור מפסיק להיות נקודת כשל יחידה.
- עקביות גרסאות — שיעור הצמתים שמגישים את האובייקט המעודכן לאחר פרסום. אי-התאמה נראית מיד אם מפנים לאובייקט לפי תוכן: הגישה שהתוותה IPFS מאפשרת לצומת לבדוק שלמות בעצמו.
השוואת כל זה הגיונית בחלונות זמן ברי-השוואה ועם פרופיל בקשות זהה — אחרת ההשוואה מציגה הבדל בעומס, ולא את הרווח של הארכיטקטורה.
פורמטי פריסה של CDN מבוזרת
בחירת הסכמה קובעת מי מחזיק את הצמתים, כיצד מחושבת התמורה ועד כמה זמן ההשהיה בהגשה צפוי. במערכת מבוזרת יש שלושה שכבות: ניתוב בקשות, מטמון בצמתים וחישוב תשלומים עבור תעבורה שנמסרה. סכמות הפריסה נבדלות בכך אילו מהשכבות הללו אתם שולטים בהן ישירות, ואילו אתם מוסרים למשתתפי הרשת.
סכמות פריסה והמגבלות שלהן
| סכמה | מתי מתאימה | מגבלות |
|---|---|---|
| מערכת ציבורית | זנב ארוך של תוכן, קהל מפוזר בין אזורים | פיזור השהיות בין צמתים, שליטה חלשה בפרטיות הבקשות |
| הפצה היברידית | ליבת תעבורה במספר אזורים ובנוסף קפיצות חדות | שתי שכבות מטמון — נדרשת אי-תוקף מתואם |
| מערכת שותפים פרטית | דרישות רגולטוריות, נתונים רגישים | הקיבולת תלויה במספר השותפים, לא בביקוש |
הפצה היברידית היא הפשרה הנפוצה ביותר: הליבה המנוהלת נמצאת היכן שהקהל העיקרי נמצא, והמערכת הציבורית מתחברת בעומסי שיא. המחיר לכך הוא שתי שכבות מטמון, לכן אי-תוקף נעשה לפי גיבוב (hash) של האובייקט ולא לפי כתובת, אחרת חלק מהצמתים ממשיכים להגיש גרסאות מיושנות.
מערכת שותפים פרטית פותרת שאלות פרטיות, אך נתקלת במגבלת קיבולת: הצמיחה מוגבלת במספר השותפים המחוברים.
את הסכמה בוחרים לאחר ריצת עומס על פרופיל תעבורה אמיתי — אחרת המגבלות צפות כבר בתעבורה חיה, כששינוי טופולוגיית המערכת יקר.
שלבי הטמעה: מביקורת תעבורה ועד מסירה
סדר העבודות כמעט אינו תלוי בפרופיל העומס — משתנים הדגשים ומשך השלבים. מתחילים בנתונים, לא ברכישת משאבים: בלי מפת תעבורה, סכמת פריסת הצמתים הופכת לניחושים שיהיה יקר לשנות אחר כך.
- ביקורת תעבורה. אוספים יומני הגשה לתקופה שכוללת עומסי שיא: גאוגרפיה של בקשות, שיעור וידאו וסטטיקה גדולה מול דינמיקה, תדירות עדכון התוכן, פרופיל יומי. בפלט — מפת עומסים ורשימת אזורים עם ההשהיה הגרועה ביותר.
- תכנון המערכת. מגדירים טופולוגיה: מספר שכבות מטמון, היכן מציבים נקודות נוכחות, כיצד מפזרים תעבורה בין צמתים, אילו כללי אי-תוקף נדרשים. כאן גם מחשבים מודל תמרוץ למפעילי צמתים — אילו מדדים יוצרים תרומה וכיצד להתגונן מפני מניפולציה.
- הגדרת צמתים. פורסים סוכן מטמון, קובעים זמן חיים לאובייקטים, סדרי עדיפויות בהגשה ומגבלות רוחב פס, מקשרים צמתים באמצעות מפתחות חתומים. כל צומת מהיום הראשון נכנס לטלמטריה.
- בדיקת עמידות בכשלים. מכבים צמתים אחד-אחד ובמקטעים שלמים, מדמים אובדן אזור: ההגשה אינה נפסקת, אלא משנה מסלול. מתעדים זמן מיתוג ושיעור שגיאות בכל תרחיש.
- פיילוט על חלק מהתעבורה. מעבירים 5–10% מהבקשות ומשווים למערכת הקודמת לפי זמן תגובה, שיעור שגיאות ונפח תעבורת ניהול. סטייה במדדים — סיבה לחזור לתכנון.
- מסירה לתפעול. מוסרים תיעוד המערכת, גישות לטלמטריה, נוהל תורנות והוראות להוספת צמתים. פעולות שגרתיות מבצעת צוות הלקוח בעצמו.
הרכב האספקה: תצורות, סכמות, נהלים
לאחר מסירת הרשת ללקוח נשאר לא אוסף סקריפטים חד-פעמיים, אלא ערכה שלפיה אפשר להקים את הפלטפורמה מחדש, להרחיב ולהעביר לצוות אחר בלי הסברים בעל-פה. כל ארטיפקט מנוהל בגרסאות ונבדק בפריסה מאפס על מתקן נקי — אם פירוק והרכבה לפי התיעוד אינם עוברים, העבודה אינה נחשבת כמתקבלת.
- תצורות צמתים — תפקידים (מטמון, מעבר, מתאם), מגבלות רוחב פס ודיסק, פרמטרי חיבור מחדש וזמני קצוב; תבניות משוכפלות לאתרים חדשים בלי עריכה ידנית.
- סכמות רשת — טופולוגיה של רשת מעל (overlay), מסלולים בין מאגרי צמתים, נקודות יציאה לאינטרנט הרגיל, גבולות כשל והתנהגות בעת אובדן מקטע.
- מדיניות גישה — כללי קבלת צמתים לרשת, ספי מוניטין, סנקציות על תוכן שלא נמסר ונוהל ערעור למפעילים.
- נהלי תפעול — תרחישי תורנות לכל סוג כשל: דעיכה בהפצה, פער בפופולריות התוכן, זינוק בבקשות. עם ספי הפעלה וסדר פעולות שלב-אחר-שלב.
- תיעוד טוקנומיקה — נוסחאות חיוב וזיכוי, לוח זמנים של הנפקה, כללי חלוקת התשלום עבור הפצה בין צמתים בעומסים שונים.
- פריסה וניטור — תיאור תשתית כקוד, איסוף מדדים לכל צומת, לוחות השהיית הגשה ושיעור מסירות מוצלחות עם התראות מוגדרות.
- נוהל מסירה — קבלה בתרחיש כשל, הדרכת צוות הלקוח, חלון ליווי לאחר ההפעלה עם ניתוח אירועים.
הערכה מיועדת לכך שהרשת תתופעל על ידי הצוות שלכם, ולא על ידינו במנוי.
מקרה בוחן: גידול בהגשת תוכן לאחר המעבר
לפני המיגרציה הפלטפורמה Mediaflow הפיצה וידאו משני שרתים משלה באזור אחד. בעומסי שיא בערב הערוץ נתקע בתקרה: התחלת הניגון התארכה, חלק מהבקשות הסתיימו בשגיאה, ונדרש להפיץ עדכוני מטמון בין הצמתים ידנית.
מה שינו
את ההפצה העבירו ל-CDN מבוזרת, והותירו את אחסון המקור כמקור לעותק האחרון. את המטמון פיצלו לפי סוגי תוכן: קבצים מוכנים מקבלים TTL ארוך, רשימות השמעה — קצר, ואי-תוקף מופעל באירוע פרסום. בדיקות זמינות מוציאות צומת מהסבב בסימנים הראשונים של דעיכה, והתעבורה מתחלקת מחדש בלי מעורבות התורן.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הגשה מהמטמון | ~40% | 92% |
| עומס על המקור | תקרת הערוץ בעומס שיא | עשירית מהקודם |
| זמן התאוששות לאחר כשל צומת | 40 דקות של מיתוג ידני | 20–30 שניות אוטומטית |
| סוג הכשל | אי-זמינות של מדור שלם | נפילה של חלק מהצמתים, הצופה לא מבחין |
את המיגרציה הובילו בשלושה שלבים: פיילוט באזור אחד, שיקוף הספרייה, העברת כל התעבורה. בכל שלב נשמרה אפשרות לחזור לסכמה הקודמת, ולכן העבודה התנהלה בלי עצירת השירות ובלי "מיתוג גדול" בסופי שבוע.
במה נבדלת מערכת מבוזרת מספק קלאסי?
הפצה קלאסית היא מערכת שבה רשת הצמתים שייכת לחברה אחת ונמצאת באתרים שלה. הספק עצמו מציב עותקים מקומיים של התוכן, בוחר את המסלול עד המשתמש ומחזיק בהתחייבות לזמינות, והלקוח מגדיר דומיין, כללי הפצה ומשלם עבור נפח התעבורה.
הניהול והאחריות מרוכזים בידיים אחדות, לכן הצפיות גבוהה, אך הגידול בנפח נתקל בתעריף ובקיבולת הפיזית של האתרים.
CDN מבוזרת פועלת על צמתים השייכים למפעילים שונים: ספקי אחסון, מרכזי נתונים, בעלי ערוצים. הניהול כאן מפוצל — כללי ההפצה, מרשם הצמתים, בדיקת ההגשה בפועל והתחשבנות נמצאים אצל הפלטפורמה, ואילו הערוץ, החשמל והחומרה נשארים אצל בעל הצומת. מכאן ההבדל העיקרי: מופיע נוהל צומת ואחריות הפלטפורמה לאיכות הניתוב, ולא לכל יחידת חומרה.
הבחירה נקבעת לפי פרופיל התעבורה: הפצה המונית של קבצים גדולים וזנב ארוך של תוכן משתלמים במערכת מבוזרת, ואילו בקשות טרנזקציוניות עם דרישה נוקשה לזמן תגובה בטוחות יותר, לעת עתה, בסכמה קלאסית.
האפשרות המעשית לרוב הפרויקטים היא היברידית: הפצה מבוזרת של השכבה הכבדה ומערכת מנוהלת לבקשות קריטיות.
ספקות טכניים: עמידות, זכויות, תאימות
הספקות בשלב זה הם הנדסיים, ואינם נפתרים בטיעונים אלא בבדיקות: כיצד המערכת מתנהגת בכשל צמתים, מי מנהל את זכויות הגישה, ומה יהיה צורך לשנות בתשתית הנוכחית. להלן תשובות לכל סעיף, החל ממעבר חלקי: הוא מאפשר להשוות את סכמת ההפצה החדשה לקודמת על אותה תעבורה בדיוק.
מעבירים חלק מהתעבורה — תחילה סטטיקה וקבצים גדולים — ומחזיקים מדידה מקבילה בשני ענפי ההפצה. אם שיעור התגובות המוצלחות או זמן ההגשה יורדים, משקל המערכת בניתוב מוחזר בתיקון אחד.
מה יקרה אם חלק מהצמתים ייפלו?
כל אובייקט נשמר במספר עותקים אצל ספקים בלתי תלויים ובאזורים שונים, לכן נפילת צמתים פוגעת לא בזמינות, אלא במהירות ההגשה של קבצים נדירים. צמתים עם ירידה בזמן התגובה מוצאים מהסבב אוטומטית, ומדיניות השכפול קובעת את מספר העותקים ואת האזורים המועדפים בהתאם לגאוגרפיה שלכם.
מי מנהל את זכויות הגישה והמפתחות?
קישורים חתומים עם זמן חיים קצר מגבילים גישה לפי דומיין, זמן ואזור; רשימות הרשאות ברמת האובייקטים מסתירות קבצים פרטיים מהפצה ציבורית. מפתחות החתימה נשארים אצלכם, האישורים מונפקים לאותו דומיין, הרוטציה מתבצעת לפי נוהל, ויומן הפניות מתעד כל בקשה.
עד כמה זה תואם את התשתית הנוכחית?
שרת המקור נשאר מקור האמת: השכבה המבוזרת מתייצבת לפניו כשכבת הפצה, ולא במקומו. אם התוכן כבר מופץ דרך קצה חיצוני — למשל Cloudflare — המערכות פועלות במקביל, והניתוב מחלק ביניהן את חלקי התעבורה; חזרה לאחור היא החזרת המשקלים, והבנייה והעלאה של התוכן אינן משתנות.
נדון במשימה: נתוני פתח ותוכנית עבודה
כדי לדון במשימה באופן ענייני, דרושים לנו נתוני פתח, ולא תיאור כללי של הרעיון. מה בדיוק מפיצים — סטטיקה, וידאו, עדכונים — מה נפח התעבורה בשיא ובאילו אזורים, ואיזה שיעור בקשות אמור להיסגר על ידי צמתי קצה ולא על ידי מקורות.
הוסיפו מגבלות: דרישות לחישוב עבור תעבורה שנמסרה, איסורים רגולטוריים לפי גאוגרפיה, שרתים משלכם שניתן לחבר לרשת.
הרכב הצוות נבנה לאחר הניתוח: מהנדסים להפצה ולאיזון עומסים, מפתחי חוזים לתשלומים למפעילים, מומחה לתשתית ולניטור צמתים, אנליסט טוקנומיקה. הערכת לוחות הזמנים קשורה לנקודות ביקורת — רשת בדיקה, חיבור המפעילים הבלתי תלויים הראשונים, בדיקת החישובים, הגעה לעומס היעד. כך רואים את לוחות הזמנים לפי שלבים, ולא כמספר אחד "על העין".
לאחר הניתוח תקבלו:
- תוכנית עבודה לפי שלבים עם תלויות ונקודות ביקורת;
- הערכת לוחות זמנים בנפרד לרשת בדיקה ולהשקה תעשייתית;
- סכמת ארכיטקטורה: מה מחשיבים בחוזים, ומה מחוץ לרשת;
- מודל תגמול מפעילים וחישוב הנפקת טוקן;
- רשימת נתוני פתח שיש להבהיר לפני ההתחלה;
- סיכונים בלוחות זמנים ודרכים להפחיתם.
תארו את המשימה בצורה חופשית — נחזור עם הערכת לוחות זמנים ותוכנית עבודה, בלי ניסוחים כלליים.