האצת אתר באמצעות KeyCDN: הגדרה, CI/CD ושמירה במטמון

הגדרת CDN KeyCDN: היכן האתר מאבד מהירות ומה נשבר

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

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

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

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

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

מה נותנת אספקת התוכן: השהיות, כשלים ועומס

האצת טעינת עמודים

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

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

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

הפחתת העומס על השרת

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

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

עמידות בתקלות בזמני קפיצות עומס

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

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

אפשרויות אספקת תוכן: CDN, ישירות מהשרת, היברידי

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

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

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

שלבי ההטמעה: מביקורת בקשות ועד העברה לתמיכה

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

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

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

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

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

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

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

רשימת החומרים הנמסרים: תצורות, סכימות, תקנונים

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

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

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

מקרה בוחן: קיצור זמן התגובה והשבתות בפרויקט אמיתי

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

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

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

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

במה נבדל המטמון בצד המבקר מהמטמון בשירות?

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

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

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

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

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

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

ספקות טכניים: ביטול תוקף, פרטיות, חזרות לאחור

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

מה עם נתונים פרטיים ועמודים אישיים?

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

האם קיימת תוכנית חזרה לסכימה הקודמת?

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

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

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

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

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