שיטות מומלצות להעברת תוכן

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

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

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

אופטימיזציה של שיעור מציאות במטמון (cache hit)

השיטות המומלצות הבאות עוזרות לשפר את שיעור מציאות במטמון (cache hit).

שמירה של תוכן סטטי במטמון

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

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

כדי לשמור במטמון באופן אוטומטי תשובות סטטיות מהמקור, אפשר להשתמש בהגדרה --cache-mode=CACHE_ALL_STATIC (ברירת מחדל). ההגדרה הזו מאפשרת ל-Cloud CDN לשמור במטמון סוגים נפוצים של תוכן סטטי כשהמקור לא מציין הנחיות שמירה במטמון בכותרות התגובה. חשוב לוודא שהתוכן שלכם תואם לקטגוריות שצוינו. אחרת, התוכן לא יישמר במטמון.

לא לשמור במטמון תוכן שספציפי למשתמש

במקרים מסוימים, דפדפנים יכולים לשמור במטמון תוכן שספציפי למשתמש. אל תשתמשו ב-Cloud CDN כדי לשמור במטמון תוכן ספציפי למשתמש.

שימוש במפתחות מטמון מותאמים אישית לשיפור יחס הפגיעה במטמון

כדי לשפר את הביצועים ואת המדרגיות, חשוב לבצע אופטימיזציה של שיעור מציאות במטמון (cache hit). כברירת מחדל, Cloud CDN משתמש בכתובת ה-URL המלאה של הבקשה כדי ליצור את מפתח המטמון. כדי לעזור באופטימיזציה של שיעור מציאות במטמון (cache hit), אפשר להשתמש במפתחות מטמון בהתאמה אישית כדי ש-Cloud CDN לא יפצל את המטמון שלא לצורך.

מאגר מפתח/ערך של Cloud CDN (לחצו כדי להגדיל).

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

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

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

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

מידע נוסף על התאמה אישית של מפתחות מטמון זמין במאמר שימוש במפתחות מטמון.

שימוש במסננים ספציפיים למסלול ב-GKE

כשמשתמשים ב-GKE Gateway, לא כדאי להחיל מדיניות גלובלית אחת של שמירת נתונים במטמון. במקום זאת, אפשר להשתמש ב-GCPHTTPFilter, משאב מותאם אישית ל-GKE Gateway, כדי להתאים אישית את cacheKeyPolicy ואת הגדרות ה-TTL עבור נתיבי URL ספציפיים במשאב HTTPRoute.

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

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

  • לנתיבי /api/*: אפשר לכלול מחרוזות ספציפיות של שאילתות כדי לוודא שהתשובות הדינמיות של ה-API מוצגות בצורה נכונה.

אופטימיזציה של הביצועים

השיטות המומלצות הבאות עוזרות לשפר את הביצועים.

מוודאים שהתמיכה בפרוטוקול HTTP/3 ובפרוטוקול QUIC מופעלת

‫HTTP/3 הוא פרוטוקול אינטרנט מהדור הבא. הוא מבוסס על QUIC, פרוטוקול שפותח מהפרוטוקול המקורי Google QUIC (gQUIC). יש תמיכה ב-HTTP/3 בין מאזן העומסים החיצוני מסוג HTTP(S),‏ Cloud CDN והלקוחות.

כדי לשפר את הביצועים באמצעות Cloud CDN, חשוב לוודא שHTTP/3 מופעל.

הפעלת תכונות להגנה על פודים כשמשתמשים ב-GKE Gateway

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

  • ‫serveWhileStale: מגדירים את serveWhileStale ל-24 שעות לפחות כדי לאפשר ל-Cloud CDN להציג תוכן שתוקף שלו פג אם הפודים של GKE מופעלים מחדש או שלא ניתן להגיע אליהם באופן זמני.

  • ‫requestCoalescing: הפעלת requestCoalescing מאפשרת לשלב כמה בקשות מקבילות למילוי מטמון לבקשה אחת לשרת המקור, וכך למנוע עליות פתאומיות בתנועת הגולשים שעלולות להשפיע על יחידת העיבוד המרכזית (CPU) ועל מגבלות הזיכרון של ה-Pod.

שימוש ב-negative caching

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

הפעלה של TLS early data

השימוש בנתונים מוקדמים של TLS משפר את שיעור החיבורים שמתחדשים ב-30 % עד 50 %. כדי להפעיל נתונים מוקדמים של TLS, משתמשים בפקודה gcloud compute target-https-proxies update עם האפשרות tls-early-data. מידע נוסף זמין במאמר בנושא הגדרת נתונים מוקדמים של TLS.

אפשר להפעיל את TLS early data במצבים STRICT או PERMISSIVE.

  • ‫STRICT: מאפשר נתונים מוקדמים לשיטות אידמפוטנטיות (GET,‏ HEAD,‏ OPTIONS ו-TRACE), שאין להן פרמטרים אחרים של שאילתות. זוהי השיטה הבטוחה יותר והיא מתאימה לרוב המקרים.
  • ‫PERMISSIVE: הפעלת נתונים מוקדמים לשיטות אידמפוטנטיות שיכולות לכלול פרמטרים של שאילתות. כשמשתמשים במצב הזה, צריך לעקוב מקרוב אחרי התנהגות האפליקציה והאבטחה שלה.

בקשות לנתונים מוקדמים שמשתמשות בשיטות HTTP לא אידמפוטנטיות או שיש להן פרמטרים של שאילתה נדחות עם קוד סטטוס HTTP 425.

אופטימיזציה של האבטחה

השיטות המומלצות הבאות עוזרות לשפר את האבטחה.

שימוש ב-Google Cloud Armor

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

שימוש בכתובות URL חתומות

אם אתם משתמשים בכתובות URL חתומות, חשוב לזכור את הנקודות הבאות:

אימות התאימות של IAP ו-Cloud CDN ל-GKE

אם אתם מנהלים את הסביבה שלכם באמצעות GKE Gateway API, ‏ Cloud CDN ו-IAP לא פועלים באותו מסלול. מוודאים שההגדרה לא מאפשרת GCPHTTPFilter לשמירה במטמון בנתיב שכבר מוגן על ידי GCPBackendPolicy עם IAP.

אימות של מקורות פרטיים

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

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

בנוסף, אם חומות אש של מקורות מונעות גישה למקור, צריך להשתמש ברשימת היתרים של כתובות IP כדי לוודא שהבקשה מגיעה מ-Cloud CDN או ממאזן עומסים חיצוני של אפליקציות (ALB). עם זאת, זה לא מונע מלקוחות אחרים של Media CDN לנסות לגשת לתוכן שלכם על ידי ציון המקור בהגדרות שלהם.

אופטימיזציה של המטמון

השיטות המומלצות הבאות עוזרות לבצע אופטימיזציה של הזיכרון הווירטואלי.

אופטימיזציה של ערכי TTL של מטמון

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

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

מידע נוסף מופיע במאמר שימוש בהגדרות TTL וביטול שלהן.

הגדרת תפוגה לתוכן רגיש לזמן

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

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

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

לאחר מכן, בוחרים את התפוגה לפי קטגוריית תוכן. לדוגמה, יכול להיות שזמן תפוגה של חמש שניות יתאים לתוצאות של משחקי ספורט שמתעדכנות כמעט בזמן אמת, וזמן תפוגה של שעה יתאים לעדכוני מזג אוויר. כדי להגדיר את תאריכי התפוגה של תוכן שמאוחסן ב-Cloud Storage, משתמשים במטא-נתונים של Cache-Control. כשתוכן מוגש על ידי Compute Engine, אתם שולטים בזמני התפוגה על ידי הגדרת תוכנת שרת האינטרנט.

זמני התפוגה מצוינים באמצעות הערכים max-age ו-s-maxage בכותרת Cache-Control. הכותרת הזו מוגדרת במפרט HTTP. לדוגמה, הכותרת Cache-Control הבאה מאפשרת לקרוא את התוכן המשויך באופן ציבורי ולשמור אותו במטמון עם תפוגה של 72 שעות (259,200 שניות):

  Cache-Control: public, max-age=259200

כדי למקסם את השמירה במטמון, פועלים לפי ההנחיות שבסקירה הכללית על שמירה במטמון. חשוב לזכור שהערכים max-age ו-s-maxage בשדה המטא-נתונים Cache-Control פועלים יחד באופן הבא:

  • הערכים max-age ו-s-maxage נמדדים בשניות.
  • הערך של s-maxage חל רק על מטמונים משותפים, ולא על מטמונים של דפדפנים.
  • הערך max-age חל על כל המטמונים, אלא אם הערך s-maxage מבטל אותו.

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

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

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

כדי ליצור גרסאות של תוכן, מוסיפים פרמטר לכתובת ה-URL, כמו מספר גרסה. יש כמה דרכים לכלול פרמטרים בכתובות URL, למשל:

  • מוסיפים מחרוזת שאילתה: file.ext?v=100.

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

  • משנים את שם הקובץ: file.1.0.0.ext או file_v100.ext.

  • משנים את הנתיב: /v100/file.ext.

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

שימוש מועט בביטול תוקף כדי להסיר תוכן

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

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

יש הגבלת קצב על ביטולי מטמון.

מידע נוסף על ניקוי המטמון זמין במאמר סקירה כללית על ניקוי המטמון.

אופטימיזציה של העקביות של הקובץ שהועלה

השיטות המומלצות הבאות עוזרות לבצע אופטימיזציה של העקביות בהעלאות קבצים.

מניעת עדכון של קבצים קיימים

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

לקבצים חדשים, כדאי להשתמש בשמות ייחודיים שיכולים לכלול מספרי גרסאות או תאריכים. הוספה של מספר גרסה (לדוגמה, file_v2.css) או תאריך (לדוגמה, file_20230806.js) לשם הקובץ עוזרת לוודא ש-Cloud CDN מאחזר את הגרסה הנכונה והמעודכנת. לא מומלץ להוסיף פרמטר לכתובת ה-URL של הקובץ (לדוגמה, file.css?v=2) כדי לאלץ אחזור של גרסה חדשה, כי הגישה הזו לא פותרת את הסיכון של שמירת עדכון לא אטומי של קובץ מקור במטמון, שבו עדיין יכולים להישמר במטמון קבצים חלקיים או לא מלאים.

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

ביצוע עדכונים אטומיים בקבצים

כשצריך לעדכן קבצים קיימים, צריך לעשות זאת באופן אטומי.

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

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

כשמעדכנים קבצים קיימים, שמירת טווחים במטמון יכולה לגרום ל-Cloud CDN לשמור טווחים מהקובץ הקודם אחרי שהקובץ החדש הועלה. אם Cloud CDN שמר במטמון טווחים של הקובץ הקודם, בקשות לחלקים חסרים עלולות להוביל לתשובות חלקיות. זה קורה כי Cloud CDN מזהה שהקובץ המקורי השתנה (בגלל שינויים ב-etag או ב-last-modified), מוחק תוכן מיושן (stale), מנתק הורדות שנמצאות בתהליך ויוצר שגיאה, שגורמת ללקוח לנסות שוב. כדי לצמצם את הבעיה, צריך להוציא פסילות לקבצים שנשמרים במטמון בטווח בייטים ועוברים עדכון.

אופטימיזציה של Monitoring ו-Logging

השיטות המומלצות הבאות עוזרות לבצע אופטימיזציה של מעקב ורישום ביומן.

מוודאים שהרישום ביומן מופעל ב-Cloud CDN

שיטה מומלצת לניהול Cloud CDN היא לוודא שהרישום ביומן מופעל בכל קצוות העורף שמופעל בהם Cloud CDN.

שימוש בלוח הבקרה המותאם אישית של Cloud Monitoring ל-Cloud CDN

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

סינון יומנים לפי מסלול GKE

בסביבת שער משותפת, אפשר להשתמש במסננים matched_url_path_rule או httpRequest.requestUrl ב-Cloud Logging כדי לראות נתוני ביצועים של שירותים ספציפיים. כדי לפתור בעיות שקשורות לפספוסים במטמון, מסננים לפי jsonPayload.statusDetails="response_sent_by_backend" כדי לזהות בדיוק אילו בקשות מגיעות ל-pods.

בדיקת תוצאות של בדיקות ביצועים של צד שלישי

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