למה הגדרת CDN לאפליקציה ניידת נשברת בשיאי עומס
הגדרת CDN לאפליקציה ניידת נראית עובדת בדיוק עד השיא הראשון: בתעבורה יציבה צמתי הקצה משרתים את הבקשות, זמן התגובה יציב, ושרת המקור כמעט לא עמוס.
אבל די בעלייה במספר הסשנים במקביל — שעת שיא בערב, מבצע מכירות, דיוור עם תמונות — וזמני הטעינה לא גדלים בהדרגה אלא קורסים: הפיד מפסיק להיטען, ומסכים נפתחים ריקים.
הכשל הראשון — מטמון. כאשר כללי המטמון מוגדרים בשורה כללית אחת, ולא מופרדים לפי קבוצות אובייקטים (תמונות קטלוג, עטיפות, סטטיקה של הממשק, נתוני פרופיל), צמתי הקצה מחשיבים חלק מהתגובות כלא ניתנות לבדיקה ופונים עבורן לשרת המקור בכל פתיחת מסך. עומס השיא עובר למקור, והוא מתחיל להגיב לאט יותר מאשר היה מגיב ללא הפצה כלל.
הכשל השני — הרשת הניידת. המשתמש יורד לרכבת התחתית, עובר בין רשתות, מאבד קליטה באמצע ההורדה: בקשה שנקטעה חוזרת על עצמה בשלמותה, ולא ממשיכה מהמקום שבו נפסקה. כל מקרה כזה — תעבורה מיותרת, פנייה מיותרת למקור ועוד צעד לקראת אותם עיכובי טעינה שהאדם מנסח כ"האפליקציה איטית".
הכשל השלישי — האובייקטים עצמם. תמונות כבדות ללא התאמה למסך, מסירת אותו קובץ בכל הרזולוציות, היעדר דחיסה ואיחוד בקשות קטנות מנפחים את נפח ההעברה פי כמה. צמתי הקצה מקצרים את המרחק למשתמש, אבל לא מצילים מכך ששולחים לו תוכן מיותר.
בכל שלושת התרחישים נקודות הכשל זהות: כללי מטמון, טיפול בקטיעות והכנת תוכן. נסביר כיצד זה נסגר.
מה CDN נותן לאפליקציה: מהירות, יציבות, כיסוי
ההיגיון של CDN פשוט: סטטיקה — תמונות, גופנים, רכיבי ממשק, וידאו, חבילות JS — נמסרת לא משרת המקור, אלא מנקודת הנוכחות הקרובה ביותר למשתמש. הבקשה הראשונה מושכת את האובייקט מה־origin, לאחר מכן הוא חי במטמון עם זמן חיים מוגדר ונמסר כבר מהאזור של המשתמש.
ההבדל במהירות התגובה בנתיבים מרוחקים הוא פי כמה, ולא "קצת יותר מהיר", מפני שמרכיב העיכוב העיקרי נעלם: מסלול החבילה דרך חצי העולם.
מטמון לסטטיקה מוגדר לפי סוגי תוכן, ולא "להפעיל ולשכוח". תמונות וגופנים נשמרים במטמון לזמן ארוך, HTML ונתוני פרופיל — לזמן קצר או לא נשמרים במטמון כלל, ותשובות API מקבלות כללים נפרדים.
בנפרד מוגדר ביטול תוקף: בעת שחרור גרסה, גרסאות חדשות של נכסים מקבלות כתובת חדשה, ולא מאפסות את המטמון כולו בכל האזורים. אחרת אחרי כל עדכון האפליקציה עובדת כשעתיים במצב מעורב — חלק מהמשתמשים מקבלים ממשק ישן, וחלק חדש.
יציבות בשיאים — האפקט המדיד השני. דיוור המוני, פתיחת הרשמה, שידור חי או מבצע עונתי יוצרים פרץ בקשות ששרת המקור לא מחזיק.
צמתי הקצה מקבלים אותו על עצמם: שיעור הבקשות שמגיעות נשאר ברמה של יום רגיל, אין כשלים בגלל timeout, ול־origin מגיע רק החלק שאינו נשמר במטמון — בדרך כלל אחוזים מהנפח הכולל. פריקת השרת מפחיתה ישירות את הדרישות למשאבים שלו ואת ההוצאות על תעבורה יוצאת, שמצטמצמת פי כמה.
אנחנו עובדים עם Cloudflare ורשתות הפצה נוספות: בחירת הספק נקבעת לפי הגיאוגרפיה של הקהל, שיעור הווידאו והדרישות להגנה. לאחר מכן — כללי מטמון, כותרות לניהול מטמון, מקור גיבוי וניטור שיעור הפגיעות. בלי זה CDN רק מעביר את העומס, ולא מסיר אותו.
סכמות הפצת תוכן ומתי כל אחת מהן מתאימה
בחירת סכמת ההפצה קובעת לא "מהירות בכלל", אלא אילו בקשות אפשר למסור בלי להגיע לשרת המקור. תוכן דינמי — פיד אישי, אימות, תשובות תשלום — אסור לשמור במטמון: טעות במפתח מוסרת למשתמש נתונים של אחרים.
סטטיקה ומדיה נשמרות במטמון לפי שם קובץ עם גרסה, ודווקא בהן הסכמה נותנת את הרווח העיקרי בזמן התגובה ובעומס.
| סכמת הפצה | מתי מתאימה | מגבלות |
|---|---|---|
| רשת חיצונית מוכנה | קהל בעשרות אזורים, רוב התוכן סטטיקה ומדיה, אין כוונה להחזיק תשתית משלנו | כללי המטמון מוגדרים בפאנל של המפעיל; חלק מההגדרות לפי אזורים ומהירות ביטול התוקף תלויים בנוהל שלו |
| צמתים משלנו | דרישה להחזיק נתונים בסביבה שלנו, כיסוי של אזור או שניים | הרחבת גיאוגרפיה — עבודה ידנית; תפעול וגיבוי נופלים על הצוות |
| סכמה היברידית | סטטיקה ומדיה בצמתים חיצוניים, תעבורה דינמית ופרטית — דרך שלנו | ניתוב מורכב יותר: צריך לסנכרן קונפיגורציות וכללים בשתי סביבות |
| הפצה ישירה מהמקור | קהל קטן, כמעט כל התעבורה — בקשות קצרות לנתונים | עיכובים ועומס גדלים באופן ליניארי עם מספר המשתמשים, היציבות כולה על המקור |
הסכמה עצמה עובדת רק יחד עם כללי המטמון: מפתח לפי גרסת המשאב, זמן חיים קצר לתוכן שמשתנה לעיתים קרובות, וביטול תוקף כפוי לאחר שחרור הלקוח. בלי זה אפילו סכמה שנבחרה נכון מוסרת קבצים מיושנים — והמשתמש רואה מסך ישן לאחר עדכון האפליקציה.
שלבי היישום: מביקורת ועד מסירת נהלים
סדר העבודה כמעט אינו תלוי בגודל האפליקציה — משתנה רק העומק של כל שלב. מתחילים במדידות: כל עוד אין מספרים על ההפצה הנוכחית, כל שינוי הופך להימור עיוור.
- ביקורת הפצה. בודקים מה ומאיפה השרתים מוסרים: הרכב התוכן, שיעור בקשות חוזרות מאותו משתמש, הגיאוגרפיה של הקהל, זמן התגובה בבקשה הראשונה ובמטמון שכבר התחמם. מחשבים איזה חלק מהתעבורה בכלל כפוף למטמון.
- סכמת מסלולים. מפרידים את הזרימות: בקשות לנתוני משתמש הולכות ישירות, סטטיקה, תמונות ותוכן מתעדכן — דרך צמתי ההפצה. בנפרד מתארים את הפצת העדכונים, כדי שהעלאה של גרסה חדשה לא תכה בשרתים.
- הגדרת מטמון. לכל סוג תוכן קובעים זמן חיים ומדיניות עדכון משלו: קבצים משתנים נבדקים לפני מסירה, קבצים קבועים נשמרים זמן רב. מפתח המטמון מנורמל כדי שעותקים של אותו קובץ לא יתרבו.
- בדיקה בעומס. מריצים את הסכמה על פרופיל תעבורה אמיתי — פרצי שיא, ערוצים איטיים, התקנה ראשונה של האפליקציה. מתעדים את שיעור הפגיעות במטמון, זמן התגובה והתנהגות המערכת בכשל של צומת בודד.
- הרצה על תעבורה חיה. מפעילים בהדרגה, על חלק מהקהל, ומשווים מדדים לפני ואחרי. כך טעות בכללים עולה שניות של ירידה בביצועים, ולא שעה.
- מסירת נהלים. מוסרים מפת מסלולים, כללי מטמון לפי סוגי תוכן, סדר איפוס המטמון בעת שחרור, דשבורד עם מדדים והוראות לתורן.
סכמות, כללי מטמון ותיעוד בתוצרים
לאחר ההפעלה נשאר לצוות הלקוח לא רק שירות הפצה עובד, אלא גם סט מלא של תוצרים, שלפיהם אפשר לפתח את הסביבה בלעדינו. קונפיגורציות אנחנו מוסרים לריפוזיטורי, ולא "במילים": שינוי עובר בדיקת קוד, ניתן לחזור ממנו ברוויזיה אחת, וסביבות ההכנה והתפעול לא מתפצלות זו מזו.
- סכמת ניתוב — אילו דומיינים משרתים סטטיקה, מדיה ובקשות של האפליקציה, כיצד התעבורה מתחלקת בין המקורות ובאיזה סדר מתבצעת מעבר אם אחד מהם נכשל.
- כללי מטמון — זמן חיים לכל סוג תוכן, גרסאות של קבצים באמצעות hash בשם ורשימה של מה שלא נשמר במטמון: תשובות אישיות ובקשות אימות.
- מדיניות גישה — קישורים חתומים עם תוקף מוגבל, הגנה מפני הטמעת תוכן באתרים חיצוניים, הגבלות לפי אזורים ותדירות פניות למקורות.
- נוהל פרסום תוכן — סדר פרסום הגרסה, חימום מטמון לפני פתיחת התעבורה, מי מאשר את ההעלאה וכיצד מוחזרת הגרסה הקודמת.
- קונפיגורציה כקוד — מסלולים וכללים בריפוזיטורי, פרוסים ב־Cloudflare: שינויים עוברים בדיקה ולא מתפצלים בין סביבות.
- מדדים והתראות — שיעור הפניות מהמטמון, זמן מסירה לפי אזורים, פרצי שגיאות וספים שאחריהם התורן מקבל התראה.
- הוראות תפעול — מפת דומיינים וצמתים, רמות הרשאה, אחראים וסדר פעולות בעבודות מתוכננות.
מקרה בוחן: קיצרנו את זמן טעינת הקטלוג פי שלושה
הלקוח — רשת חנויות למוצרי בית «סבני דום»: קטלוג של 40 אלף פריטים, אפליקציות ל־iOS ול־Android. כרטיס מוצר משך מהסביבה הראשית גם נתונים וגם כל תמונה, ולכן בזרימה חדה של משתמשים זמן התגובה עלה ל־5–6 שניות, וכל טעינה חמישית נקטעה. שרת המקור נתקע בתקרה ומסר תמונות לאט יותר מאשר הספיקו לבקש אותן.
מה עשינו במסגרת מקרה הבוחן של היישום
הפרדנו את התעבורה: סטטיקה — תמונות כרטיסים, באנרים, סקירות וידאו — הועברה ל־CDN, ובאמצעות שרת המקור נשארו הדינמיקה והנתונים האישיים. הגדרנו כללי מטמון לפי סוגי אובייקטים, גרסאות של קישורים לתמונות וטעינה ברקע של תצוגות מקדימות, כדי שהקטלוג ייפתח ממטמון שכבר התחמם. את ההפצה קישרנו לניתוב גיאוגרפי: המשתמש מקבל תוכן מנקודת הנוכחות הקרובה ביותר של הרשת.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן תגובה בשיא | 5–6 שניות | 1.7 שניות |
| שיעור טעינות שנקטעו | 19% | 6% |
| עומס על שרת המקור | 100% | 25–30% |
בזרימה של פי עשרה של משתמשים בדקה הראשונה של המבצע, הקטלוג נפתח בלי ירידה בביצועים: רשת ההפצה מקבלת את הבקשות על עצמה, ואין צורך להרחיב את שרת המקור תחת עומס השיא.
במה שונה מטמון סטטיקה מהפצת סטרימינג
סטטיקה וסטרים — שני חוזים שונים בין האפליקציה לשרת הקצה. סטטיקה זהה לכולם: מעטפת האפליקציה, תמונות, גופנים, סקריפטים.
מחזיקים אותה בקצה עם זמן חיים ארוך ומאפסים לא לפי טיימר, אלא לפי שינוי שם קובץ — בעת שחרור גרסה חדשה, עותקים חדשים נמשכים מיד, והישנים מסיימים את תוקפם בלי שגיאות אצל המשתמשים.
נתונים אישיים בנויים הפוך: התשובה ייחודית למשתמש מסוים, ומטמון משותף על תשובה כזו הופך לדליפה בין חשבונות.
לכן בקשות פרטיות עוברות מחוץ למטמון או עם מפתח לפי משתמש, והגישה לקבצים ניתנת באמצעות קישורים חתומים עם תוקף קצר — קישור שדלף מהלוגים או הועבר הלאה מפסיק לעבוד לפני שהספיקו להשתמש בו.
סטרים לא נשמר במטמון כולו: ההקלטה מחולקת למקטעים קצרים שנאספים במכשיר, ובקצה משתלם להחזיק רק מקטעים חמים של הקלטות פופולריות. זה מסיר עומס מהאחסון הראשי, אך דורש הגדרה קפדנית של הגנת תוכן, כדי שמקטעים לא יורדו בעקיפין לאפליקציה. אסור לערבב מצבים בכלל אחד — דווקא על זה נשברת ההפצה.
ספקות טכניים נפוצים לפני תחילת העבודה
לפני תחילת הגדרת CDN עולות אותן שאלות: מה לעשות עם סכמת הפצה שכבר פרוסה, האם נדרשים תיקונים באפליקציה ומי אחראי לתקלות לאחר המסירה. נבחן אותן לגופן — מהתשובות תלויים גם לוחות הזמנים של היישום וגם אופן התפעול.
כבר פרוסה אצלנו סכמת הפצה משלנו — לשבור אותה?
לא. ממפים את התשתית הקיימת: מקורות, כללי מטמון, נקודות כשל. מעבירים בחלקים של התעבורה ומשווים מדדים; החזרת המשקל לאחור לוקחת דקות.
האם יידרשו תיקונים בקוד האפליקציה?
בדרך כלל לא: כתובות של סטטיקה ומדיה נמצאות בקונפיגורציה של ההפצה. תיקונים בלקוח נדרשים רק אם מעבירים אליו את הלוגיקה של בחירת המקור — עושים אותם עם תאימות לאחור.
מה יקרה בפרץ אחרי דיוור?
המטמון בקצה מחזיק את הפרץ: בקשות לא מגיעות למקור. קובעים מרווח וכללי טעינה משלימה, כדי שפספוסים בודדים לא ייצרו מפל, ובנוסף סף הגנה מפני אנומליות.
איך נדע שההפצה עובדת טוב?
מגדירים אנליטיקת הפצה: שיעור הפגיעות במטמון, זמן עד הבית הראשון, אזורים איטיים, שיעור שגיאות לפי קודים. משווים חתכים לפני ואחרי המעבר.
מי אחראי לתקלות אחרי המסירה?
בשבועות הראשונים אנחנו מנהלים: תורנות, טיפול באירועים, תיקוני קונפיגורציה. לאחר מכן מעבירים את הסכמה והנהלים לצוות שלכם או נשארים בתמיכה; זמן התגובה נקבע בכתב.
כיצד מוגנת אבטחת התוכן?
הגישה למקורות מוגבלת בחתימה ובאסימונים, כדי שלא ניתן יהיה להשתמש בקישור מחוץ לאפליקציה. חומרים פרטיים מסומנים כלא ניתנים למטמון, וסגירת רשימות תיקיות.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שההערכה תהיה מדויקת, ולא לפי אנלוגיה, נדרשים נתוני פתיחה על ההפצה הנוכחית: מה ומאיפה מופץ, כיצד בנויות כתובות הקבצים, והאם יש גרסאות של מערכי נתונים. תארו את סוגי התוכן — תמונות, וידאו, ספרי עזר מתעדכנים — ואת נקודות המסירה: שרת מקור אחד, כמה אזורים או ספק צד שלישי.
בתגובה נכין תוכנית יישום עם פריסת עבודות וסכמת מעבר ללא השבתה: התעבורה מועברת בחלקים, הכתובות הישנות ממשיכות להגיב, והחזרה לסכמה הקודמת זמינה בכל שלב.
- מה לשלוח להערכה: סכמת הפצה, רש