פתרון בעיות ב-Cloud CDN

בהמשך מפורטים שלבים לפתרון בעיות שיוכלו לעזור לכם אם תיתקלו בבעיות הבאות בשימוש ב-Cloud CDN.

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

בעיות כלליות ופתרונות

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

התשובות לא נשמרות במטמון

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

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

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

יש כמה דרכים לבדוק את כותרות התגובה:

בדוגמה הבאה מוצג שימוש בפקודה curl כדי לבדוק את כותרות תגובת ה-HTTP של http://example.com/style.css:

curl -s -D - -o /dev/null http://example.com/style.css

פלט:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google

השוואה בין הכותרות האלה לבין הדרישות של תוכן שניתן לשמירה במטמון מגלה שחסרה בתגובה הכותרת הנדרשת Cache-Control (בהנחה שמצב המטמון מוגדר לערך USE_ORIGIN_HEADERS).

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

אחרי שמגדירים מחדש את שרת המקור כדי להוסיף את הכותרת הנדרשת, אפשר להשתמש שוב ב-curl כדי לבדוק את התוצאה:

curl -s -D - -o /dev/null http://example.com/style.css

פלט:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

פלט:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

פלט:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2

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

בנוסף, אם ETags מופעלים במופעי הקצה העורפי, Cloud CDN מסתמך על ETags כדי לאשר את עדכניות האובייקט. אם מופעי ה-backend משרתים תגי ETag שונים באותו אובייקט, Cloud CDN סופר אי-התאמות כאי-מציאה במטמון ומרענן את האובייקט. כדי למנוע את זה, מופעי ה-Backend צריכים להציג את אותו ETag או שצריך להשבית את ה-ETag.

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

curl -s -D - -o /dev/null http://example.com/image.png

פלט:

HTTP/2 200
date: Fri, 20 Mar 2020 15:02:30 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:20:59 GMT
etag: "10f-5a0f1256f1402"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:02:30 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

curl -s -D - -o /dev/null http://example.com/image.png

פלט:

HTTP/2 200
date: Fri, 20 Mar 2020 15:03:11 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:18:31 GMT
etag: "10f-5a0f11ca09b7a"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:03:11 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

אין אפשרות לגשת לאובייקטים ב-Cloud Storage

כדי לספק גישה לאובייקטים ב-Cloud Storage, צריך להגדיר כתובות URL חתומות או לתת לקטגוריה ולכל האובייקטים שבה גישה ציבורית ל-allUsers.

אם מחליטים לתת גישה ל-allUsers, אפשר לאמת את הגישה ברמת האובייקט באופן הבא.

המסוף

  1. במסוף Google Cloud , פותחים את Cloud Storage browser.

    פתיחת הכלי Storage browser

  2. לוחצים על מאגר כדי להציג את הדף Bucket details.

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

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

    • ישות: משתמש
    • שם: allUsers
    • גישה: קורא

מידע נוסף על בקרת גישה ל-Cloud Storage זמין במסמכי התיעוד בנושא ניהול זהויות והרשאות גישה (IAM) ל-Cloud Storage.

מידע נוסף על כתובות URL חתומות זמין במאמר בנושא שימוש בכתובות URL חתומות.

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

תוכן פרטי נשמר במטמון, או שהתוכן שנשמר במטמון שגוי

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

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

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

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

שיעור הפגיעות במטמון נמוך

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

השתמשו בטבלה הבאה כדי להבין כמה מהסיבות האפשריות לשיעור נמוך של מציאות במטמון (cache hit) ואת הפתרונות האפשריים.

סיבות תגובות תיקונים
התוכן שלכם לא ניתן לשמירה במטמון. תגובה שניתנת לשמירה במטמון היא תגובת HTTP ש-Cloud CDN יכול לאחסן. חשוב לוודא שהתוכן ניתן לשמירה במטמון.
מצב המטמון לא אופטימלי לאפליקציה. ל-Cloud CDN יש כמה מצבי מטמון. אם אתם לא משתמשים בכותרות של בקרת מטמון כדי לשלוט בהתנהגות השמירה במטמון, מומלץ לאפשר ל-Cloud CDN לשמור במטמון את כל התוכן הסטטי.
יש נפח קטן של תנועת גולשים. במהלך בדיקות וניסויים, סביר להניח שכמות התנועה שתייצרו תהיה נמוכה. ל-Google יש מטמון מבוזר גלובלי, ובקשות שמגיעות ממיקומים גיאוגרפיים שונים מועברות למיקומי קצה קדמי שונים של Google. בכל מיקום של חזית האתר, יכול להיות של-Google יש כמה מופעים נפרדים של מטמון.
  • חשוב לוודא שנפח התנועה שנשלח אל Google מספיק כדי לאכלס את כל מטמוני הנתונים הרלוונטיים.
  • במהלך הבדיקה, חשוב לפצל את התנועה לפי כתובת URL כדי שכל התנועה של כל קבוצת בקשות תגיע אל Google. לא מומלץ לפצל באופן אקראי כל בקשה לספק CDN אחר.
תשובות לכתובות URL מסוימות לא נשמרות במטמון. ‫Cloud CDN משלב את ה-URI של הבקשה המלא במפתחות המטמון שלו, כך ש-http://example.com/cat.jpg?color=orange ו-http://example.com/cat.jpg?color=gray הם רשומות מטמון נפרדות. תמיד משתמשים בכתובת URL אחת למשאב נתון.

אם אתם צריכים להעביר פרמטרים ל-JavaScript שפועל בדף שאפשר לשמור במטמון, כדאי להשתמש ב מזהי קטע במקום במחרוזות שאילתה.
המטמון מפולח שלא לצורך בגלל שדה הכותרת Vary. שדה הכותרת Vary בתגובה מתאר אילו חלקים בהודעת בקשה (מלבד השיטה, שדה הכותרת Host ויעד הבקשה) עשויים להשפיע על תהליך הבחירה והייצוג של תגובה בשרת המקור. לדוגמה, כדאי להשתמש בכותרת Vary: Accept-Encoding אם אתם מציגים תוכן שונה ללקוחות שיכולים לטפל בתגובות דחוסות וללקוחות שלא יכולים. משתמשים בכותרת התגובה Vary רק כשצריך.
אתם לא משתמשים במפתחות מטמון בהתאמה אישית. כברירת מחדל, Cloud CDN משתמש בכתובת ה-URL המלאה של הבקשה כדי ליצור את מפתח המטמון. אתם יכולים להתאים אישית את מפתחות המטמון כך שיכללו או לא יכללו כל שילוב של פרוטוקול, מארח ומחרוזת שאילתה. לדוגמה, אם שני דומיינים משתמשים באותו תוכן סטטי, אפשר ליצור מפתח מטמון מותאם אישית שמשמיט את שדה המארח. במקרה הצורך, אפשר להשתמש במפתחות מטמון בהתאמה אישית.

יש כמה מילויים של מטמון לאותו תוכן

באופן כללי, אפשר להקטין את מספר המקרים שבהם המטמון מתמלא על ידי הגדלת משך התפוגה של התשובות שניתנות לאחסון במטמון. אם כל שאר התנאים זהים, תראו פחות מקרים של מילוי מטמון בתגובה עם Cache-Control: public, max-age=86400 מאשר בתגובה עם Cache-Control: public, max-age=1.

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

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

הדחיסה לא פועלת

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

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

אם אתם משתמשים בתוכנת שרת האינטרנט nginx, עליכם לשנות את קובץ התצורה nginx.conf כדי להפעיל דחיסה. המיקום של הקובץ הזה תלוי במקום שבו nginx מותקן. בהרבה הפצות של Linux, הקובץ מאוחסן ב-/etc/nginx/nginx.conf.

כדי לאפשר דחיסת נתונים של nginx לפעול עם מאזן עומסים של אפליקציות (ALB) החיצוני, מוסיפים את שתי השורות הבאות לקטע http של nginx.conf:

gzip_proxied any;
gzip_vary on;

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

  • בשורה השנייה נוספת כותרת Vary: Accept-Encoding לתגובות. ‫Vary: Accept-Encoding מודיע לשרתי proxy של מטמון, כמו Cloud CDN, שעליהם לשמור רשומות מטמון נפרדות לגרסאות דחוסות ולא דחוסות של משאבים שניתנים לדחיסה.

אחרי שמשנים את הקובץ nginx.conf, צריך להפעיל מחדש את nginx כדי שהמערכת תשתמש בהגדרה החדשה. בהפצות רבות של Linux, אפשר להפעיל מחדש את nginx על ידי הפעלת הפקודה sudo service nginx restart או /etc/init.d/nginx restart.

התשובות מסתיימות בשגיאות byte_range_caching_aborted

כש-Cloud CDN מרכיב תשובה מכמה בקשות לטווח בייטים, הוא בודק אם הטווחים האלה הם מאותה גרסה של המשאב על ידי השוואה בין כותרות התשובה ETag ו-Last-Modified. אם Cloud CDN מזהה שהערך של אחת מהכותרות לא עקבי עם טווחים שכבר הועברו ללקוח, הוא מבטל את התשובה.

אם אתם מבחינים בתגובות לא צפויות שהופסקו, ברשומות ביומן של Cloud Logging עם byte_range_caching_aborted statusDetails, או אם המופעים מחזירים תגובות 412 Precondition Failed, ודאו שתוכנת שרת האינטרנט שפועלת בכל המכונות הווירטואליות (VM) מחזירה את אותם ערכים של ETag ו-Last-Modified עבור משאב נתון.

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

פתרון בעיות שקשורות לקובצי Cookie חתומים

אם אתם משתמשים בקובצי Cookie חתומים, יכולות להתרחש הבעיות הבאות.

קידוד

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

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

חתימה

הבקשה נדחית על ידי Cloud CDN.

  • חשוב לוודא שאתם משתמשים ב-HMAC-SHA-1 כאלגוריתם החתימה, ולא בגרסה אחרת של HMAC.

  • מוודאים שהפרמטר KeyName (שם הפרמטר רגיש לאותיות רישיות) תואם לשם מפתח תקין של שירות הקצה העורפי או של קטגוריית הקצה העורפי שבהם נעשה שימוש ב-Cloud CDN.

  • כשיוצרים וחותמים על URLPrefix, לא חותמים על הפרמטרים של השאילתה. חשוב לוודא שהתג URLPrefix מכיל רק את רכיבי הסכימה, המארח והנתיב (חלקי) של כתובת ה-URL.

  • מוודאים שבלוק החתימה – URLPrefix, Expires, KeyName וSignature עצמו – הם הקטעים האחרונים של קובץ ה-Cookie שמופרדים באמצעות :.

  • חשוב לוודא שהפעולות URLPrefix, Expires, KeyName ו-Signature מתרחשות בסדר הזה.

  • אסור לכלול את התו כוכבית (*) בסוף URLPrefix בקובץ Cookie חתום.

קובצי Cookie

  • בדרך כלל, הדפדפנים מגבילים את קובצי ה-Cookie ל-4KB לכל דומיין, עם מגבלה של 50 קובצי Cookie לכל דומיין בסך הכול. חשוב לשים לב לקובצי Cookie אחרים שאתם מנפיקים ודורשים מהלקוחות לשלוח, כי לשרתי אינטרנט רבים יש גם מגבלות על כותרות בקשות.

  • חשוב לוודא שאתם משתמשים בתו הנקודתיים (:), בנקודת הקוד של Unicode‏ U+003A, כתו המפריד לפרמטרים עם שם בקובץ Cookie חתום, ולא בתו האמפרסנד (&).

  • מוודאים שחותמת הזמן Expires בקובצי ה-Cookie שאתם מנפיקים לא קצרה מדי ללא צורך. תקופות תוקף של פחות מדקה או שתיים עלולות לגרום לבעיות של הבדלים בשעון בין האפליקציה שמנפיקה את האסימון לבין התשתית של Cloud CDN.

  • חשוב לוודא שלא מוגדרים כמה קובצי Cookie לאותו Domain ו-Path עם ערכים שונים. מגדירים קובץ Cookie יחיד לכל משתמש עם ערך של תחילית כתובת URL שכולל את כל התוכן שהמשתמש צריך לגשת אליו.

הודעות שגיאה

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

שגיאות בביטול תוקף של מטמון

קוד שגיאה הערות
Invalid value for field 'resource.path'

הפורמט של ערך הנתיב לא תקין. הנתיבים צריכים להתחיל ב-/, לא יכולים להכיל ? או #, ויכולים להכיל רק * אחד, שחייב להיות התו האחרון אחרי /.

הנתיבים לא יכולים להיות ארוכים מ-1,024 תווים. אם קיבלתם את השגיאה הזו, בדקו את ערך הנתיב ותקנו שגיאות בפורמט.

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