למה Azure CDN לא מאיץ את האתר: ניתוח כשלים אופייניים
חיבור Azure CDN כשלעצמו לא מאיץ את האתר. אם כללי המטמון, התעודות וסדר הניקוי לא מוגדרים בהתאם למבנה האמיתי של הסטטיקה, המדדים לא משתנים: זמן התגובה נשאר כשהיה, העומס על המקור לא יורד, וחלק מהמבקרים רואים עמודים שבורים. הפצת תוכן אינה מתג הפעלה, אלא מערכת של פרמטרים תלויים זה בזה בתצורה.
הכשל הנפוץ ביותר — המטמון מגיש גרסה מיושנת של הסטטיקה. הצומת נשען על כותרות המטמון מהמקור: אם הן חסרות או שזמן החיים הוגדר לא נכון, הקבצים או לא נשמרים במטמון, או נשארים בו אחרי פרסום. לאחר העלאה של גרסה חדשה, הדפדפן מקבל סקריפט ישן יחד עם עיצוב חדש — הממשק מתפרק, והטופס לא נשלח.
הכשל השני — HTTPS נופל בתת-דומיין של הסטטיקה. התעודה הונפקה עבור הדומיין הראשי ואינה מכסה תת-דומיין נפרד, או שנשלחת שרשרת תעודות חלקית. הדפדפן חוסם משאבים כאלה: העמוד נפתח, אבל נשאר בלי תמונות ובלי עיצוב.
הכשל השלישי — המקור לא מתפנה מעומס. אם הצומת לא מגיש סטטיקה מהמטמון, כל בקשה ממשיכה לשרת האפליקציה, ושיא התעבורה מפיל אותו בדיוק כמו בלי הפצת תוכן. סיבה נפרדת — ניקוי מטמון ידני אחרי פרסום: הוא מבוצע לא עבור כל הנתיבים, וחלק מהמשתמשים עוד רואה תערובת של גרסאות זמן רב. נבחן כיצד כל אחד מהכשלים האלה נסגר.
מה נותן מטמון מוגדר היטב: אפקטים מדידים
הפרימטר ב-Azure CDN משנה את פרופיל העומס על המקור: חלק מהבקשות פשוט לא מגיעות אליו. להלן שלושה אפקטים שנראים במדדים אחרי ההגדרה, ולא בדוח על העבודה שבוצעה.
פריקת העומס מהמקור והסרת עומס השיא
את הסטטיקה — תמונות, גופנים, סקריפטים, עיצובים — מגישה נקודת נוכחות הקרובה למשתמש, ולא שרת האפליקציה. במקור נשארות בקשות לדינמיקה ול-API, ולכן בשיא — השקת קמפיין, פרסום קטלוג, כניסה המונית של עובדים — הוא מקבל פי כמה פחות חיבורים במקביל.
כללי מטמון לפי סיומת וזמן חיים קצר נפרד לסימון מספקים שיעור פגיעות צפוי במקום "לשמור הכול במטמון".
זמן תגובה יציב של העמוד בזינוקות תעבורה
כאשר התעבורה גדלה פי כמה, זמן התגובה נקבע לפי קיום עותק מוכן והמרחק לנקודת ההגשה, ולא לפי עוצמת השרת. סטטיקה עם זמן חיים ארוך יוצאת מהמטמון בלי לפנות למקור, ולכן גרף זמן התגובה נשאר יציב במקום לצנוח בשיא. ריצת עומס לפני ואחרי ההגדרה מראה את ההבדל בזנבות ההתפלגות, ולא בממוצע — דווקא שם רואים את הבעיות.
HTTPS אחיד והפניות נכונות בכל הדומיינים
התעודה נמצאת בפרימטר: חידוש והחלפת מפתחות אינם תלויים בתצורת שרת האינטרנט. כלל הפניה מכנס את הדומיין הראשי, הכינויים וה-HTTP לצורה קנונית אחת תוך שמירה על הנתיב ופרמטרי הבקשה, כך שלא נותרו כפילויות עבור סורקי החיפוש.
ניקוי המטמון מופעל מ-CI/CD מיד לאחר הפרסום — הקבצים המעודכנים זמינים בלי פעולות ידניות ובלי חלון שבו חלק מהמשתמשים רואים גרסה ישנה.
פרופילי Azure CDN: השוואת אפשרויות הפצה
פרופיל ההפצה קובע אילו כללי מטמון זמינים: בסט הסטנדרטי אלה הגדרות כלליות, ובמורחב — כללים לפי נתיבים, סיומות וכותרות בקשה. כדאי לקבע את הבחירה לפני החלפת הדומיין: חלק מהאפשרויות אינן תחליפיות זו לזו בלי החלפת נקודת הכניסה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פרופיל הפצה סטנדרטי | סטטיקה, אותה לוגיקה לכל המדורים | הגדרות כלליות, אין כללים לפי נתיבים |
| פרופיל עם כללים מורחבים | ל-API, לסטטיקה ולמדיה זמן חיים שונה | יש לגרס את הכללים ולבדוק אותם |
| פרוקסי הפוך משלך עם מטמון | נדרש שליטה על מפתח המטמון ועל ביטול התוקף | צומת נפרד שיש לתפעל |
| מטמון במקור | תגובות מאומתות, נתונים פרטיים | הערוץ לא מתפנה מעומס, הרווח רק בחזרות |
כללי מטמון לפי נתיבים
כלל לפי נתיב קושר את ההתנהגות לקידומת הכתובת: /api/ — בלי מטמון, /static/ — שעה, /media/ — יממה. ההתאמה הראשונה בדרך כלל עוצרת את הניתוח, ולכן יוצאי דופן שמים מעל מסכות כלליות, אחרת תגובות אישיות ייכנסו למטמון הכללי.
כללים לפי סיומות קבצים
כללים לפי סיומות (.css, .js, גופנים, תמונות) נקראים בקלות רבה יותר ומכסים את כל הבנייה. נקודת התורפה — כתובות בלי סיומת ופרמטרי גרסה בבקשה: אותם מתארים בנפרד, אחרת לאחר עדכון הקובץ הלקוח יקבל את העותק הקודם.
בפועל, פרופיל מורחב מעל מטמון במקור נותן זמן חיים צפוי לסטטיקה וניקוי דרך API מתהליך הבנייה — בלי להמתין לפקיעת התוקף לאחר ההעלאה.
סדר היישום: מביקורת תוכן ועד מסירה
את המטמון ב-Azure CDN מגדירים באיטרציות: קודם מקבעים מה בדיוק מוגש, אחר כך מתארים את הכללים, ורק לאחר מכן מפעילים את התעבורה הראשית. הסדר מונע מצב שבו המטמון כבר מגיש תוכן, והכללים עבורו עוד לא הוגדרו.
- ספירת מלאי של דומיינים וסוגי תוכן. אוספים שמות ותת-דומיינים, מסמנים סטטיקה, מדיה, קבצי בנייה ותגובות שירותים. עבור כל סוג מציינים אם הוא נשמר במטמון או עובר בעקיפין.
- סכמת מטמון. קובעים זמני אחסון לפי קבוצות קבצים, כללים להתחשבות במחרוזת השאילתה והתנהגות בעת עדכון: קבצים עם גרסה מקבלים זמן ארוך, נקודות כניסה — קצר.
- קישור הדומיין. מחברים נקודת נוכחות, מקשרים את הדומיין, בודקים את התאמת רשומות הדומיין ואת סדר ההגשה.
- תעודה ו-HTTPS. מנפיקים תעודה, מפעילים HTTPS כפוי והפניות, בודקים את השרשרת בכל תת-דומיין.
- ניקוי מטמון בצינור. מטמיעים שלב ניקוי אחרי הפרסום — הבנייה בעצמה מנקה את מה שהשתנה, בלי פעולות ידניות של תורן.
- בדיקה ומסירה. מריצים תרחישים, מתעדים את התוצאה, מוסרים הרשאות גישה, סכמה ותקנון.
בדיקת תרחישים
את הבדיקה בונים על נתיבים אמיתיים: עדכון קובץ בודד, החזרה מלאה של פרסום, החלפת תעודה, ניקוי לפי מסכה. תרחיש נחשב לעבר בהצלחה רק כאשר הגרסה החדשה נראית בכל הנקודות, והגרסה הישנה לא חוזרת ממאגרי ביניים.
פרסום ראשון ומסירה
את הפרסום הראשון מובילים עם נתח תעבורה מופחת: חלק מהבקשות עובר דרך רשת ההפצה, וחלק ישירות. כאשר שיעור הפגיעות במטמון וזמן ההגשה תואמים את הצפוי, מעבירים את כל הזרימה וסוגרים את השלב במסירת הרשאות גישה, סכמה ותקנון.
תיעוד, סכמות ותקנונים לאחר היישום
לאחר ההפעלה של Azure CDN נשאר אצל צוות הלקוח סט מסמכים שלפיו מבצעים שינויים בלעדינו. זו גם נקודת הכניסה למהנדס חדש: ממנה רואים למה כלל המטמון הוגדר דווקא כך ומה יקרה בעת החזרה לאחור.
תצורה וכללי גישה
- כללי מטמון בתצורה מוכנה: קובץ במאגר, שבו לפי נתיבים וסיומות מוגדרים זמני אחסון — סטטיקה עם זמן ארוך, HTML ותגובות API עם זמן קצר או עם עקיפה מלאה של המטמון.
- מפת נקודות נוכחות: אילו צמתים משרתים את הקהל, היכן מופעל דחיסה והיכן היכולות מצומצמות, כדי לא להכניס לכללים משהו שלא יעבוד בחלק מהאזורים.
- הגדרות HTTPS והפניות: קישור תעודה (מנוהלת או עצמאית), מעבר כפוי מ-HTTP, גרסת TLS מינימלית, כללי שכתוב נתיבים.
- מטריצת גישה: מי משנה כללים, מי רק צופה במדדים, מי מפעיל ניקוי מטמון.
תקנון פרסום
- שלב ניקוי מטמון מובנה: לאחר ההעלאה הצינור מפעיל ניקוי לפי מסכת נתיבים ותגים, ממתין לאישור וממשיך הלאה רק בהצלחה — אחרת הפרסום נעצר.
- סדר הוצאת גרסאות: בנייה, העלאה, ניקוי, חימום, בדיקה — עם ציון אילו שלבים בטוח לחזור עליהם.
- הוראות בדיקה והפקת מדדים: בקשות בקרה לנתיבים מרכזיים, מצב המטמון בכותרת התגובה, שיעור הפגיעות וזמן התגובה של הצמתים, עם ספי אזהרה לחזרה לאחור.
מקרה בוחן: כיצד פינו את המקור מעומס וייצבו את התגובה
מה היה לפני ההגדרה
ויטרינה עם סטטיקה כבדה: תמונות קטלוג, עיצובים, סקריפטים, גופנים. המטמון ב-Azure CDN חי עם זמן קצר אחד לכל סוגי הקבצים ובלי קישור לגרסאות הבנייה — מהמטמון הוגשה רק שליש מהבקשות, והשאר עבר למקור.
בשעות שיא זמן התגובה גדל יחד עם התעבורה, ואחרי פרסום צץ סוג נפרד של כשלים: הסימון במשך כמה דקות הפנה לקבצים שעוד לא היו בפרימטר.
מה עשינו
הפרדנו את כללי המטמון לפי סוגי תוכן: קבצי בנייה עם גרסה קיבלו זמן חיים ארוך, HTML — קצר עם אימות מחדש חובה, ותגובות API הוצאו מהמטמון. לצינור הוספנו שלב ניקוי — המטמון מבוטל לפי מסכות לאחר פרסום הארטיפקטים ולפני החלפת התעבורה.
אילו מדדים התקבלו
שיעור הפגיעות במטמון עלה משליש לרוב — כארבע חמישיות מהבקשות. מספר הפניות למקור קטן בערך פי שלושה, והתגובה בשיא הפסיקה לגדול: זמן התגובה נשמר ברמה של שעות לא-שיא.
הסוג "סטטיקה שבורה אחרי פרסום" נסגר — חלון אי-ההתאמה בין ההעלאה לבין ביטול התוקף בוטל. לא נדרשו החזרות לאחור: הארטיפקטים הקודמים חיים במטמון עד סוף התקופה, ולכן החזרה לגרסה הקודמת נשארת מיידית.
במה שונה ניקוי מטמון מגירסה של סטטיקה?
ב-Azure CDN ניקוי כפוי (purge) מסיר אובייקט מצמתי הנוכחות בלי להמתין לפקיעת זמן החיים של המטמון. הפעולה אסינכרונית: התשובה מגיעה מיד, אבל מתפשטת בין הצמתים בדקות, ולכן בין ההעלאה לתוכן חדש מובטח נשאר חלון. הניקוי מוגדר לפי נתיב מדויק או לפי מסכה — מסכה נוחה יותר, אבל פוגעת בכל מה שהתאים לתבנית.
גירסה של סטטיקה פותרת את אותה משימה אחרת: הבנייה שמה hash בשם הקובץ, והסימון מפנה לכתובת החדשה. הקובץ הקודם נשאר זמין, והחדש עוד לא נראה בצמתים — ביטול תוקף לא נדרש באופן עקרוני. תופעת לוואי — גרסאות ישנות מצטברות במאגר, ולכן מנקים אותן בכלל נפרד של מחזור חיים.
הבחירה מוכתבת על ידי יכולת שינוי השם. סקריפטים, עיצובים, גופנים ותמונות מקבלים גרסה, ומוקצב להם זמן חיים ארוך עם סימן אי-שינוי — הדפדפן מפסיק לשאול שוב. כתובות עם שם קבוע — סימון, מניפסט, תצורות — לא מקבלות גרסה כך, ועבורן נשאר רק ניקוי.
בפועל אלה שתי מדיניות בהפצה אחת. את הסימון מגישים עם זמן חיים קצר ומנקים לפי מסכה מהצינור של הבנייה, נכסים — עם זמן ארוך ובלי ניקוי בכלל. ניקוי מטמון לפי מסכה כמו קטלוג עם כל הנכסים הוא מסוכן: ביטול תוקף המוני דוחף תעבורה למקור וקל מאוד לפגוע בשיא העומס.
לסיכום: החלפת שם היא הנורמה עבור קבצים נבנים, וניקוי — עבור כתובות קבועות. לא כדאי לערבב את שתי האסטרטגיות בכלל אחד.
שאלות טכניות נפוצות על מטמון ו-HTTPS
מטמון בקצה לא מבטל את הלוגיקה של האפליקציה: קודם המקור מחליט אם התגובה תלויה במשתמש, ורק אחר כך התגובה נכנסת למאגר בקצה. לכן כמעט כל הספקות במסירת ההגדרות — בשאלה היכן עובר הגבול בין סטטיקה לתגובה אישית, ומי שולט בו: כלל בקצה או כותרות המקור.
להלן חמש שאלות שעולות לרוב ביותר בקבלה ובשבועות הראשונים של התפעול.
האם בכלל אפשר לשמור במטמון עמודים דינמיים עם התאמה אישית?
אפשר, אבל באופן סלקטיבי. בקשות עם cookie של אימות וכותרות אימות עוברות בעקיפין למטמון, ורק GET אנונימיים נשמרים במטמון. עבור עמודים אישיים המקור נותן איסור אחסון — ואז הקצה לא מחזיק את התגובה אפילו שנייה, והנתונים לא דולפים בין משתמשים.
למה אחרי פרסום חלק מהמשתמשים רואים גרסה ישנה של העמוד?
פער גרסאות נוצר כאשר הסימון וקבצי הממשק חיים עם זמני חיים שונים. את הסימון מגישים עם זמן חיים קצר, ואת הקבצים — עם זמן ארוך ו-hash בשם, כדי שהסטים הישן והחדש לא יתערבבו באותו עמוד.
ניקוי המטמון בנתיבים שהשתנו מבוצע בצינור הבנייה לפני החלפת התעבורה: ביטול התוקף לא מתפשט בין הצמתים באופן מיידי.
מה יקרה לאתר בעת חידוש התעודה?
תעודה מנוהלת מתחדשת אוטומטית אם הדומיין מפנה לקצה באמצעות רשומת CNAME ואינו עובר פרוקסי דרך שירות צד שלישי — בדיקת הבעלות עוברת דרך DNS. עם תעודה עצמאית, החדשה נטענת מראש, והקודמת נשארת פעילה עד סוף החפיפה: ניתוק החיבור ואזהרות בדפדפן לא מתרחשים.
שינויים במקור לא מופיעים — מה לבדוק קודם?
קודם כל הכותרות של המקור עצמו: הן בעדיפות על כללי הקצה. אחר כך — האם מחרוזת השאילתה נכנסת למפתח המטמון: בהיעדרה, כתובות עם פרמטרים שונים מחזירות את אותה תגובה. ושלישית — האם כלל העקיפה לפי cookie רחב מדי, בגללו המטמון בכלל לא מתמלא.
איך לוודא שהמטמון באמת עובד?
מסתכלים על סימן הפגיעה וגיל התגובה בכותרות, ולא רק על זמן הטעינה בדפדפן. בודקים מכמה אזורים ולפי סוגי קבצים שונים, ואז מקבעים בצינור בדיקה: אחרי ניקוי המטמון התגובה חייבת להתעדכן. כך תופסים נסיגה בהגדרה לפני תלונות המשתמשים.
נדון במשימה: מה להכין לקראת תחילת העבודה
הערכת ההגדרה של Azure CDN מואצת בדיוק במידה שבה נתוני הקלט מלאים. כאשר דומיינים, סוגי תוכן וסכמת סביבות נאספים בחלקים, אנחנו מבזבזים זמן על הבהרות במקום על תכנון כללי מטמון. להלן הסט המינימלי שאיתו אפשר מיד לחשב ארכיטקטורה.
- רשימת דומיינים ותת-דומיינים — עם ציון אילו מגישים סטטיקה, אילו משמשים כפרוקסי ל-API ואסור לשמור אותם במטמון כלל. בנפרד — תוכניות לשמות חדשים ולסדר קישור התעודות.
- סוגי תוכן וחלקי סטטיקה — אילו נתיבים נשמרים במטמון זמן רב, אילו נבדקים מחדש בכל בקשה, והיכן התוכן משתנה לעתים קרובות. זה קובע את הכללים לפי סיומות, נתיבים וכותרות תגובה.
- סכמת סביבות — כמה סביבות יש, כיצד מתקני הבדיקה מופרדים מפרודקשן, האם נדרשים פרופילים נפרדים וכיצד מתחלקת התעבורה בין המקורות.
- מצב HTTPS נוכחי — היכן מנפיקים תעודות, האם יש תעודות עצמאיות, האם נדרשת הפניה כפויה וגרסת פרוטוקול מינימלית.
- סדר הוצאת גרסאות — כיצד היום מעלים בניות, מה מפעיל ניקוי מטמון ומה צריך לקרות בעת חזרה לגרסה קודמת.
- כללי גישה ותפקידים — מי מנהל את הפרופיל, כיצד מוענקות הרשאות ולאילו סביבות, והאם נדרשת הפרדה בין צוותים.
- מגבלות המקורות — מאגרים סגורים, מאזני עומס, מגבלות גאוגרפיות ודרישות ליומני בקשות.
תארו את המשימה בהיקף הזה — נחזור עם הערכה ותוכנית עבודה, כולל סכמת מטמון, סדר חיבור HTTPS ושלב ניקוי מטמון בצינור ההוצאה לאור.