אספקה גלובלית של תוכן סטטי: הגדרת Cloud CDN ב-GCP

הגדרת GCP Cloud CDN: היכן הפצת סטטיקה נשברת

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

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

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

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

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

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

מה נותן מטמון בקצה הרשת

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

זמן תגובה ושלמות טעינת העמוד

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

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

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

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

דרכים להגשת סטטיקה: מה לבחור למשימה

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

הגשה ישירה מאחסון אובייקטים

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

שכבת ביניים עצמאית מול הפצה מנוהלת

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

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

סדר ההגדרה: מביקורת ועד מסירה

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

מה מקבעים בשלב הביקורת

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

1. מלאי תוכן. סוגי קבצים, זמני שמירה, שיטת מתן גרסאות לשמות — ממנה תלוי אם אפשר להחזיק קובץ במטמון זמן רב.
2. תכנית ניתוב בקשות. מפת נתיבים לדליי בקאנד ולשירותים, סדר הכללים, התנהגות לכתובות לא קיימות.
3. כללי מטמון. מה נכנס למפתח המטמון, אילו כותרים ופרמטרים מתעלמים מהם, זמני ברירת מחדל ודריסות עבור נתיבים מסוימים.
4. חיבור דומיין ותעודה. קישור הדומיין להפצה, הנפקת תעודה מנוהלת, בדיקת אימות והעברת תעבורה.
5. בדיקה בתרחישי בקרה. בקשה קרה ובקשה חוזרת, עדכון קובץ, איפוס מטמון כפוי, תקינות כותרי התגובה.
6. נראות. יומני בקשות, שיעור הפגיעות במטמון וזמן תגובה בקצה — מהם רואים שההגדרה עובדת, ולא רק נראית מוגדרת.
7. מסירה והדרכה. נוהל פרסום ואיפוס מטמון, תכנית סביבת בדיקות ודיון עם הצוות שממשיך בהמשך להפעיל את ההפצה בעצמו.

קונפיגורציות, תכניות ונוהלי הפצה

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

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

תכנית ניתוב וכללי מטמון

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

נוהל עדכון גרסאות וביטול מטמון

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

פריקת המקור: תוצאות ההטמעה

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

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

מדדים לפני ואחרי

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

מה לעשות אם סטטיקה כבר מוגשת דרך CDN חיצוני?

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

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

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

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

ספקות טכניים לפני הטמעה

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

מה מוגש אם המקור אינו זמין?

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

האם CDN משפיע על הבנייה והפרסום?

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

איך להגביל גישה ולהימנע מהוטלינק?

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

היכן לראות סטטיסטיקת מטמון?

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

נדון במשימת הפצת סטטיקה ובתכנית העבודה

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

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

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