הגדרת Akamai CDN: היכן נשברת הפצת התעבורה
ההפצה נשברת לא בשלב החיבור ל-CDN, אלא בתפעול, כשהקונפיגורציה מתמלאת בחריגים. ב-Akamai הכללים חיים ב-Property Manager ומפורסמים בגרסאות: תחילה לסביבת בדיקה, ואחר כך לסביבת הפרודקשן.
פער גרסאות בין אזורים הוא הסיבה השכיחה ביותר לכך שאצל חלק מהמשתמשים המטמון מתנהג אחרת מאשר אצל האחרים.
צוואר הבקבוק הראשון של הפצת תוכן הוא התנהגות המטמון בשיא. אם זמן החיים של התגובה נקבע לפי שאריות, ומפתח המטמון כולל כותרות שמשתנות מבקשה לבקשה — מזהה סשן, תגי קמפיין, שפה — שיעור הפגיעות יורד, והעומס בשיא על המקור גדל פי כמה. מקור שתוכנן לתעבורה ממוצעת מתחיל להחזיר 502 ו-504 בדיוק כשההפצה היא הדבר החשוב ביותר.
השני — כללי מטמון שמתפצלים בין אזורים גאוגרפיים לסביבות. כלל שנוסף רק לגרסת הפרודקשן נעלם בפרסום הבא ממערכת ניהול הקונפיגורציה; חריג עבור אזור אישי, שנשכח באחת מקבוצות האזוריות, מביא לכך שתגובות מותאמות אישית עוברות למטמון המשותף. ניטור זמינות לא תופס פערים כאלה — הם מתבטאים כ"פעם מהר, פעם לאט".
השלישי — ניתוב למקור: בלי אזורי האצה מוגדרים במפורש ונתיבים חלופיים, התעבורה עוברת במסלול אקראי, והזמן עד הבית הראשון גדל פי כמה בלי סיבה. להלן נפרט כיצד זה נסגר: ממבנה הכללים ומפתח המטמון ועד ניהול קונפיגורציה כקוד.
האפקט מההגדרה: מהירות הפצה, פגיעות במטמון, יציבות
האפקט מההגדרה נמדד בשלושה מספרים: שיעור הבקשות שמוגשות על ידי צומתי המטמון בלי פנייה למקור, זמן התגובה למשתמש הקצה, ומרווח לעומס שיא. אנו מעבירים את הפצת התוכן לפריפריה של Akamai — להלן כיצד משתנה כל מדד ואילו תקלות מפסיקות להגיע למשתמש.
שיעור הפגיעות במטמון
את הכללים מגדירים לפי סוגי תוכן: סטטי, מדיה, תגובות של בקשות יישומיות — עם זמן חיים משלהם למטמון, התחשבות בפרמטרים של הבקשה ובכותרות. רוב הבקשות נסגרות בצומת הקרוב, ולמקור עוברות רק החמצות ועדכונים. בסטטי שיעור הפגיעות מגיע ל-90% ומעלה — קודם לכן הבקשות האלה נפלו כולן על המקור.
זמן התגובה למשתמש הקצה
התוכן מוגש מהצומת הקרוב, ולא דרך יבשת: מצטמצמים המרחק ברשת וזמן כינון החיבור. בדינמיקה פועלים מסלולים מותאמים בין צומתים וחיבורים קבועים למקור — התגובה מפסיקה להיות תלויה במרחק לשרת. החציון של זמן התגובה יורד פי כמה, והפיזור בין אזורים מצטמצם.
יציבות לשיאים והסרת עומס מהמקור
פרצי תעבורה נבלמים על ידי צומתי המטמון, והמקור מקבל זרם אחיד של החמצות במקום שיא. נעלם סוג של תקלות הקשורות לעומס יתר: פסקי זמן, ירידה בהפצה, שגיאות משורשרות בשירותים תלויים. השקת קמפיינים ועדכוני תוכן המוניים מפסיקים לדרוש הרחבת תשתית מראש.
את המדדים אנו לוקחים לפני ואחרי: שיעור הפגיעות, זמן התגובה לפי אזורים, נפח התעבורה שהגיע למקור. לפיהם אנו מגדירים מטמון וכללי ניקוי מטמון, כדי שהאפקט יישמר ולא יושג פעם אחת.
סכמות הפצת תוכן CDN: מתי מה מתאים
סכמות הפצת תוכן נבחרות לא לפי נפח התעבורה, אלא לפי פרופיל התגובה והשהיה המותרת. בקונפיגורציה אחת של Akamai המצבים האלה משתלבים: חלק מהנתיבים מוגשים ישירות מהשרתים, חלק מהמטמון בצומתים, וחלק משכבה מתווכת.
אנו מפרידים את האפשרויות לפי ארבעה מאפיינים — יכולת מטמון, גאוגרפיה, משקל האובייקטים ודרישות מהמקור.
| סכמה | מתי מתאימה | מגבלות |
|---|---|---|
| הפצה ישירה מהשרתים | תגובות מותאמות אישית, מדורים סגורים, תוכן עם זמן חיים קצר | אין מטמון — כל העומס והשהיה נופלים על שרת המקור |
| רשת הפצה קלאסית | סטטי, מדיה, קטלוג, דפים עם זמן אחסון ארוך | בהחמצת מטמון הבקשה עוברת למקור מכל צומת |
| הפצה רב-שכבתית | קבצים כבדים, אזורים רבים, אכלוס מטמון יקר | נדרשת שכבה מתווכת וכללים לאכלוסה |
| מחשוב פריפריאלי בצומתים | אימות, הזרקת נתונים, הרכבת תגובה ליד המשתמש | את הלוגיקה בפריפריה מתחזקים ובודקים בנפרד |
בפועל: מתחילים בהפצה קלאסית ומפעילים רב-שכבתית כשהמקור מפסיק להתמודד עם אכלוס המטמון. החלפת סכמה היא עריכת כללים ב-Property, בלי לבנות מחדש את מבנה האתר ובלי ריליס חוזר. המצבים מתערבבים לפי נתיבים: מדיה וסטטי עוברים דרך המטמון, והשלמת הזמנה — ישירות.
שלבי העבודה: ביקורת תעבורה, סכמת מטמון, בדיקה
הגדרת Akamai CDN יוצאת לא מעריכת קונפיגורציה, אלא מנתונים: אנו לוקחים מפת תעבורה, מתכננים סכמת מטמון, ורק אחר כך מפעילים כללים בזרם החי. דילוג על ביקורת נותן מטמון "בעין": סטטי ותגובות מותאמות אישית עוברים תחת כלל אחד, והחזרה לאחור נעשית בעיוורון.
- ביקורת מפת תעבורה: מנתחים יומנים ופרמטרים של בקשות — אילו נתיבים סטטיים, אילו תלויים בסשן, היכן גופים גדולים, וכיצד הפניות מתפלגות לפי אזורים. בפלט — קבוצות תוכן עם זמן חיים וסימנים לסיווג הבקשה.
- תיאום סכמת מטמון: עבור כל קבוצה מחליטים מה נשמר בגבול הרשת ומה עובר לשרת המקור, אילו כותרות ו-cookie מועברים הלאה ואילו נחתכים, כדי לא להרבות עותקים ייחודיים.
- תכנון כללים ב-Property Manager: מרכיבים אותם לפי עדיפויות — ניתוב, התנהגות בהחמצת מטמון, טיפול בשגיאות מקור, הגשת אובייקט מיושן. קובעים איזה תנאי מופעל ראשון בעת חפיפה.
- הרכבה בסביבה מתווכת: דומיין בדיקה, השוואת כותרות תגובה, שיעורי פגיעות במטמון והתנהגות כשהמקור לא זמין. שגיאות קונפיגורציה תופסים כאן, ולא בזרם.
- בדיקה בתעבורת פרודקשן: מפעילים כללים בשלבים, עוקבים אחר שיעור הפגיעות, זמן התגובה לפי אזורים ושיעור השגיאות. בחריגה — חזרה לגרסה הקודמת בלי לעצור את ההפצה.
- מסירת השליטה: מוסרים מפת תעבורה, סכמת מטמון, תיאור כללים וסדר עריכות אופייניות, כדי שצוות הלקוח ישנה הגדרות בעצמו ויבין את ההשלכות.
קונפיגורציות מאפיינים, כללי מטמון ונהלים
קונפיגורציה של מאפיין ב-Akamai היא לא אוסף תיבות סימון בממשק ווב, אלא ארטיפקט מגורסן שאפשר להשוות, להחזיר לאחור ולהעביר לצוות אחר. אנו משאירים ללקוח ערכה מלאה: לאחר ההפעלה, עריכות בהתנהגות המטמון ובניתוב מבוצעות על ידי הצוות שלו עצמו, בלי לפנות אלינו לכל שינוי.
- קונפיגורציות מאפיינים — תיאורים מיוצאים בפורמט קריא, מסודרים לפי סביבות: בדיקה, קדם-פרודקשן, פרודקשן. שינוי עובר בדיקה בסביבה הנמוכה לפני העלאה לפרודקשן.
- כללי מטמון — זמן חיים לכל סוג תוכן, מפתחות מטמון, התחשבות בפרמטרי בקשה, סדר ניקוי המטמון אחרי ריליס. בנפרד מתוארות כתובות שאסור לשמור במטמון.
- סכמות נתיבים — מאיפה ולאן עוברת התעבורה, אילו מקורות ראשיים וגיבוי, כיצד מוגדרות בדיקות זמינות ומעבר בעת כשל.
- מדיניות גישה — הגנת תוכן, הגבלות לפי אזורים ותדירות פניות, כללים לסוכנים של חיפוש ולסוכנים שירותיים, חלוקת הרשאות בתוך הצוות.
- נוהל שינויים — מי מכין את העריכה, מי מאשר, אילו בדיקות חובה לפני פרודקשן וכיצד מתבצעת חזרה לגרסה קודמת.
- סדר פעולות באירוע — ניקוי וחימום מטמון, אבחון מקור, נקודות הסלמה וגבולות אחריות של הצדדים.
סוגר את הערכה מסמך עם תיאור כל הסכמה וניטור מוגדר של צומתי המפתח. לפיו מהנדס חדש בצוות מבין את הקונפיגורציה ביום עבודה אחד, ולא משחזר את הלוגיקה מהתכתבות.
מקרה בוחן: הפצה יציבה בזינוק חד בתעבורה
הלקוח — חנות מקוונת עם מבצעים עונתיים: בשיא התעבורה גדלה פי 6-8 בתוך שעות ספורות, ועל הרקע הזה האתר התחיל להחזיר שגיאות. המקורות תוכננו לעומס ממוצע, ורשת ההפצה עבדה כמעט במצב העברה ישירה — צומתי הפריפריה העבירו בקשות הלאה, כדי לא להסתכן בתגובה מיושנת.
צווארי בקבוק לפני העבודה
- מטמון הסטטי עבד חלקית: המפתח כלל תגי קמפיינים פרסומיים, ולכן כל מעבר בקישור יצר אובייקט נפרד.
- זמני החיים לתמונות, סקריפטים ותגובות שירותים היו זהים ומינימליים.
- בהחמצת מטמון כל הבקשות עברו למקור בזרם אחד, בלי הגבלה ובלי עדכון ברקע.
תוצאה
כתבנו מחדש את כללי הטיפול בפריפריה: הסרנו פרמטרים מיותרים ממפתח המטמון, הפרדנו מדיניות לפי סוגי תוכן, הוספנו עדכון ברקע לאובייקטים פופולריים והגנה על המקור מפני בקשות בו-זמניות.
את הניתוב לצומת הקרוב ואת ניקוי המטמון קישרנו לריליס, כדי שההעלאה לא תאפס את כל הפריפריה — עבדנו על Akamai.
| מדד | לפני | אחרי |
|---|---|---|
| תגובות מהפריפריה | 46% | 91% |
| זמן תגובה בשיא | עד 5 שנ׳ | 0.4-0.6 שנ׳ |
| שיעור שגיאות בשיא | 7% | פחות מ-0.3% |
עומס יתר על המקור הפסיק להיות סיכון עונתי: בהחמצת מטמון העומס מתפזר, ולא נופל בבת אחת. החזרה לאחור של כללים אורכת דקות — הקונפיגורציה מגורסנת.
במה ניהול דרך פאנל שונה מקונפיגורציה כקוד?
שתי הדרכים מנהלות את אותה מודל כללים של Akamai — סט של התנהגויות ותנאים שלפיהם מופץ התעבורה. ההבדל הוא היכן נשמר מקור האמת: בחשבון או במאגר, וכמה גלוי השינוי בו.
בפאנל ההגדרות חיות כמצב של גרסת קונפיגורציה מסוימת. היסטוריית גרסאות קיימת, אך היא לא מקושרת למאגר: ביומן רואים שהכלל שונה, ולא אילו שורות בו השתנו. לשחזר סביבה מאפס אפשר רק בחזרה ידנית על השלבים — וכל פער צף כבר בתעבורת הפרודקשן.
קונפיגורציה כקוד מעבירה את אותם כללים לקבצים. לאחר מכן פועלות המכניקות הרגילות: ענף, ריוויו, פריסה אוטומטית, השוואת גרסאות לפני הפעלה.
חזרה לאחור — הפער העיקרי. בפאנל זו הפעלה של הגרסה הקודמת בשלמותה, עם כל מה שהספיק להיכנס אליה. בקוד, חזרה לאחור היא קומיט הפוך: רואים איזה כלל חזר לערך הקודם, והשאר לא נפגע.
ספקות טכניים: מטמון, ביטול תוקף, הרשאות
ההתנגדויות לגבי מטמון מצטמצמות בדרך כלל לשלושה דברים: כמה מהר העריכה תגיע למשתמשים, האם המטמון יתחיל להגיש תוכן של אחרים, ומי בכלל יכול לשנות את הקונפיגורציה.
כל השלושה נפתרים ברמת הכללים, ולא על ידי כיבוי המטמון "ליתר ביטחון" — בלעדיו הקצה מאבד את משמעותו, והעומס עובר ל-origin.
אנו מפרקים את התנהגות המטמון לשכבות: מה בדיוק נשמר בקצה, לפי איזה מפתח (כתובת, פרמטרי בקשה, cookie, כותרות), איזה זמן חיים לתוכן מוגדר לכל סוג אובייקט ומה קורה בהחמצה.
ביטול תוקף של מטמון הוא מעגל נפרד: ממוקד לפי כתובת או תג מיד אחרי ריליס, ובנוסף זמן חיים סביר כרשת ביטחון, אם הניקוי לא הגיע לאנשהו.
כמה מהר העדכון יגיע למשתמשים?
ביטול תוקף לפי תגים מסיר מהקצה את כל האובייקטים הקשורים בקריאה אחת, במקום לעבור על כתובות. הניקוי מתפשט בגלים בין אזורים, ולכן את התוצאה אנו בודקים תחילה בסביבת הבדיקה ורק אחר כך מפעילים בפרודקשן. עבור סטטי עם hash בשם הקובץ אין צורך בניקוי כלל — הכתובת עצמה משתנה.
האם המטמון לא יתחיל להגיש דפים מותאמים אישית לאחרים?
עבור תגובות מאומתות ואישיות הכלל אוסר על אחסון, ומפתח המטמון מורחב ב-cookie או בכותרת — אז משתמשים שונים פיזית לא מצטלבים על אותו אובייקט. בנפרד אנו בודקים תרחישים עם סל קניות וטוקנים של סשן: הם עוברים ל-origin בעקיפת המטמון.
כיצד לחלק הרשאות לניהול הקונפיגורציה?
הרשאות ניתנות לפי תפקידים: מהנדס עורך ומפעיל, מהנדס ריליס מאשר פריסה, צופה רק רואה. עריכות עוברות דרך עותקים נפרדים של הקונפיגורציה עם היסטוריית גרסאות, כך ששינוי לא מוצלח מוחזר על ידי החזרת הגרסה הקודמת. הגישה דרך API חסומה במפתחות נפרדים עם הגבלה לפי כתובת ותוקף פעולה.
נדון במשימה: תעבורה, גאוגרפיה, דרישות הפצה
כדי שההערכה תהיה מדויקת, והתוכנית — ברת ביצוע, אנחנו צריכים לא רשימת משאלות, אלא עובדות על התעבורה שלכם. מהן תלוי אילו כללי מטמון וניתוב נניח, ואיזה שיעור בקשות בכלל יגיע למקור.
מה כדאי להכין לדיון:
- פרופיל תעבורה: שיעור הסטטי והדינמי, נפחים ביממה, שיאים ממבצעים והתפרצויות עונתיות.
- גאוגרפיה של משתמשים: אזורים ומדינות שעבורם השהיית ההפצה קריטית.
- דרישות הפצה: זמן תגובה יעד, שיעור החמצות מטמון מותר, התנהגות כשאין זמינות למקור.
- סכמה נוכחית: מה כבר עומד לפני השירות, אילו כללי הפניה ומטמון מוגדרים.
- מגבלות: נהלים לאחסון ועיבוד נתונים, דרישות לאזורים מסוימים, תפקידי גישה.
- אבני דרך בלוחות זמנים: מה נדרש להשקה, ומה אפשר להעביר לשלב הבא.
זה מספיק כדי לחזור עם הערכה ותוכנית: סכמת הפצה לפי אזורים, כללי מטמון וניקוי מטמון, הגדרת Akamai CDN לפרופיל העומס שלכם, מדיניות אבטחה וסדר הכנסת שינויים עם אפשרות חזרה לאחור. תארו את משימת ההפצה — בואו עם מה שכבר נאסף, ואת החסר נבהיר תוך כדי.