סקירה כללית על קבוצות של נקודות קצה ברשת בלי שרת (serverless)

קבוצה של נקודות קצה ברשת (NEG) מציינת קבוצה של נקודות קצה בקצה העורפי של מאזן עומסים. קבוצת נקודות קצה ברשת ללא שרת (serverless NEG) היא קצה עורפי שמפנה למשאב של Cloud Run,‏ App Engine,‏ פונקציות Cloud Run או API Gateway.

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

  • משאב Cloud Run או קבוצת משאבים.
  • פונקציית Cloud Run או קבוצה של פונקציות (לשעבר פונקציות Cloud Run דור שני).
  • פונקציית Cloud Run (דור ראשון) או קבוצת פונקציות
  • אפליקציה בסביבת ברירת המחדל ב-App Engine או בסביבה גמישה ב-App Engine, שירות ספציפי באפליקציה, גרסה ספציפית של אפליקציה או קבוצת שירותים.
  • API Gateway שמספק גישה לשירותים באמצעות API בארכיטקטורת REST עקבי בכל השירותים, ללא קשר לאופן השימוש בשירות. היכולת הזו נמצאת בגרסת Preview.

מאזני עומסים נתמכים

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

סוג NEG ללא שרת (serverless) מאזני עומסים של אפליקציות
אזורי
פנימי		 פנימי
בין אזורים		 גלובלי
חיצוני		 קלאסי אזורי
חיצוני

Cloud Run

תמיכה ב-Cloud Run ובפונקציות Cloud Run (דור שני)
App Engine

Cloud Functions

תמיכה בפונקציות Cloud Run (דור ראשון), שנקראו בעבר Cloud Functions (דור ראשון)

תרחישים לדוגמה

כשמאזן העומסים מופעל באפליקציות בלי שרת, אפשר:

  • מגדירים את האפליקציה בלי שרת (serverless) כך שתפעל מכתובת IPv4 ייעודית שלא משותפת עם שירותים אחרים.
  • מיפוי של כתובת URL יחידה לכמה פונקציות או שירותים ללא שרתים שפועלים באותו דומיין. להסבר, ראו מסכות של כתובות URL.
  • שיתוף של מרחב כתובות ה-URL עם פלטפורמות מחשוב אחרות של Google Cloud . באמצעות כמה שירותים לקצה העורפי, מאזן עומסים אחד יכול לשלוח תנועה לכמה סוגים של קצה עורפי. מאזן העומסים בוחר את שירות הקצה העורפי הנכון על סמך המארח או הנתיב של כתובת ה-URL של הבקשה.
  • שימוש חוזר באותם אישורי SSL ומפתחות פרטיים שבהם אתם משתמשים ב-Compute Engine, ב-Google Kubernetes Engine וב-Cloud Storage. שימוש חוזר באותם אישורים מייתר את הצורך לנהל אישורים נפרדים לאפליקציות ללא שרת (serverless).

מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) ומאזן עומסים קלאסי של אפליקציות (ALB)

הגדרת מאזן עומסים חיצוני גלובלי של אפליקציות (ALB) או מאזן עומסים קלאסי של אפליקציות מאפשרת לאפליקציות ללא שרת (serverless) להשתלב עם שירותי ענן קיימים. אתם יכולים:

  • הגנה על השירות באמצעות Google Cloud Armor, מוצר אבטחה של חומת אש ליישומי אינטרנט (WAF) והגנה מפני DDoS בקצה הרשת, שזמין לכל השירותים שאליהם ניגשים דרך מאזן עומסים חיצוני של אפליקציות. יש כמה מגבלות שקשורות ליכולת הזו, במיוחד ב-Cloud Run וב-App Engine.
  • להפעיל את השירות כדי לייעל את ההעברה באמצעות Cloud CDN. ‫Cloud CDN שומר תוכן במטמון קרוב למשתמשים. ב-Cloud CDN יש יכולות כמו ביטול תוקף של מטמון וכתובות URL חתומות של Cloud CDN.
  • השתמשו בתשתית Edge של Google כדי לסיים את חיבורי ה-HTTP(S) של המשתמשים קרוב יותר למשתמשים, וכך להקטין את זמן האחזור.

כדי ללמוד איך להגדיר מאזן עומסים עם קצה עורפי של מחשוב בלי שרת (serverless computing), קראו את מאמרי העזרה הבאים:

שילוב של מאזן עומסים חיצוני של אפליקציות עם API Gateway מאפשר לקצה העורפי ללא שרת (serverless) ליהנות מכל התכונות שמסופקות על ידי Cloud Load Balancing. מידע נוסף זמין במאמר מאזן עומסים חיצוני של אפליקציות ל-API Gateway. כדי להגדיר מאזן עומסים חיצוני של אפליקציות (ALB) לניתוב תנועה ל-API Gateway, קראו את המאמר תחילת העבודה עם מאזן עומסים חיצוני של אפליקציות (ALB) ל-API Gateway. היכולת הזו נמצאת בגרסת Preview.

מאזן עומסים חיצוני אזורי של אפליקציות (ALB)

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

במאמר הגדרת מאזן עומסים חיצוני אזורי של אפליקציות (ALB) עם Cloud Run מוסבר איך להגדיר מאזן עומסים חיצוני אזורי של אפליקציות (ALB) עם קצה עורפי של מחשוב בלי שרת (serverless computing).

מאזן עומסים פנימי אזורי של אפליקציות (ALB) ומאזן עומסים פנימי חוצה-אזורים של אפליקציות (ALB)

כשמאזן עומסים של אפליקציות (ALB) פנימי מוגדר עם עורפי קצה של Cloud Run או של פונקציות Cloud Run (דור שני), אפשר לבצע את הפעולות הבאות:

  • הפעלת תכונות מתקדמות לניהול תנועה כמו הזרקת תקלות, שכתוב של כותרות, הפניות אוטומטיות, חלוקת תנועה ועוד, בשירותי Cloud Run ופונקציות Cloud Run (דור שני).
  • אתם יכולים להעביר בצורה חלקה שירותים מדור קודם מ-Compute Engine, מ-GKE או מסביבה מקומית ל-Cloud Run ולפונקציות Cloud Run (דור שני), כדי לנצל את היתרונות של חלוקת תנועה לפי משקל ולהעביר בהדרגה את התנועה ל-Cloud Run בלי זמן השבתה.
  • הגנה על שירותי Cloud Run ופונקציות Cloud Run (דור שני) באמצעות VPC Service Controls.
  • הגדרת נקודת כניסה פנימית אחת לאכיפת מדיניות בשירותים שפועלים ב-Cloud Run, בפונקציות Cloud Run (דור שני), ב-Compute Engine וב-GKE.

במאמר הגדרת מאזן עומסים פנימי אזורי של אפליקציות עם Cloud Run מוסבר איך להגדיר מאזן עומסים פנימי אזורי של אפליקציות עם קצה עורפי של מחשוב ללא שרת (serverless).

בהמשך הדף מוסבר איך להשתמש בקבוצות NEG בלי שרת (serverless) עם מאזני עומסים של אפליקציות (ALB). מידע נוסף על סוגים אחרים של קבוצות נקודות קצה ברשת זמין במאמר סקירה כללית על קבוצות של נקודות קצה ברשת.

סוגי נקודות קצה

ל-NEGs ללא שרתים אין נקודות קצה ברשת, כמו יציאות או כתובות IP. הם יכולים להפנות רק למשאב קיים של Cloud Run,‏ App Engine,‏ API Gateway או פונקציות Cloud Run שנמצא באותו אזור כמו ה-NEG.

כשיוצרים NEG ללא שרת, מציינים את שם הדומיין שמוגדר במלואו (FQDN) של משאב Cloud Run,‏ App Engine,‏ API Gateway או Cloud Run Functions. נקודת הקצה היא מסוג SERVERLESS. אין תמיכה בסוגים אחרים של נקודות קצה ב-NEG ללא שרת.

ל-NEG ללא שרתים יכולה להיות רק נקודת קצה אחת. נקודת הקצה מפנה לאפליקציה ללא שרת (serverless) או למסכת כתובות URL. מאזן העומסים משמש כקצה קדמי עבור אפליקציית מחשוב בלי שרת (serverless computing) ומעביר תעבורת נתונים לנקודת הקצה שצוינה. עם זאת, אם שירות לקצה העורפי מכיל כמה קבוצות NEG בלי שרתים באזורים שונים, מאזן העומסים שולח תעבורת נתונים לקבוצת ה-NEG באזור הקרוב ביותר כדי למזער את זמן האחזור של הבקשה.

רמת הרשת

במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), אתם יכולים להשתמש בקבוצת נקודות קצה ללא שרת (serverless NEG) במאזן עומסים במסלול הרגיל או במסלול הפרימיום של שירות הרשת. מסלול Premium נדרש רק אם רוצים להגדיר קבוצות NEGs ללא שרת בכמה אזורים.

מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) הם תמיד במסלול הרגיל.

מאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים ומאזני עומסים פנימיים אזוריים של אפליקציות (ALB) הם תמיד במסלול Premium.

רכיבים של איזון עומסים

במאזן עומסים שמשתמש בקצה עורפי של קבוצת נקודות קצה ברשת (NEG) בלי שרת (serverless), נדרשת הגדרה מיוחדת רק לשירות לקצה העורפי. ההגדרה של הקצה הקדמי זהה לכל מאזן עומסים אחר Google Cloud שמבוסס על שרת Proxy. בנוסף, מאזני עומסים פנימיים של אפליקציות (ALB) דורשים תת-רשת של שרת proxy בלבד כדי להריץ שרתי proxy של Envoy בשבילכם.

בתרשימים הבאים מוצגת פריסה לדוגמה של קבוצת נקודות קצה ללא שרת (serverless NEG).

חיצוני גלובלי

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

‫ מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) לאפליקציות ללא שרת (serverless). ‫
מאזן עומסים של אפליקציות (ALB) חיצוני גלובלי לאפליקציות בלי שרת (serverless) (לחצו כדי להגדיל).

חיצוניים אזוריים

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

‫ מאזן עומסים חיצוני אזורי של אפליקציות (ALB) לאפליקציות ללא שרת (serverless).
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) לאפליקציות בלי שרת (serverless) (לחצו כדי להגדיל).

אזורי פנימי

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

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

בין אזורים

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

מאזן עומסים פנימי חוצה אזורים עם פריסת Cloud Run.
מאזן עומסים פנימי של אפליקציות (ALB) בכמה אזורים עם פריסה של Cloud Run (לחצו כדי להגדיל).

רכיבי ממשק משתמש

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

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

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

שירות לקצה העורפי

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

ההגבלות הבאות חלות בהתאם לסוג של מאזן העומסים:

  • לשירות גלובלי לקצה העורפי שמשמש מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) יכולות להיות כמה קבוצות NEG ללא שרת, אבל רק קבוצת NEG אחת ללא שרת לכל אזור.
  • לשירות אזורי לקצה העורפי שמשמש מאזני עומסים אזוריים פנימיים של אפליקציות ומאזני עומסים אזוריים חיצוניים של אפליקציות, יכולה להיות רק קבוצת נקודות קצה ללא שרת (serverless) אחת.
  • בשירות לקצה העורפי גלובלי שמשמש מאזני עומסים של אפליקציות (ALB) פנימיים באזורים שונים יכולים להיות רק משאבים של Cloud Run ופונקציות Cloud Run (דור שני) שמצורפים אליו.

כל NEG ללא שרת יכול להפנות לאחד מהבאים:

  • ה-FQDN של משאב יחיד
  • מסכת כתובת URL שמפנה לכמה משאבים שמוצגים באותו דומיין

מסכת כתובת URL היא תבנית סכימה של כתובת URL, שמציינת לקצה העורפי של קבוצת נקודות הקצה ברשת בלי שרת (serverless) איך למפות את בקשת המשתמש לשירות הנכון. מסכות של כתובות URL שימושיות אם אתם משתמשים בדומיין מותאם אישית לאפליקציה בלי שרת (serverless), ויש לכם כמה שירותים שפועלים באותו דומיין. במקום ליצור NEG נפרד בלי שרת (serverless) לכל משאב, אפשר ליצור את ה-NEG עם מסכת URL כללית לדומיין מותאם אישית. למידע נוסף ולדוגמאות, ראו מסכות של כתובות URL.

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

זיהוי חריגים ב-NEGs בלי שרת

זיהוי חריגים הוא הגדרה אופציונלית שאפשר להפעיל בשירות לקצה העורפי גלובלי שמצורפים אליו NEGs בלי שרת (serverless). ניתוח זיהוי החריגים זמין רק למאזן עומסים פנימי של אפליקציות (ALB) בין אזורים ולמאזן עומסים גלובלי חיצוני של אפליקציות (ALB), ולא למאזן עומסים קלאסי של אפליקציות (ALB). בניתוח לזיהוי חריגים, המערכת מזהה קבוצות NEG לא תקינות בלי שרת (serverless) על סמך דפוסי תגובת ה-HTTP שלהן, ומפחיתה את שיעור השגיאות על ידי ניתוב רוב הבקשות החדשות ממשאבים לא תקינים למשאבים תקינים. כדי להבין איך פועל האלגוריתם לזיהוי חריגות ואת המגבלות שלו, קראו את הדוגמה הבאה.

נניח שיש שירות לקצה העורפי עם שתי קבוצות NEGs בלי שרת (serverless) שמצורפות אליו – אחת באזור REGION_A ואחת באזור REGION_B. אם ה-NEG בלי שרת (serverless) שמשמש כבק-אנד למאזן עומסים של אפליקציות (ALB) גלובלי חיצוני באזור REGION_A לא מגיב, מנגנון זיהוי החריגים מזהה את ה-NEG בלי שרת (serverless) כלא תקין. על סמך ניתוח של זיהוי חריגות, חלק מהבקשות החדשות נשלחות ל-NEG ללא שרתים באזור REGION_B.

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

  • שגיאות 5xx ברצף. קוד סטטוס של HTTP מסדרה 5xx נחשב לשגיאה.
  • שגיאות שער רצופות. רק קודי סטטוס של HTTP‏ 502, 503 ו-504 נחשבים לשגיאה.

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

כדי להפחית עוד יותר את שיעורי השגיאות, אפשר להגדיר פרמטרים אגרסיביים יותר לזיהוי חריגות. מומלץ להגדיר ערכים גבוהים יותר לסף ההוצאה מהתור (outlierDetection.baseEjectionTime). לדוגמה, מהבדיקות שלנו עולה שהגדרת outlierDetection.baseEjectionTime ל-180 שניות עם QPS קבוע של יותר מ-100 מובילה לשיעורי שגיאה שנצפו של פחות מ-5%. מידע נוסף על ה-API לזיהוי חריגים זמין בקטע outlierDetection במסמכי התיעוד של ה-API הגלובלי של שירות לקצה העורפי.

אי אפשר להשתמש בשדות הבאים של outlierDetection כששירות ה-Backend מחובר ל-NEG ללא שרת:

  • outlierDetection.enforcingSuccessRate
  • outlierDetection.successRateMinimumHosts
  • outlierDetection.successRateRequestVolume
  • outlierDetection.successRateStdevFactor

במאמר הגדרת מאזן עומסים חיצוני גלובלי של אפליקציות (ALB) עם קצה עורפי בלי שרת (serverless): הפעלת זיהוי חריגים מוסבר איך מגדירים זיהוי חריגים.

הסוואת כתובות URL

קצה עורפי של NEG ללא שרת יכול להפנות למשאב אחד של Cloud Run (או של App Engine או של פונקציות Cloud Run, אם רלוונטי), או למסכת כתובות URL שמפנה לכמה משאבים. מסכת כתובת URL היא תבנית של סכימת כתובת ה-URL. קבוצת נקודות הקצה בלי שרת (serverless) משתמשת בתבנית הזו כדי למפות את הבקשה למשאב המתאים.

מסכות של כתובות URL הן תכונה אופציונלית שמאפשרת להגדיר בקלות קבוצות NEG ללא שרת (serverless), כשהאפליקציה ללא שרת מורכבת מכמה משאבים של Cloud Run, פונקציות Cloud Run או App Engine. קבוצות NEG ללא שרת (serverless) שמשמשות עם מאזני עומסים של אפליקציות (ALB) פנימיים יכולות להשתמש רק במסכת כתובות URL שמפנה לשירותי Cloud Run או לפונקציות Cloud Run (דור שני).

מסכות של כתובות URL שימושיות אם האפליקציה בלי שרת (serverless) ממופה לדומיין מותאם אישית, ולא לכתובת ברירת המחדל ש- Google Cloud מספק. בדומיין מותאם אישית כמו example.com, אפשר לפרוס כמה משאבים בתתי-דומיינים או בנתיבים שונים באותו דומיין. במקרים כאלה, במקום ליצור קצה עורפי נפרד של NEG ללא שרת לכל משאב, אפשר ליצור NEG יחיד ללא שרת עם מסכת כתובת URL כללית לדומיין המותאם אישית (לדוגמה, example.com/<service>). ה-NEG מחלץ את שם השירות מכתובת ה-URL של הבקשה.

באיור הבא מוצג מאזן עומסים של אפליקציות (ALB) חיצוני עם שירות לקצה העורפי אחד וקבוצת NEG בלי שרת (serverless), שמשתמשת במסכת כתובות URL כדי למפות בקשות של משתמשים לשירותים שונים.

‫ חלוקת תעבורת הנתונים לאפליקציות ללא שרת (serverless). ‫
שימוש במסכת כתובת URL כדי להפיץ תנועה לשירותים שונים (לחצו כדי להגדיל).

מסכות של כתובות URL פועלות בצורה הטובה ביותר כשמשאבי האפליקציה משתמשים בסכימה צפויה של כתובות URL. היתרון בשימוש במסכת כתובות URL במקום במפת URL הוא שלא צריך ליצור קבוצות NEG נפרדות בלי שרת (serverless) לשירותי login ו-search. בנוסף, לא צריך לשנות את ההגדרות של מאזן העומסים בכל פעם שמוסיפים משאב חדש לאפליקציה.

מגבלות

  • ל-NEG ללא שרת לא יכולות להיות נקודות קצה ברשת, כמו כתובת IP או יציאה.
  • קבוצות NEGs ללא שרת יכולות להפנות רק למשאבים ללא שרת שנמצאים באותו אזור שבו נוצרה קבוצת ה-NEG.
  • במאזן עומסים שמשתמש בקצה עורפי של קבוצת NEG ללא שרת, צריך ליצור את קבוצת ה-NEG ללא שרת באותו פרויקט שבו נמצאים משאבי הגיבוי של Cloud Run,‏ App Engine,‏ API Gateway או פונקציות Cloud Run שאליהם מפנה קבוצת ה-NEG. יכול להיות שתראו בקשות שנכשלות אם תחברו שירות שלא נמצא באותו פרויקט כמו ה-NEG ללא שרת.

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

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

    • זיהוי חריגים: נתמך במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים, כדי לזהות קבוצות NEG בלי שרתים תקינים על סמך דפוסי תגובות HTTP.
    • Service Health ב-Cloud Run: נתמך במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) ובמאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים שהוגדרו עם עורפי NEG בלי שרתים.

  • Google Cloud מסוף. אפשר ליצור קבוצות NEG בלי שרת (serverless) רק כשיוצרים או עורכים מאזן עומסים (LB) באמצעות הדף Load balancing במסוףGoogle Cloud . בדף Network endpoint groups אי אפשר ליצור או לערוך קבוצות של נקודות קצה ברשת ללא שרתים, אבל אפשר לראות בו רשימה של כל הקבוצות האלה בפרויקט.

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

המגבלות הבאות חלות על שירותים לקצה העורפי שיש להם בק-אנד של קבוצת נקודות קצה ברשת (NEG) בלי שרת (serverless):

  • לשירות גלובלי לקצה העורפי שמשמש מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) יכולה להיות רק קבוצת NEG אחת ללא שרת (serverless) בכל אזור. כדי לשלב כמה NEGs ללא שרתים בשירות קצה עורפי יחיד, כל ה-NEGs צריכים לייצג פריסות שוות ערך מבחינה פונקציונלית באזורים שונים. לדוגמה, קבוצות ה-NEG יכולות להפנות לאותו משאב של Cloud Run,‏ App Engine או פונקציות Cloud Run שנפרס באזורים שונים.
  • לשירות קצה עורפי גלובלי שמשמש מאזני עומסים של אפליקציות (ALB) פנימיים בין אזורים יכול להיות מצורף רק משאב אחד של Cloud Run או של פונקציות Cloud Run (דור שני).
  • לשירות לקצה העורפי האזורי אפשר לצרף רק קבוצת NEG אחת ללא שרת.
  • הפניה לשירותים בפרויקטים שונים בפריסת VPC משותף נתמכת עם הגדרות שמכילות NEG בלי שרת. כדי להשתמש בתכונה הזו, אתם יוצרים את רכיבי הקצה הקדמי של מאזן העומסים (כתובת IP, כלל העברה, שרת proxy לחלוקת העומס ומפת URL) בפרויקט שונה מרכיבי הקצה העורפי של מאזן העומסים (שירות לקצה העורפי ו-NEG בלי שרת). חשוב לזכור: שירות הקצה העורפי, קבוצות ה-NEG ללא שרת שמשויכות אליו והמשאב ללא שרת שמגבה אותו (Cloud Run, ‏App Engine, ‏API Gateway או פונקציות Cloud Run) חייבים תמיד להיווצר באותו פרויקט.
  • ההגדרה של זמן קצוב לתפוגה של שירות קצה עורפי לא חלה על שירותי קצה עורפי עם קצוות עורפיים של NEG בלי שרתים. ניסיון לשנות את המאפיין resource.timeoutSec של שירות הקצה העורפי מוביל לשגיאה הבאה: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    בשירותים לקצה העורפי עם קצוות עורפיים של קבוצות NEG ללא שרת, ברירת המחדל של הזמן הקצוב לתפוגה היא 60 דקות. אי אפשר להגדיר את משך הזמן הזה. אם האפליקציה שלכם צריכה חיבורים ארוכים, צריך להגדיר את הלקוחות כך שינסו לשלוח מחדש בקשות במקרה של כשל.
  • כל ה-NEGs ללא שרתים שמשולבים בשירות קצה עורפי חייבים להשתמש באותו סוג קצה עורפי. המשמעות היא שאפשר לשלב NEGs בלי שרת ב-Cloud Run רק עם NEGs אחרים בלי שרת ב-Cloud Run, ואפשר לשלב NEGs בלי שרת ב-App Engine רק עם NEGs אחרים בלי שרת ב-App Engine.
  • אי אפשר לשלב קבוצות NEG ללא שרת עם סוגים אחרים של קבוצות NEG באותו שירות לקצה העורפי. לדוגמה, אי אפשר לנתב לאותו שירות backend מאשכול GKE ולשירות Cloud Run.
  • כשמגדירים שירותים לקצה העורפי שמנתבים ל-NEGs ללא שרתים, יש שדות שמוגבלים:
    • אי אפשר לציין מצב איזון. כלומר, לערכים RATE,‏ UTILIZATION ו-CONNECTION אין השפעה על חלוקת התנועה של מאזן העומסים.
    • בדיקות תקינות לא נתמכות בקצוות עורפיים ללא שרת (serverless). לכן, אי אפשר להגדיר בדיקות תקינות בשירותי קצה עורפיים שמכילים קצוות עורפיים של NEG ללא שרתים. עם זאת, אפשר להפעיל זיהוי חריגים כדי לזהות משאבים לא תקינים ללא שרת, ולנתב בקשות חדשות למשאב תקין ללא שרת.
  • אי אפשר להשתמש בפקודה gcloud compute backend-services edit כדי לשנות שירות לקצה העורפי עם קצה עורפי של NEG בלי שרת (serverless). כפתרון עקיף, אפשר להשתמש בפקודה gcloud compute backend-services update.

יש מגבלות נוספות בהתאם לסוג מאזן העומסים (LB) ול-backend בלי שרת (serverless).

מגבלות של מאזני עומסים פנימיים אזוריים של אפליקציות (ALB) ומאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)

  • קבוצות אזוריות של נקודות קצה ברשת (NEG) בלי שרת (serverless) שמשמשות עם מאזני עומסים פנימיים אזוריים של אפליקציות (ALB) או עם מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) יכולות להפנות רק למשאבים של Cloud Run או של פונקציות Cloud Run (דור שני).
  • בפרויקטים שמשתמשים ב-NEGs בלי שרתים, המגבלה של שאילתות לשנייה (QPS) היא 5,000 QPS לכל פרויקט לתעבורה שנשלחת לכל NEGs בלי שרתים שהוגדרו עם מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) או עם מאזני עומסים פנימיים אזוריים של אפליקציות (ALB). המגבלה הזו היא מצטברת בכל מאזני העומסים האזוריים החיצוניים של אפליקציות ובכל מאזני העומסים האזוריים הפנימיים של אפליקציות בפרויקט. המגבלה הזו היא לא לכל מאזן עומסים.

מגבלות של מאזני עומסים פנימיים של אפליקציות (ALB) באזורים שונים

  • קבוצות NEGs ללא שרת שמשמשות עם מאזני עומסים פנימיים של אפליקציות חוצות-אזורים יכולות להפנות רק למשאבי Cloud Run או Cloud Run Functions (דור שני).

מגבלות במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)

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

מגבלות ב-Cloud Run

  • מאזן עומסים חיצוני של אפליקציות (ALB) עם קבוצות NEG ללא שרת (serverless) לא תומך ב-Knative serving.
  • מאזני עומסים חיצוניים של אפליקציות לא תומכים באימות בקשות של משתמשי קצה למשאבי Cloud Run. עם זאת, אפשר להשתמש ב-IAP כדי לאמת משתמשים בארגון. אם אתם רוצים להפעיל את IAP, חשוב לזכור ש-IAP ו-Cloud CDN לא תואמים זה לזה. אי אפשר להפעיל אותם באותו שירות לקצה העורפי.

מגבלות ב-App Engine

  • אי אפשר להשתמש באיזון עומסים במספר אזורים עם App Engine. הסיבה לכך היא ש-App Engine דורש אזור אחד לכל פרויקט.
  • אם אתם משתמשים ב-IAP, אתם צריכים להשתמש באותו מזהה לקוח OAuth לכל שירותי App Engine שמשויכים למאזן עומסים יחיד.
  • מותר להשתמש רק במדיניות IAP אחת בנתיב הבקשה. לדוגמה, אם כבר הגדרתם מדיניות IAP בשירות לקצה העורפי, אל תגדירו מדיניות IAP נוספת באפליקציית App Engine.
  • במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB) עם קצוות עורפיים של סביבה גמישה ב-App Engine וקצוות עורפיים של סביבת ברירת המחדל ב-App Engine, אין תמיכה בהפניה לשירותים בפרויקטים שונים.
  • מומלץ להשתמש בשליטה בתעבורת נתונים נכנסת (ingress) כדי שהאפליקציה תקבל רק בקשות שנשלחות ממאזן העומסים (ומ-VPC אם משתמשים בו). אחרת, המשתמשים יוכלו להשתמש בכתובת ה-URL של האפליקציה ב-App Engine כדי לעקוף את מאזן העומסים, את מדיניות האבטחה של Cloud Armor, את אישורי ה-SSL ואת המפתחות הפרטיים שמועברים דרך מאזן העומסים.

מגבלות ב-API Gateway

מידע נוסף זמין במאמר מגבלות על NEGs ללא שרתים ועל API Gateway.

מגבלות בתכונות לניהול תנועה

  • ניהול תנועה מתקדם: תכונות כמו מדיניות מקומית של איזון עומסים וזיקה לסשן (session affinity) לא נתמכות בקצוות עורפיים של קבוצות NEG ללא שרת.
  • אי אפשר לציין זיקה לסשן (session affinity) בשירות קצה עורפי עם קצה עורפי של NEG בלי שרת (serverless). כפתרון עקיף ל-Cloud Run, אפשר להשתמש בתכונה הספציפית שלו session affinity.

תמחור

למידע על מחירים, ראו תמחור רשת: Cloud Load Balancing.

המאמרים הבאים