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

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

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

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

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

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

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

‫Cloud CDN שומר במטמון רק תשובות עם תוכן שניתן לשמירה במטמון. המידע הזה מועבר בכותרות של תגובת HTTP, בשילוב עם הגדרת ה-Backend. כשמגדירים כותרת תגובה בהתאמה אישית עם 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 כדי לאשר את עדכניות האובייקט. אם מופעלים מופעים בעורף העורפי שמציגים תגי 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, מעבירים את הסמן מעל סמל סימן הקריאה ולוחצים על Edit access.

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

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

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

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

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

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

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

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

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

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

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

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

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

סיבות תגובות תיקונים
התוכן שלך לא ניתן לשמירה במטמון. תגובה שניתן לשמור במטמון היא תגובת 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 המלאה של הבקשה כדי ליצור את מפתח המטמון. אתם יכולים להתאים אישית את מפתחות המטמון כך שיכללו או ישמיטו כל שילוב של פרוטוקול, מארח ומחרוזת שאילתה. לדוגמה, אם שני דומיינים משתמשים באותו תוכן סטטי, אפשר ליצור מפתח מטמון בהתאמה אישית שמשמיט את שדה המארח. במקרה הצורך, משתמשים במפתחות מטמון בהתאמה אישית.

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

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

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

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

Cache-Control: public, max-age=1

CDN-Cache-Control: public, max-age=86400

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

‫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 כמו מאזן עומסים חיצוני של אפליקציות (ALB).

  • בשורה השנייה נוספת כותרת 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, חשוב לוודא שמשתמשים בגרסה של base64 שמתאימה לשימוש בכתובות URL. קידוד base64 רגיל נכשל כשהתווים שנוצרים לא בטוחים לשימוש בכתובות URL. אפשר להשתמש ב-padding.

חתימה

הבקשה נדחתה על ידי 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 בקשות לביטול תוקף בדקה. בכל פעולה אפשר לציין תבנית נתיב שתואמת למספר כלשהו של אובייקטים.