הגדרת מטמון CDN: TTL לתוכן סטטי, API, HTML

הגדרת CDN שבה המטמון לא שובר את הדינמיקה

קישוב ב-CDN שובר את הדינמיקה לא בגלל TTL קצר, אלא בגלל היעדר כלל: מה מותר להגיש מהקצה, ומה חייב להגיע למקור. כאשר סטטיקה, HTML ותשובות API מטופלים על ידי מדיניות אחת, חלק מהדפים קופאים בצורה מיושנת, וחלק מפספסים את המטמון בכל בקשה — והמקור מקבל את אותו עומס כמו בלי CDN.

החמצות מטמון הן כמעט תמיד תוצאה של המפתח. אם המפתח כולל את כל פרמטרי מחרוזת השאילתה וכותרים המשתנים ממשתמש למשתמש, אותו קובץ נשמר בעשרות עותקים: שיעור הפגיעות יורד לאחוזים בודדים, והעומס על המקור גדל פי כמה. המפתח נבנה לפי משמעות המשאב, ופרמטרים מיותרים נחתכים בקצה — ואז בקשות חוזרות אכן מטופלות מהמטמון.

סטטיקה עם hash בשם הקובץ חיה זמן רב ומתעדכנת בלי ביטול תוקף: קובץ חדש מגיע לכתובת חדשה, ואין צורך באיפוס מטמון כלל. עם HTML זה לא עובד — הדף מסומן כמהימן לכאורה, עם בדיקה לפי ETag, או שניתן חלון חיים קצר עם עדכון ברקע stale-while-revalidate.

תשובות API מסומנות לפי ייעוד: ספרי עזר ציבוריים חיים לפי תוקף משותף, אישיים מסומנים כפרטיים ואינם נשמרים במטמון בצמתים משותפים.

משימה נפרדת — צוואר הבקבוק של ההגשה. המקור צריך לטפל רק במה שהקצה לא יכול להגיש, ובקשות מקבילות לאותה החמצה מתמזגות לבקשה אחת לקצה האחורי. אז תוכן מיושן נראה באופן צפוי ולא יותר מחלון מוגדר, והעומס על המקור מפסיק לחזור על שיאי התעבורה.

אנו מפרקים כיצד זה נסגר בפועל: אילו מדיניות אנו תולים על קבוצות משאבים וכיצד אנו בודקים שהמטמון לא מחליף נתונים רעננים.

מה נותן מטמון מסודר: פגיעות, מהירות, יציבות

שיעור הפגיעות במטמון וזמן התגובה של הדף

מפתח מטמון ו-TTL אנו מגדירים לפי סוגי תוכן: עבור סטטיקה עם hash בשם הקובץ — ארוך, עבור HTML — קצר עם רה-ולידציה לפי ETag, עבור API — נפרד, עם התחשבות בכותרת Authorization ו-Vary.

ב-Cloudflare ובאנלוגים, סט כזה מעלה את שיעור הפגיעות במטמון ל-85–95% באתר טיפוסי, והוא זה, ולא עתודת הכוח של המקור, שקובע את זמן התגובה של הדף: התשובה ניתנת מהצומת הקרוב, ולא משרת האפליקציה.

פריקת עומס מהמקור והתנהגות תחת שיא

כל פגיעה היא בקשה שלא הגיעה למקור. במבצע או לאחר פרסום חומר, המקור מקבל סדר גודל פחות פניות, והתור עליו מפסיק להיות צוואר בקבוק. ההוראה stale-while-revalidate מוסיפה יציבות: המבקרים מקבלים עותק מהמטמון, בזמן שהעדכון מתבצע ברקע ואינו חוסם את ההגשה.

סוג הכשלים שנעלם יחד עם ההגדרה

הכלל «מקור איטי או שקרס לא צריך להפיל את הדף» מתבטא ב-stale-if-error: כאשר יש תשובת שגיאה, הלקוח מקבל את העותק התקף האחרון. הזמינות תחת שיא מפסיקה להיות תלויה בשאלה אם המקור עמד בעומס — ויחד עם ההגדרה נעלם סוג שלם של כשלים, שבדרך כלל מהווה את עיקר זמן ההשבתה.

אפשרויות קישוב: צמתי קצה, שכבה מתווכת, היברידי

הבחירה בין מטמון קצה, שכבה מתווכת וסכימה היברידית נקבעת לא לפי «מהירות», אלא לפי שיעור הדינמיקה בתעבורה, הגיאוגרפיה של הקהל ועד כמה כואבת הגשת תשובה מיושנת.

צמתי קצה כמו הרשת של Cloudflare, מעגל קישוב עצמאי לפני האפליקציה ושילוב של השניים פותרים משימות שונות — אנו משווים לפי תנאי התאמה.

הגשת סטטיקה

עבור סטטיקה, מפתח המטמון נבנה לפי שם קובץ מגורסן, ולא לפי נתיב. אז ניתן לקבוע זמן חיים ארוך ולסמן את התשובה כבלתי ניתנת לשינוי: מהדורה חדשה מביאה שמות חדשים, והאובייקטים הישנים משלימים את תוקפם ללא איפוס כפוי. הפרסום מסתכם בהעלאת קבצים לאחסון, ורשת הקצה קולטת אותם בבקשה הראשונה.

כללים לדינמיקה

כאן ההיגיון הפוך: זמן חיים קצר בתוספת איפוס לפי אירוע. HTML מוגש עם תוקף קצר ועדכון ברקע, כדי שהמבקר לא ימתין לבנייה מחדש של הדף, ותשובות אישיות או שאינן נשמרות במטמון, או מופרדות לפי סימן Authorization.

התפרצויות תעבורה נחסמות על ידי מיקרו-מטמון לכמה שניות — הוא מסיר עומס מהאפליקציה ובמקביל לא הופך את הנתונים למיושנים.

סדר העבודות: ביקורת תעבורה, כללים, בדיקה, מסירה

אנו מפרקים לא את הקונפיגורציה, אלא עובדות: כיצד התעבורה זורמת כעת, מה נשמר במטמון ומאיפה המקור מקבל עומס חוזר. בלי יומני פניות וכותרי תשובה נוכחיים, כל שינוי בכללים הוא ניחוש. לכן אנו מבצעים את העבודה בשלבים, כאשר כל צעד ניתן לבדיקה ולהפיכה.

1. ביקורת תעבורה. אנו לוקחים יומני פניות לתקופה מייצגת, מחשבים את שיעור הבקשות החוזרות והפגיעות במטמון לפי קבוצות תוכן. בנפרד אנו רושמים את מה שאסור לשמור במטמון: אזורים מאומתים, תשובות עם נתונים אישיים, סל קניות ותשלום.

2. מפת מסלולים. אנו משווים תבניות כתובות, פרמטרים של מחרוזת שאילתה וכותרים שמשפיעים על מפתח המטמון. אנו מתעדים מקומות שבהם לאותה כתובת מוגשות תשובות שונות — זה המקור העיקרי לדפים «תקועים» ולנתונים זרים במטמון.

3. כללי קישוב. אנו מגדירים TTL נפרדים: ארוכים לסטטיקה ומדיה, קצרים ל-HTML עם בדיקת עדכניות חובה, נקודתיים ל-API — רק היכן שהתשובה זהה לכולם. אנו רושמים כותרי ניהול מטמון בצד האפליקציה, ולא רק בהגדרות רשת ההפצה.

4. איפוס ופריסה. אנו מגדירים ניקוי לפי נתיבים ותגים, ומקשרים אותו לשחרור: לאחר פרסום בנייה חדשה המשתמש מקבל קבצים רעננים, ולא גרסה מהמטמון.

5. בדיקה על תעבורה חיה. אנו מפעילים כללים על חלק מהתעבורה, בודקים את שיעור הפגיעות, קודי תשובה ואי-התאמות עם המקור. חזרה לאחור — בשינוי קונפיגורציה אחד, ללא פריסת האפליקציה.

6. מסירת נהלים. אנו מוסרים תיעוד של הכללים, רשימת בדיקה לשחרור, סכימת איפוס וסט מדדים לניטור, כדי שהצוות ימשיך לשנות TTL ומסלולים באופן עצמאי.

קונפיגורציות, כללי ביטול תוקף וסכימות בפלט

ההגדרה מסתיימת לא בדוח, אלא בסט ארטיפקטים, שאיתו צוות הלקוח עובד בלעדינו. הקונפיגורציה נמצאת במאגר, ההרשאות מופרדות, והתנהגות המטמון מתוארת כך שניתן לשחזר אותה בסביבה אחרת ולבדוק בלי מחבר השינויים.

• קבצי קונפיגורציה במערכת בקרת גרסאות: כללי קישוב לפי סוגי תוכן, כותרי Cache-Control ו-Vary, ערכי s-maxage ו-stale-while-revalidate, היסטוריית שינויים וחזרה לאחור.
• כללי ביטול תוקף: איפוס לפי תגים וקידומות נתיבים לאחר שחרור, איפוס מלא — רק כפעולת חירום, סדר נפרד לסטטיקה, תשובות API ו-HTML.
• סכימת מעבר בקשה: מה מוגש מהצומת הקרוב, מה עובר למקור, באיזה שלב מתווספים כותרים וכיצד מחושב שיעור הפגיעות במטמון.
• הפרדת הרשאות לגישה לפאנל הניהול: תפקידים לפיתוח, תמיכה ואנליטיקה, איסור איפוס מלא ללא אישור, יומן פעולות לכל שינוי.
• הוראות לתמיכה: נוהל לאיפוס מטמון, בדיקת רעננות לאחר פריסה וסדר פעולות במקרה של תשובה מיושנת — עם פקודות ותוצאה צפויה.
• מפת התאמה בין סוגי תוכן ל-TTL: אילו סיומות ומסלולים משויכים לכל פרופיל — כדי שסעיף חדש באתר לא ייפול מהסכימה בעת הוספה.

מקרה בוחן: כיצד הסרנו ירידות ביצועים והפחתנו עומס מהמקור

לפני: כיוונו את המטמון «בעין»

פרויקט — חלון ראווה עם קטלוג וחשבון אישי: סטטיקה, דפי HTML ו-API מאחורי CDN אחד. כ-40% מהבקשות נכנסו למטמון, ו-TTL היה אחיד — שעה לכל דבר, כולל תשובות API עם נתונים אישיים.

בשעות שיא המקור קיבל כמעט את כל הזרימה: זמן התגובה באחוזון ה-95 הגיע ל-1.9 שניות, ולאחר כל פריסה התורן איפס ידנית את המטמון לפי עשרות נתיבים, ולפעמים שכח חלק — משתמשים ראו מחיר ישן ומלאי ישן.

מה שינינו

הפרדנו כללים לפי סוגי תוכן. סטטיקה מוגשת עם TTL ארוך וגירסה בשם הקובץ — עדכון לא דורש איפוס כלל. HTML נשמר במטמון לזמן קצר, עם הגשת עותק מיושן בזמן שהבנייה מחדש מושכת עותק רענן. תשובות API נשמרות במטמון רק היכן שהמפתח כולל את המשתמש ואת פרמטרי הבקשה, והשאר מסומן כפרטי.

במקום איפוסים ידניים — תגים על התוכן וקריאת ביטול תוקף אחת לפריסה: Cloudflare עצמו מפיץ אותה לצמתים.

אחרי

שיעור התשובות מהמטמון גדל ל-94%, הפניות למקור ירדו פי ארבעה, וזמן התגובה תחת אותו שיא — מ-1.9 ל-0.3 שניות. איפוסים ידניים הפכו לאחד-שניים בשבוע במקום מאתיים, וכמעט כולם — שלב סטנדרטי בפריסה.

ההגשה הפסיקה «לרעוד»: עותק שפג תוקפו מוגש באופן מיידי, בזמן שהרענן מגיע מהמקור, לכן המשתמש לא רואה לא מסך ריק ולא מחיר ישן לאחר עדכון הקטלוג.

במה שונה קישוב סטטיקה מ-API בהגדרת CDN?

סטטיקה ותשובות API מתיישנים בקצבים שונים: קובץ בנייה עם hash בשם אינו משתנה עד לשחרור הבא, בעוד שרשימת הזמנות מאבדת עדכניות תוך שניות. כלל אחד לכל הדומיין נותן או נתונים מיושנים בממשק, או מטמון שלא מגיש דבר.

הפרדת הכללים נעשית לא על כל הדומיין, אלא ברמת נתיבים וסוגי תוכן: לסטטיקה יש זמן חיים ארוך, ל-API — קצר עם בדיקת חובה. מפתח המטמון מתחשב בכתובת יחד עם פרמטרי הבקשה והשפה, לכן הגשה לפי מסננים ולוקאלים אינה מתערבבת, ותשובות מאומתות מוצאות בכלל נפרד.

בדיקת עדכניות מפרידה בין רעננות לבין הורדה חוזרת: הצומת מגיש תשובה 304 כל עוד התוכן לא השתנה, ואובייקט מלא — ברגע שהשתנה. כאשר זמן החיים של הרשומה קצר, הבקשה הראשונה לאחר פקיעת התוקף עוברת למקור, והשאר מקבלות עותק מוכן.

ביטול תוקף קשור לשחרור: בעת פריסה מאופסים רק נתיבים או תגים שנפגעו, ולא המטמון כולו. כך תוקף ארוך לסטטיקה וקצר ל-API חיים יחד באותה סכימה בלי תיקונים ידניים.

ספקות בהתחלה: ביטול תוקף, נתונים פרטיים, דיבוג

איפוס מטמון, אזורים פרטיים ובדיקה שהמטמון באמת עובד — שלוש שאלות שצפות כבר בשלב תכנון המדיניות, ולא אחרי ההשקה. להלן תשובות קצרות אליהן.

האם נתונים פרטיים ידלפו למטמון משותף?

אזורים פרטיים, חשבון אישי ובקשות מאומתות איננו מכניסים למטמון משותף כלל — כלל זה נקבע ברמת הקונפיגורציה, ולא במשמעת של מפתחים. ההיגיון פשוט: אם התשובה תלויה במי שביקש אותה, לצומת המטמון אין זכות לאחסן אותה. הציבורי נשאר רק מה שזהה לכולם.

כיצד לוודא שהמטמון עובד כמתוכנן?

הנראות של המטמון — זה שיעור הפגיעות בפילוח לפי סוגי תוכן: בנפרד סטטיקה, בנפרד דפים, בנפרד תשובות בקאנד. אם בתמונות ובסגנונות שיעור הפגיעות גבוה, ואילו בדפים הוא צנח לפתע, סימן שהכלל נשבר או נוסף פרמטר חדש בכתובת. מדדים אלה מוצגים בדאשבורד יחד עם נתוני שרת המקור — ניתן לראות איזה חלק מהתעבורה כלל לא מגיע אליו.

מה לעשות במקרה של תקלה: חלק מהמשתמשים רואים גרסה ישנה?

ניתוח התקלה מתחיל בהשוואה: מה הגיש צומת המטמון ומה הגיש המקור לאותה כתובת. לאחר מכן אנו בודקים באיזה צומת נשאר העותק הישן, מסירים אותו נקודתית ומתקנים את הכלל שבגללו הוא שרד את העדכון. לרוב הסיבה היא תג שנשכח או תוקף ארוך מדי לכתובת שמשתנה בכל שחרור.

נדון בסכימת הקישוב שלכם ונחזור עם הערכה

הערכה מדויקת ותוכנית עבודה נשענות על הבנה כיצד בנויה התעבורה שלכם וכיצד אתם מפרסמים תוכן. להלן מה שאנו מפרקים בשיחה הראשונה: בלי נתוני פתיחה אלה כל מדיניות קישוב יוצאת ממוצעת או שמשלמת יותר מדי על החמצות, או שמתחילה להגיש דפים מיושנים.

נדון במשימה באופן ענייני — לכל סעיף די לנו בסטטיסטיקה שלכם על הצמתים, בגישה לקונפיגורציה ובניסיון התפעול.

• פרופיל תעבורה: שיעורי סטטיקה, בקשות ל-API וסימון, שיאים יומיים, יחס בין פניות ייחודיות לחוזרות — מזה תלוי שיעור הפגיעות במטמון שניתן להשיג.
• סוגי תוכן והתיישנות מותרת: קטלוג, פיד, תשובות אישיות ומאומתות — מה ניתן להחזיק במטמון, ומה חייב ללכת למקור.
• מגבלות המקור: עתודה ברוחב פס, מגבלות על מספר פניות והתנהגות בזמן החמצת מטמון המונית לאחר איפוס.
• דרישות לאיפוס מטמון: באיזו מהירות התיקון צריך להיות גלוי, האם יש גירסה לנתיבים או תגים קבוצתיים לביטול תוקף.
• סכימת פרסום: כיצד השחרור מגיע לצמתים וכיצד זה מתיישב עם ביטול תוקף, כדי לא להגיש גרסאות מעורבות.
• הרשאות וזכויות: היכן נשמרת הקונפיגורציה, מי משנה כללים וכיצד מתועדים שינויי TTL.
• מצב תמיכה: האם נדרש ניטור של שיעור פגיעות, התראות על גידול בתעבורה למקור ונוהל לתיקוני מדיניות.

תארו את המשימה — נחזור עם הערכה ותוכנית עבודה: פריסת TTL לפי סוגי תוכן, סדר ביטול תוקף והרכב הניטור.