הגדרת Selectel CDN: היכן נשברת אספקת התוכן
עומס שיא חושף כמעט תמיד את אותו הדבר: סטטיקה — תמונות, גופנים, סקריפטים, עיצובים — מוגשת ישירות מהמקור. כל עוד התעבורה יציבה, זה לא מורגש.
ברגע שמתחיל שיא, המקור נחנק: זמן התגובה עולה, חלק מהבקשות נקטעות בגלל timeout, ולצד הסטטיקה גם עמודים דינמיים, שאינם קשורים כלל למטמון, מאטים.
פורמלית, מטמון לסטטיקה "מופעל". הבעיה בפרטים: כותרות המטמון לא הוגדרו או סותרות זו את זו, למפתח נכנסים פרמטרים של סימון שגורמים לכל כתובת להיחשב ייחודית, ותוקף הקובץ מוגדר כך שהדפדפן וצומת הביניים מפנים שאילתה למקור כמעט על כל בקשה. המטמון קיים, אך אינו עובד — המקור רואה את אותו זרם כמו בלעדיו.
בהמשך מצטרפת החלק השני — אספקת תוכן איטית בכיוונים מרוחקים, שבהם הבקשה עוברת דרך חצי עולם, והיעדר עבודה תקינה עם תעודות בקצה הרשת.
תעודה שמנפיקים מחדש באופן ידני, וכללי איפוס מטמון שנכתבו "בעין", מוסיפים קטגוריית תקלות נפרדת: לאחר ההשקה משתמשים רואים קבצים ישנים, והניקוי הופך לפעולה ידנית.
הגדרת CDN אינה תיבת סימון אחת בפאנל, אלא שילוב של החלטות: מה לשמור במטמון ולכמה זמן, כיצד נוצר המפתח, כיצד מתעדכן התוכן לאחר ריליס, וכיצד מתנהג הקצה כאשר המקור אינו זמין. להלן נפרט כיצד זה נסגר.
מה נותנת הגדרה נכונה של מטמון ותעודות
מטמון מוגדר היטב אינו "הדלקנו ושכחנו", אלא אוסף של מדדים ניתנים לבדיקה. שיעור הפגיעות במטמון על סטטיקה מגיע ל-90% ומעלה, המקור מפסיק לקבל בקשות חוזרות, וזמן התגובה של העמוד עבור המבקר מתקרב לזמן ההמתנה של הצומת הקרוב. להלן צ'ק-ליסט שלפיו אנו מאשרים את ההגדרה לפני העלאה לפרודקשן.
- שיעור הפגיעות במטמון על סטטיקה — מ-90%: נשמרים במטמון עיצובים, סקריפטים, תמונות וגופנים, ולא רק סימון העמודים.
- הקלה על השרת: פניות חוזרות נחסמות בצמתי הרשת, המקור מטפל רק בהחמצות ובדינמיקה.
- תוקף התוכן מוגדר לפי סוגים: כללים נפרדים לקבצים עם גרסאות ולעמודים עם עריכות תכופות.
- איפוס מטמון לפי דרישה: אינוולידציה לפי נתיב או מסכה מיד לאחר הפרסום, בלי להמתין לפקיעת התוקף.
- אספקה יציבה בשיא: התעבורה מתחלקת בין נקודות הנוכחות, המקור לא נכנס לתור תחת עומס.
- תעודות: הנפקה וחידוש אוטומטי בצד רשת ההפצה, שרשרת אמון תקינה, הפניה לפרוטוקול מאובטח, והיעדר אזהרות בדפדפן.
כל סעיף נבדק בבדיקת עומס לפני העברת התעבורה: בוחנים את התנהגות המקור באספקת שיא ואם נשמרת היציבות תחת עומס בעת כשל של אחד הצמתים.
את הגדרת הרשת ב-Selectel מתארים כקוד — כללי מטמון, כותרות, תעודות ודומיינים משוחזרים בפקודה אחת, ולא נבנים ידנית בפאנל, ולכן סביבת הבדיקה והפרודקשן אינן נפרדות זו מזו.
Selectel CDN: השוואת מצבי מטמון
את מצב המטמון בוחרים לפני הפעלת ההפצה: ממנו תלוי מה בכלל יגיע לצמתי הקצה ומה ימשיך לעבור לשרת המקור. טעות לכיוון "לשמור הכל במטמון" שוברת התאמה אישית וסל קניות, וטעות בכיוון ההפוך משאירה את שרת המקור תחת עומס מלא בתעבורת מדיה.
כללי המטמון מוגדרים לפי נתיבים, סיומות וכותרות בקשה: סטטיקה חיה בקצה, סימון ותשובות API עוברים על פניו. תעודה עצמאית אינה מתנגשת עם ה-CDN — השרשרת נבדקת בצד הלקוח, ובתחום נשארת הצמדה למפתח מעודכן.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| מטמון על כל התחום | חלונות ראווה, קטלוגים ועמודי פרומו ללא התאמה אישית | נדרשות כתובות עם גרסאות והפרדה לפי cookie, אחרת המשתמש יראה סל קניות של אחר |
| מטמון קצה לסטטיקה בלבד | חנויות, אזורים אישיים, שירותים עם API | סימון ותשובות API אינם נשמרים במטמון — הרווח רק במדיה ובסקריפטים |
| מטמון עם הפרדה לפי מפתח | גרסאות גיאוגרפיות, בלוקים אישיים, מדורים לפי מטבע | גדל מספר ההעתקות של האובייקט, ויורד שיעור הפגיעות בהבדלים קטנים |
| ללא מטמון, הפצת קצה בלבד | אזורים אישיים, טפסי תשלום, דוחות | העומס על שרת המקור אינו יורד, הרווח רק בניתוב |
המצב הנבחר מתועד בכללי המטמון ומקבל גרסה יחד עם התצורה — ואז האיפוס לאחר ריליס נשאר צפוי ולא פעולה ידנית.
סדר ההטמעה: מהאודיט ועד המסירה
סדר העבודות בנוי כך שהמטמון והתעודות ייבדקו על תחום בדיקה ולא על תעבורת הפרודקשן. כל שלב מסתיים בארטיפקט — תרשים, תצורה או דוח בדיקה.
- אודיט תצורה. מפרקים את מקורות התוכן, כללי המטמון, זמני האחסון של אובייקטים בפריפריה, כותרות התגובה ושרשרת התעודות. מאתרים מה מוגש על פני הרשת ואילו סוגי קבצים נשמרים במטמון באופן שגוי.
- תרשים הפצת התוכן. קובעים אילו דומיינים ואזורים עוברים דרך הרשת, היכן נשאר מקור ישיר, וכיצד מופרדים סטטיקה ודינמיקה. התרשים מתעד את הצירוף דומיין — אזור — מקור.
- הגדרת כללים. רושמים מטמון לפי סוגי אובייקטים, פרמטרים לעקיפת מטמון, דחיסה, כותרות אבטחה ותעודות לכל השמות. התצורה מתוארת כקוד ועוברת בדיקה לפני יישום.
- בדיקת מטמון. מריצים את תחום הבדיקה: שיעור הפגיעות במטמון, תקינות העקיפה לבקשות מורשות, עדכון קבצים בעת החלפת גרסה. מוודאים שסטטיקה ישנה אינה נתקעת בפריפריה.
- תוכנית חזרה לאחור. מכינים חזרה למקור ישיר: שומרים את רשומות התחום הקודמות, תוקפן וסדר החזרת התעודות. החזרה נמשכת דקות ואינה דורשת בנייה מחדש של התצורה.
- העברת תעבורה. מעבירים את הרשומות לרשת, החל ממקטע אחד, ועוקבים אחרי שיעור השגיאות וזמן התגובה. בסטייה במדדים חוזרים לפי תוכנית החזרה לאחור.
- מסירה. מוסרים את התצורה, התרשים, מדיניות המטמון והוראות לתיקונים אופייניים, וכן את ספי המדדים שבהם יש להתערב.
תיעוד ותצורות שנשארים אצלכם
את כל מה שאנו מגדירים מוסרים לא בהתכתבות במסנג'ר, אלא בארטיפקטים עובדים במאגר שלכם: תצורת Selectel CDN, תרשים ותקנונים שלפיהם הצוות יוכל לשנות את ההפצה בלעדינו. הערכה נבנית כך שמהנדס חדש יבין את התרשים בערב אחד, ולא ישחזר את ההיגיון מהיסטוריית העריכות.
- תרשים התשתית: דומיינים, מקורות, אזורי הפצה, סטטוסים וקשרים ביניהם — הדיאגרמה נמצאת לצד הקוד.
- מדיניות מטמון לפי סוגי תוכן: תוקף אובייקטים, מפתחות מטמון, כללי עקיפה לדינמיקה, התנהגות בעת אי-זמינות המקור.
- תיאורי משאבים, תעודות והפניות כקוד — הסביבה נפרסת מאפס באופן חוזר, ללא עריכות ידניות בפאנל.
- כללי גישה ותפקידים: מי ומה רשאי לשנות, היכן נשמרים המפתחות וכיצד מתבצעת הרוטציה שלהם.
- תקנון עדכון: סדר העריכות, בדיקה על תחום בדיקה, קריטריוני קבלה, תוכנית חזרה לגרסת תצורה קודמת.
- הוראות לצוות: הנפקת תעודה, החלפת מקור, קריאת סטטיסטיקה, איתור סיבת שגיאות ההפצה.
- יומן החלטות — מדוע נבחרו זמני תוקף וכללי אינוולידציה שכאלה: בעוד חצי שנה לא יהיה צורך לנחש את ההיגיון מהיסטוריית השינויים.
ערכה כזו מסירה את הסיכון המרכזי: התצורה מפסיקה להיות הידע של אדם אחד והופכת לחלק מהתשתית שלכם.
מקרה בוחן: כיצד צומצם העומס על המקור פי כמה
נקודת הפתיחה
קטלוג עם תוכן מדיה כבד: תמונות ווידאו הוגשו ישירות משרתי האפליקציה. כל מעבר בין מדורים יצר בקשה למקור, ובשעות השיא השרת נכנס לתור — חלק מהפניות הסתיימו ב-timeout. מטמון מקומי בצד האפליקציה לא עזר: אותם קבצים נבנו מחדש בכל אינסטנס, והפגיעות כמעט לא היו.
מה שינו
את הסטטיקה והמדיה הוציאו ל-Selectel CDN והפרידו את כללי המטמון לפי סוגי תוכן: קבצים עם גרסאות קיבלו תוקף ארוך, עמודי הקטלוג — תוקף קצר, כדי שעריכות יגיעו למשתמשים במהירות.
את מפתח המטמון הרחיבו רק בפרמטרים שמשפיעים באמת על התוצאה — אחרת ה-CDN מתחיל להגיש גרסה של עמוד belonging למשתמש אחר. את המקור סגרו מפני פניות ישירות, ואת איפוס המטמון קשרו לפרסום הריליס, כדי לא לנקות אותו ידנית.
התוצאה
שיעור הפגיעות במטמון עלה משליש מהבקשות לתשע מתוך עשר — המקור הפסיק להיות צוואר הבקבוק. העומס על שרתי האפליקציה ירד פי חמישה לערך, זמן התגובה של הקטלוג הצטמצם פי ארבעה והפסיק להיות תלוי במספר המשתמשים הפעילים.
נעלמה קטגוריית תקלות נפרדת: timeouts במדיה ושגיאות הפצה בעת זינוק חד בתעבורה. איפוס המטמון לאחר ריליס אינו גורם עוד לזינוק בבקשות למקור — החימום מתבצע בהדרגה, וההשקה אינה מפילה את השירות.
במה נבדל מטמון בקצה ממטמון בדפדפן?
מטמון הדפדפן חי במכשיר המבקר: לאחר קבלת התגובה, הדפדפן שומר את האובייקט ובפנייה הבאה אינו פונה כלל לרשת. מטמון קצה הוא שכבה על צמתי הספק, שמגישה את אותה תגובה למאות מבקרים עוד לפני השרת שלכם. אלה שני מאגרים בלתי תלויים עם כללי איפוס שונים.
שני הרבדים מנוהלים באותן כותרות מטמון — ושם מקור הבלבול העיקרי. הוראה שהוגדרה לדפדפן יורשת כברירת מחדל על ידי שכבת הקצה: או שכל מבקר ממתין מחדש לטעינה הראשונה, או שעמוד מיושן נתקע בצמתים ואינו מתאפס לפי דרישה.
מפרידים בין הרבדים באמצעות דירקטיבות כמו s-maxage ו-private, וכן בכותרת Vary — היא מתארת אילו הבדלים בבקשה הופכים את התגובה לייחודית.
תוקף המטמון לשני הרבדים מוגדר באופן שונה. סטטיקה עם hash בשם הקובץ נשמרת במטמון לזמן ארוך בכל מקום, ואילו תגובות HTML מקבלות בדרך כלל תוקף קצר בקצה ואפסי בדפדפן, כדי שעריכת התוכן תיראה כבר ברענון הראשון של העמוד.
מכאן גם שיטת ההגדרות: תחילה מסמנים תגובות זהות לכולם, אחר כך קובעים להן תוקף בקצה וכלל איפוס לפי מפתח, ואת הנתונים האישיים סוגרים מפני המטמון המשותף.
ב-Selectel CDN האיפוס פועל בקצה, אך מטמון הדפדפן אצל מבקרים שכבר טענו אינו ניתן לאיפוס: נותר להמתין לפקיעת התוקף או לשנות את שם הקובץ בעת ההשקה.
ספקות טכניים לפני תחילת העבודות
ספקות לפני ההתחלה הם בדרך כלל לא בשאלה "האם הפצת התוכן עובדת", אלא בתפעול: מה יקרה למטמון מיושן, כיצד תעבור החלפת ה-DNS, האם הפלטפורמה תקבל את התעודה שלנו וכיצד לוודא שהכל הוגדר נכון. להלן ארבע שאלות שנשאלות בתדירות הגבוהה ביותר.
המשתמשים יראו מטמון מיושן לאחר ריליס?
המטמון מנוהל בשני רבדים: תוקף האובייקט בצד פלטפורמת Selectel וכללי הניקוי. סטטיקה עם hash בשם הקובץ ניתן להחזיק זמן רב — תוכנה אינו משתנה.
לעמודים ולתשובות API קובעים תוקף קצר ומוסיפים איפוס לפי תג בעת הדיפלוי: הבנייה מפרסמת סט חדש של קבצים ומבטלת רק נתיבים שהשתנו, ולא את כל המטמון כולו. כך הריליס נראה מיד, והאובייקטים החמים נשארים במטמון ואינם נבנים מחדש מאפס.
החלפת התחום תעבור ללא השבתה?
הסדר הוא כזה: תחילה יוצרים את ההפצה ומצמידים את התחום, בודקים תגובות בכתובת זמנית, לאחר מכן מחליפים את רשומות ה-DNS ורק אחר כך מכבים את המקור הישן. את תוקף הרשומות מקצרים מראש, כדי שההחלפה תתפשט ברזולברים תוך דקות ולא תוך יממה. חזרה לאחור היא החזרת הרשומות הקודמות, היא נמשכת אותו זמן ואינה דורשת הגדרה מחדש של ההפצה.
אפשר לחבר תעודה עצמאית ולא תעודה של הפלטפורמה?
כן, וזה מקרה נפוץ שבו התעודה כבר הונפקה על ידי מרכז תעודות ארגוני או מכסה כמה דומיינים בבת אחת. מעלים את השרשרת כולה יחד עם תעודות הביניים — אם מדלגים על חוליית הביניים, הדפדפנים יציגו אזהרה, למרות שהבדיקה בצד השרת תעבור. בהמשך מגדירים חידוש אוטומטי ומוודאים שהתעודה החדשה נכנסת להפצה לפני פקיעת הנוכחית.
יש לנו כבר הפצה פרוסה — יהיה צורך לבנות אותה מחדש?
לא. מתחילים במיפוי: מצלמים את כללי המטמון הנוכחיים, הכותרות, הצמדות הדומיינים והגדרות התעודות, ואחר כך מעבירים אותם לתיאור תצורה. בדיקת ההגדרות נעשית לפי רשימת בקרה — קודי תגובה, תקינות כותרות המטמון, פגיעות והחמצות במטמון, התנהגות בעת מקור שאינו זמין. את הסטיות רואים לפני העברת התעבורה, ולא אחריה.
נדון במשימה שלכם ונחזור עם תוכנית
כדי שהערכת העבודה תישען על עובדות ולא על הנחות, די לתיאור המשימה בצורה חופשית: מה אתם מפיצים, מאיפה, ואיזה עומס אתם מצפים לו. את הפרטים נבהיר בעצמנו, אך כמה נתוני פתיחה חוסכים סבב התכתבות שלם ואיטרציה אחת של הערכה.
- דומיינים ואזורים שיעברו דרך ה-CDN, והיכן נמצא כעת ה-DNS.
- מקורות התוכן: שרתים, אחסון אובייקטים או שירותים חיצוניים שמהם ה-CDN שולף נתונים.
- מה נשמר במטמון ומה חייב לעבור על פניו: סטטיקה, תמונות, וידאו, API, בקשות עם הרשאה.
- דרישות לתעודות: עצמאיות או שהונפקו על ידי הספק, והאם נדרשת תעודה משותפת לתת-דומיינים.
- הרשאות: חשבון ענן ומשתמש שירות נפרד עם הרשאות ל-CDN ול-DNS בלבד, ולא מפתח מאסטר.
- תקנון שינויים: חלונות שבהם מותר להעביר תעבורה, וזמן אי-זמינות נסבל.
בתגובה נשלח תוכנית הטמעה עם סדר העבודות: שלבים, מה בדיוק משתנה בכל אחד, נקודות חזרה לאחור ומי נדרש מצד המזמין. בבלוק נפרד — תיאור תצורה ל-Terraform וכללי מטמון, כדי שניתן יהיה לבנות את התצורה מחדש ולמסור אותה לצוות שלכם.
אם חלק מהנתונים עדיין אינו ידוע — זו אינה סיבה לדחות. תארו את המשימה כפי שהיא, נבנה את ההערכה ונחזור עם תוכנית ושאלות לגופן של הדברים.