דמיינו את המצב: שרת המקור שלכם חווה קפיצה בעומס המעבד, שאילתת מסד נתונים נתקעת, או שחברת האחסון שלכם חווה תקלה קצרה. בדרך כלל זה אומר שהמבקרים שלכם יראו גלגל טעינה מסתובב או שגיאת timeout. אבל אם אתם משתמשים ב-CDN עם יכולת failover, רוב המבקרים כלל לא ישימו לב לכלום. זו הקסם השקט של CDN failover, וזו אחת הסיבות הכי לא מוערכות להציב CDN לשיפור מהירות מול שרת המקור שלכם מלכתחילה.
בואו נפרק את זה: איך זה באמת עובד, למה זה חשוב יותר ממה שאנשים חושבים, ואיך להגדיר את זה בלי להסתבך יותר מדי.
מה זה באמת CDN Failover
רשת תוכן (CDN) יושבת בין המבקרים שלכם לשרת המקור. בדרך כלל, היא מביאה תוכן עדכני מהמקור, שומרת אותו בזיכרון מטמון בנקודות קצה (edge) ברחבי העולם, ומגישה עותקים שמורים למבקרים הקרובים. זה בלבד הופך CDN לשיפור מהירות למהלך חכם, כי זה מקצר את המרחק הפיזי שהמידע צריך לעבור.
failover הוא מה שקורה כששרת המקור שלכם לא מצליח להגיב, בין אם זו שגיאת timeout, שגיאת 500, או שהשרת פשוט נפל לגמרי. במקום להעביר את התקלה הזו ישירות למבקר, CDN עם לוגיקת failover יכול:
- להגיש גרסה שמורה של הדף, גם אם היא קצת לא מעודכנת
- לנסות שוב את הבקשה מול שרת מקור גיבוי, אם הגדרתם כזה
- להגיש תגובת "stale while revalidating" מותאמת אישית שעדיין מציגה דף שמיש
- לנתב תעבורה למרכז נתונים משני לגמרי, בהגדרות עם כמה שרתי מקור
התוצאה היא שהאתר שלכם נשאר פעיל, או לפחות פונקציונלי, בדיוק ברגע שבו התשתית שלכם סובלת הכי הרבה.
למה זה חשוב יותר ממה שחושבים
תקלות בשרת המקור הן לרוב לא דרמטיות. לרוב מדובר בתקלות קצרות: נעילה של 30 שניות במסד נתונים, deployment שהשתבש קצת, קפיצת תעבורה שמציפה את עובדי ה-PHP-FPM. הרגעים האלה קצרים, אבל גם בלתי צפויים, מה שהופך אותם לקשים לתכנון ידני.
בלי failover, כל אחת מהתקלות הקטנות האלה הופכת לגלויה למבקרים אמיתיים. איתו, ה-CDN סופג את הזעזוע. מחקרים על נטישת דפים מראים שוב ושוב שגם עיכוב של 2-3 שניות מעלה משמעותית את שיעור הנטישה, ודף שגיאה גמור הרבה יותר גרוע מעיכוב. failover זה לא עניין של מהירות במובן המסורתי, זה עניין של לוודא שהמהירות אף פעם לא יורדת לאפס.
Stale-While-Revalidate: הסוס העובד מאחורי Failover
רוב רשתות ה-CDN המודרניות תומכות בהנחיית caching שנקראת stale-while-revalidate, ואחת קשורה שנקראת stale-if-error. הנה איך נראית כותרת cache-control טיפוסית:
Cache-Control: max-age=300, stale-while-revalidate=60, stale-if-error=86400
זה אומר ל-CDN: הגש את העותק השמור למשך 5 דקות כרגיל, המשך להגיש עותק קצת לא מעודכן למשך עד 60 שניות בזמן שאתה מביא עותק עדכני ברקע, ואם שרת המקור נפל לגמרי, המשך להגיש את העותק השמור הזה למשך עד 24 שעות במקום להציג שגיאה. החלק האחרון הזה הוא פוליסת הביטוח של ה-failover. זה ההבדל בין "האתר שלי נראה קצת לא מעודכן לרגע" לבין "האתר שלי לגמרי לא נגיש".
Failover עם כמה שרתי מקור להגדרות גדולות יותר
caching עם stale מטפל טוב בתקלות קצרות, אבל מה לגבי תקלות ארוכות יותר, כמו שרת שצריך הפעלה מחדש או deployment כושל שלוקח 20 דקות לבטל? כאן נכנס לתמונה failover עם כמה שרתי מקור.
בהגדרה כזו, אתם מגדירים ב-CDN שרת מקור ראשי ושרת גיבוי אחד או יותר. אם השרת הראשי נכשל בבדיקת תקינות (בדרך כלל פינג HTTP פשוט כל כמה שניות), ה-CDN מעביר אוטומטית בקשות חדשות לשרת הגיבוי. דפוסים נפוצים כוללים:
- שרת רפליקה לקריאה בלבד שיכול להגיש תוכן סטטי או שנשמר לאחרונה
- VPS משני במרכז נתונים אחר לגיבוי מלא
- אתר סטטי של "מצב תחזוקה" שמשאיר מידע בסיסי זמין
זה מורכב יותר להגדיר מאשר failover פשוט מבוסס caching, אבל עבור חנויות אונליין או אתרים עם תעבורה גבוהה, שווה את המאמץ הנוסף. כמה דקות של downtime במהלך מבצע יכולות לעלות יותר מכמה חודשים של דמי אחסון.
איך להגדיר בדיקות תקינות נכון
failover עובד רק אם ה-CDN באמת יודע ששרת המקור שלכם לא תקין. זה אומר להגדיר בדיקות תקינות כראוי:
- בדקו נקודת קצה קלה, לא את דף הבית המלא שלכם, כך שהבדיקה עצמה לא תוסיף עומס
- קבעו סף כשלים סביר, למשל 3 בדיקות כושלות ברצף, כדי שתקלה בודדת לא תפעיל failover מיותר
- עקבו גם אחרי קודי סטטוס HTTP וגם אחרי זמן תגובה, כי שרת שמחזיר 200 OK אבל לוקח 15 שניות עדיין נכשל מול המשתמשים שלכם
אם אתם רוצים לראות את זה מנקודת המבט של המשתמש, כלי ניטור סינתטי שבודקים את האתר שלכם מכמה אזורים נותנים תמונה ברורה יותר של מה שמבקרים אמיתיים חווים, לא רק מה שלוגי השרת שלכם אומרים פנימית.
מה הגדרת CDN Failover לא פותרת
כדאי להיות כנים לגבי המגבלות כאן. CDN failover מגן על הגשת התוכן, אבל הוא לא פותר את הבעיה הבסיסית. אם מסד הנתונים שלכם הוא צוואר הבקבוק, failover קונה לכם זמן, הוא לא פותר שאילתות איטיות. אם השרת שלכם חלש מדי ביחס לתעבורה שלכם, תמשיכו להפעיל אירועי failover עד שתטפלו בשורש הבעיה.
תחשבו על failover כעל רשת ביטחון, לא כעל פתרון קבוע. זה אמור לקנות לצוות שלכם זמן לחקור ולפתור את הבעיה האמיתית בלי שהמבקרים ירגישו את ההשפעה בינתיים.
לסיכום
CDN לשיפור מהירות עושה עבודה כפולה: הוא מהיר את האתר שלכם בתנאים רגילים ושומר אותו זמין כשדברים משתבשים. השילוב של caching בקצה הרשת, הנחיות stale-while-revalidate, ו-failover עם כמה שרתי מקור אומר שהמבקרים שלכם כמעט ולא חווים את הימים הרעים שהשרת שלכם לפעמים חווה.
כתבנו בעבר על איך CDN משנה את הגאוגרפיה של הביצועים של האתר שלכם ועל איך להגדיר כללי caching ב-CDN כך שתוכן דינמי יישאר עדכני, ששניהם משתלבים היטב עם תכנון failover. אם אתם גם מנסים להבין איזו פריסת רשת מתאימה לקהל שלכם, המאמר שלנו על בחירת רשת edge של CDN שבאמת מכסה את הקהל שלכם הוא קריאה טובה להמשך.
בצד האחסון, שרת שמנוטר כראוי תופס את הקשיים האלה בשרת המקור מוקדם, לרוב עוד לפני שה-CDN failover בכלל צריך להיכנס לפעולה. שילוב של ניטור זמינות איכותי יחד עם יתירות ברמת ה-CDN נותן לכם שתי שכבות הגנה במקום להסתמך על אחת בלבד.
המסקנה
אל תחכו לתקלה כדי לגלות שה-CDN שלכם לא מוגדר ל-failover. בדקו את כותרות cache-control שלכם היום, ודאו שהגדרות stale-if-error במקום, ואם התעבורה שלכם מצדיקה זאת, שקלו להגדיר שרת מקור משני. כמה שעות של הגדרה עכשיו יכולות לחסוך לכם תקלה מביכה ומפסידת הכנסות בהמשך.
