מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) מאפשרים לכם להתאים אישית את תגובות השגיאה שלכם כשנוצר קוד מצב שגיאה של HTTP (4xx ו-5xx). אפשר להתאים אישית את תגובות השגיאה לשגיאות שנוצרות על ידי איזון העומסים וגם על ידי מופעי ה-Backend. אפשר גם להתאים אישית את תגובות השגיאה לקודי תגובת שגיאה שנוצרים כש-Google Cloud Armor דוחה תעבורה.
הנה דוגמה לדף שגיאה בהתאמה אישית שבו אפשר להגדיר תגובות לשגיאות באפליקציה צרכנית שפונה ללקוחות חיצוניים, עם מיתוג וסמל לוגו של החברה, קישורים לדפים קשורים והודעות בהתאמה אישית.
באמצעות מדיניות מותאמת אישית של תגובות לשגיאות, אפשר להגדיר תגובות שונות לשגיאות עבור קודי סטטוס שונים של שגיאות HTTP, דומיינים של כתובות URL, נתיבים של כתובות URL ושדות של כותרות הבקשה ופרמטרים של בקשות HTTP.
החזרת תגובות שגיאה מותאמות אישית עוזרת לשפר את חוויית המשתמש שלכם, ומספקת את היתרונות הבאים:
- מספק חוויית מיתוג עקבית
- מספק מידע רלוונטי לפי ההקשר כדי לשפר את השימושיות ואת חוויית המשתמש
- מצמצם את ההשפעה השלילית של זמן השבתה ושגיאות בצד הלקוח
- שיפור אבטחת הרשת
אם לא מגדירים מדיניות תגובת שגיאה מותאמת אישית, מוצג אובייקט שגיאה גנרי בלי קשר למותג, כמו שמוצג באיור 2.
תרחישים לדוגמה
התכונה 'תשובות שגיאה בהתאמה אישית' מתאימה לתרחישי שימוש רבים. בקטע הזה מפורטות כמה דוגמאות כלליות.
הגדרת דף תחזוקה משלכם
אתם יכולים להחזיר דף שגיאה עם מיתוג ופרטים של החברה כששרתי הקצה העורפיים לא תקינים או במצב תחזוקה. אתם יכולים ליצור דפי שגיאה הקשריים שמכילים מידע מועיל, כמו מספרי טלפון של מוקד שירות הלקוחות או מועדים שבהם המשתמשים צריכים לנסות שוב לגשת לאתר. יש לכם אפשרות להתאים אישית דפי שגיאה על סמך התאמה של תנאי שגיאה כמו שם מארח וקוד שגיאת HTTP.
הגדרת דף שגיאה משלכם כברירת מחדל
אתם יכולים להגדיר תשובות שגיאה מותאמות אישית לפי קודי שגיאה ספציפיים. לדוגמה, אפשר להגדיר דף שגיאה עם ההודעה 'כניסה או הרשמה' לקוד תגובת HTTP 401 (Unauthorized). אפשר גם להגדיר דף שגיאה שמופיע כברירת מחדל ומכיל את המיתוג של החברה ומידע רלוונטי אחר לכל קודי השגיאה של HTTP בסדרות 4xx ו-5xx.
הגדרת תגובות לשגיאות בכללי אבטחה
אתם יכולים להחזיר דף שגיאה מותאם אישית לקודי תגובה לשגיאה שנוצרים כשמדיניות האבטחה של Cloud Armor דוחה תעבורה. צריך לוודא שדף השגיאה מוגדר עם אותו קוד שגיאת HTTP מסדרה 4xx או מסדרה 5xx שהזנתם בכלל האבטחה של Cloud Armor.
צמצום ההשפעה של זמן ההשבתה
במקרים הרלוונטיים, אפשר להגדיר תגובת שגיאה שתחזיר קוד סטטוס 200 (OK) HTTP ותציג דף אינטרנט סטטי, כדי שהמשתמשים יראו מידע הקשרי ומועיל יותר במקום דף שגיאה במהלך ההשבתה.
התאמה אישית של תגובות לשגיאות על סמך סוג הבקשה של הלקוח
אפשר להתאים אישית תגובת שגיאה על סמך כותרות ופרמטרים של בקשת HTTP, למשל הכותרת Content-Type. כשמנתבים את הבקשה המקורית לשירות השגיאות, הניתוב יכול להתבסס על הכותרת Content-Type כדי להציג דף אינטרנט (לבקשות מדפדפנים) או JSON (לבקשות מ-API לאינטרנט).
איך פועלת מדיניות מותאמת אישית לתגובות לשגיאות
אפשר להגדיר מדיניות מותאמת אישית לתגובה לשגיאות בשלוש רמות של משאב מפת URL: ברמת איזון העומסים, ברמת הדומיין של כתובת ה-URL וברמת נתיב כתובת ה-URL.
ברמת מאזן העומסים. המדיניות חלה על כל התנועה שמתקבלת במאזן העומסים.
רמת הדומיין של כתובת ה-URL. המדיניות חלה על תנועה שמכוונת לשם דומיין או לשם מארח ספציפיים – לדוגמה,
www.example.com.רמה של נתיב כתובת ה-URL. המדיניות חלה על תנועה שמופנית לנתיב ספציפי – למשל,
www.example.com/images/*. ברמה הזו, אפשר גם להשתמש בתנאי התאמה מתקדמים עם כותרות ופרמטרים של בקשות HTTP – לדוגמה,Content-Type:application/json.
בטבלה הבאה מוצגת מדיניות תגובות שגיאה בהתאמה אישית שמוחלת ברמה של מאזן העומסים, ברמה של דומיין כתובת ה-URL וברמה של נתיב כתובת ה-URL של מפת URL.
| רמת המדיניות | שדה API |
|---|---|
| מאזן עומסים | urlMaps.defaultCustomErrorResponsePolicy |
| הדומיין של כתובת ה-URL | pathMatchers[].defaultCustomErrorResponsePolicy |
| נתיב כתובת ה-URL |
|
אם מגדירים מדיניות מותאמת אישית לתגובה על שגיאה בכמה רמות של משאב מפת URL, מוחזר אובייקט השגיאה שצוין במדיניות המותאמת אישית לשגיאה ברמה הנמוכה ביותר של מפת URL. מדיניות תגובות לשגיאות שמוגדרת ברמה נמוכה יותר של מפת URL היא ספציפית יותר, ולכן היא מקבלת עדיפות על פני מדיניות תגובות לשגיאות שמוגדרת ברמה גבוהה יותר של מפת URL.
לדוגמה, מדיניות תגובת שגיאה מותאמת אישית ברמת איזון העומסים מוחלת רק אם המדיניות תואמת לתנאי השגיאה, ולא הוגדרה מדיניות תואמת לקוד השגיאה ברמות הנמוכות יותר – דומיין כתובת ה-URL או נתיב כתובת ה-URL. באופן דומה, מדיניות תגובות שגיאה מותאמת אישית ברמת הדומיין של כתובת ה-URL חלה רק אם המדיניות תואמת לתנאי השגיאה, ולא הוגדרה מדיניות תואמת לקוד השגיאה ברמה הנמוכה יותר – נתיב כתובת ה-URL. מידע נוסף על ההגדרה הזו זמין במאמר הגדרת מדיניות מפורטת של תגובות שגיאה מותאמות אישית לדומיינים, לנתיבים ולקודי תגובות שגיאה שונים.
ציון של כמה כללים לתגובות שגיאה כדי להתאים לקודי תגובות שגיאה של HTTP
בכל רמה במדיניות מותאמת אישית של תגובות לשגיאות, אפשר לציין כמה כללים של תגובות לשגיאות. הכללים האלה יכולים להתאים לתגובת שגיאת HTTP לפי קודי שגיאה ספציפיים או טווח של קודי שגיאה. אם מציינים כלל לטווח של קודי שגיאה וגם כללים לקודי שגיאה ספציפיים, הכללים עם קודי השגיאה הספציפיים מקבלים עדיפות.
לדוגמה, נניח שהגדרתם כלל לשגיאה עם קוד 401 (Unauthorized) וכלל אחר לכל השגיאות בסדרה 4xx. אם שירות לקצה העורפי מחזיר קוד שגיאה 401, הכלל שתואם לשגיאה 401 יחול. עם זאת, אם שירות ה-Backend מחזיר קוד שגיאה 403, הכלל לגבי שגיאות 4xx נכנס לתוקף.
שינוי קוד תגובת ה-HTTP
כללי תגובת השגיאה מאפשרים לשנות את קוד תגובת ה-HTTP שמוחזר על ידי מאזן העומסים. המשמעות היא שאתם יכולים לבטל את קוד התגובה שנוצר על ידי השרת ולהגדיר מה יהיה קוד התגובה הסופי לבקשה. אפשר לציין להחזיר כל קוד תגובה של תגובת HTTP, כולל 200 (OK), סדרת 4xx או סדרת 5xx של קודי תגובה, או כל קוד תגובה אחר בן שלוש ספרות. מידע נוסף על שינוי קוד התגובה זמין במאמר בנושא הגדרת דף שגיאה לקוד שגיאה ספציפי עבור מארח ספציפי.
אם מגדירים קוד תגובה של ביטול, הוא נרשם כשדה חדש overrideResponseCodeServed ביומני איזון העומסים. השדה הזה מאוכלס רק בבקשות שבהן מוחל קוד תגובה חלופי על ידי מדיניות התגובה לשגיאה בהתאמה אישית.
הקוד status שנרשם בשדה httpRequest לא מושפע.
הוא מתעד את קוד התגובה של HTTP שנוצר על ידי השרת או את תגובת ה-HTTP שמאזן העומסים מחזיר. יכול להיות שקוד הסטטוס הזה יהיה שונה מהקוד בפועל שמועבר ללקוח אם קוד התגובה משתנה על ידי מדיניות מותאמת לתגובות שגיאה.
שמירת תשובות שגיאה מותאמות אישית במטמון
אפשר לשמור במטמון תגובה לשגיאה בהתאמה אישית על ידי הגדרת מדיניות negative caching עבור ה-Backend שיצר את השגיאה. הסיבה לכך היא להחיל שליטה מדויקת על שמירת נתונים במטמון עבור שגיאות נפוצות או הפניות אוטומטיות. כך אפשר להפחית את העומס על מקורות התוכן ולשפר את חוויית המשתמש על ידי הפחתת זמן האחזור של התגובה.
למדיניות negative caching שהוגדרה עבור ה-Backend שיצר את השגיאה תמיד יש עדיפות על פני המטא-נתונים Cache-Control שהוגדרו לאובייקט השגיאה בשירות השגיאות. בנוסף, אם מאזן העומסים מחזיר קוד תגובה של ביטול, מוחלת negative caching על סמך הערך של קוד התגובה של הביטול, ולא על סמך קוד התגובה המקורי שהבק-אנד החזיר למאזן העומסים. אם קוד שאינו קוד שגיאה (HTTP 200) מוחזר כקוד תשובה של ביטול, מדיניות שלילית של שמירה במטמון לא חלה.
אם אורך החיים (TTL) של תגובת השגיאה לא הסתיים, מאזן העומסים ממשיך להציג תוכן שנשמר במטמון בלי להפנות את הבקשה לשירות backend או לדלי backend. עם זאת, ההתנהגות הזו תלויה בשאלה אם Cloud CDN מופעל במאזן העומסים.
Cloud CDN מופעל במאזן העומסים
בקטע הזה מתואר אופן הפעולה של מאזן העומסים כש-Cloud CDN מופעל ונעשה שימוש בתשובות שגיאה מותאמות אישית.
כשמאזן העומסים מקבל בקשה, הוא בודק את המטמון של Cloud CDN. אם מאזן העומסים מוצא תגובה ששמורה במטמון לבקשת המשתמש, מאזן העומסים מחזיר למשתמש את התגובה ששמורה במטמון. התגובה שמאוחסנת במטמון יכולה להיות התוכן שהמשתמש ביקש או אובייקט שגיאה מותאם אישית.
אם אין פגיעה במטמון, מאזן העומסים מעבד את הבקשה ושולח אותה לקצה העורפי.
אם ה-Backend מציג תגובה ללא שגיאה, התגובה הזו מוחזרת למשתמש הקצה. עם זאת, אם בקשת לקוח נתקלת בשגיאה (קוד תגובה מסוג
4xxאו5xxHTTP), מאזן העומסים מנסה לקבל את אובייקט השגיאה המותאם אישית משירות השגיאות שציינתם באופן הבא:מאזן העומסים בודק את כל כללי המדיניות של תגובות שגיאה בהתאמה אישית ומקבל את הנתיב המתאים של אובייקט השגיאה בהתאמה אישית שמתאים לקוד הסטטוס של השגיאה ולתנאי התאמה אחרים.
מאזן העומסים מעביר את הבקשה לאובייקט השגיאה המותאם אישית לשירות השגיאות שצוין במדיניות התגובה לשגיאות מותאמות אישית. המונח שירות השגיאות מתייחס לקטגוריית קצה עורפי או לשירות לקצה העורפי שמציג את תוכן השגיאה המותאם אישית.
מאזן העומסים מחזיר את אובייקט השגיאה המותאם אישית ללקוח ששלח את הבקשה. הוא גם שולח את האובייקט ל-Cloud CDN כדי לשמור במטמון את אובייקט השגיאה למשך הזמן שצוין על ידי
cdnPolicy.negativeCachingPolicy[].ttl.
Cloud CDN מושבת במאזן העומסים
אם Cloud CDN מושבת, מומלץ להשתמש בקטגוריית קצה עורפי כשירות השגיאות ולא בשירות לקצה העורפי. הסיבה לכך היא ששירות לקצה העורפי לא יכול לשמור תוכן במטמון אם Cloud CDN מושבת. עם זאת, לקטגוריות קצה עורפי יש יכולת מובנית של שמירה במטמון, והן יכולות לשמור במטמון תגובות שגיאה גם אם Cloud CDN מושבת.
מגבלות
תשובות שגיאה מותאמות אישית נתמכות רק במאזן עומסים גלובלי חיצוני של אפליקציות (ALB). אין תמיכה במצבים אזוריים וקלאסיים.
אם אי אפשר לאחזר את אובייקט השגיאה המותאם אישית משירות השגיאות – למשל, אם נתיב התוכן לא מוגדר בצורה נכונה – יוצג אובייקט שגיאה כללי בלי קשר למותג.
מדיניות תגובת השגיאה המותאמת אישית לא עוקבת אחרי האובייקט שמוחזר על ידי שירות השגיאות ולא מסננת אותו כדי לזהות סיכוני אבטחה. לכן, חשוב להקפיד על סילוק נקודות חולשה והגבלת ההשפעה של חשיפה פוטנציאלית.
תשובות שגיאה מותאמות אישית נתמכות רק בדלי Cloud Storage שניתן לקרוא אותם באופן ציבורי.
כדי למנוע טעויות בהגדרות כשמשתמשים בקטגוריה של Cloud Storage, כדאי לעיין בשיטות המומלצות הנפוצות לשימוש ב-Cloud Storage.
תשובות שגיאה מותאמות אישית לא פועלות אם למאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) יש רק קטגוריות בק-אנד. בנוסף ל-קטגוריית קצה עורפי, צריך שיהיה לכם לפחות שירות לקצה העורפי אחד שמצורף למאזן העומסים.
כותרות תגובה בהתאמה אישית שמוגדרות על סמך המקור של תגובת השגיאה בהתאמה אישית לא חלות על תגובות יוצאות.
מדיניות התגובה לשגיאה בהתאמה אישית חלה רק על תגובות HTTP שמגיעות בפועל מהעורפים. אם התגובה מגיעה מ-Google Front End (GFE), יכול להיות שיוצגו קודי תגובת HTTP לא צפויים אחרים.
תגובות שגיאה מותאמות אישית לא תואמות לסוגי הבקשות הבאים:
- בקשות עם גופים שמפעילים מדיניות של הזרקת תקלות.
- בקשות גדולות שבהן שירות לקצה העורפי שולח תגובה לפני שהוא קורא את הגוף באופן מלא.
- בקשות שכוללות כותרת
Authorization. אם בקשה כוללת כותרתAuthorization, Cloud Storage מחזיר תגובהAuthentication Required.
תמחור
למידע על תמחור, אפשר לעיין במאמר בנושא תמחור רשת: איזון עומסים ב-Cloud.