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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

רמת הרשת

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

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

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

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

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

בתרשימים הבאים מוצגת פריסה לדוגמה של NEG בלי שרת.

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

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

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

חיצוני אזורי

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

פנימי אזורי

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

בין אזורים

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

רכיבים של הקצה הקדמי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מסיכות של כתובות URL

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

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

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

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

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

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

מגבלות

ל-NEG בלי שרת (serverless) לא יכולות להיות נקודות קצה ברשת, כמו כתובת IP או יציאה.
קבוצות NEGs ללא שרת יכולות להצביע רק על משאבים ללא שרת שנמצאים באותו אזור שבו נוצרה קבוצת ה-NEG.
אם מאזן העומסים משתמש בעורף קצה של Serverless NEG, צריך ליצור את ה-Serverless NEG באותו פרויקט שבו נמצאים משאבי Cloud Run,‏ App Engine,‏ API Gateway או פונקציות Cloud Run שאליהם מצביע ה-NEG. יכול להיות שתראו שבקשות נכשלות אם אתם מחברים שירות שלא נמצא באותו פרויקט כמו ה-NEG ללא שרת.
מאזן עומסים שהוגדר עם NEG ללא שרת לא יכול לזהות אם המשאב הבסיסי ללא שרת פועל כמצופה. המשמעות היא שגם אם המשאב מחזיר שגיאות, מאזן העומסים ממשיך להפנות אליו תנועה. חשוב לבדוק היטב גרסאות חדשות של המשאבים לפני שמנתבים אליהן את תנועת המשתמשים.
Google Cloud console. אפשר ליצור קבוצות NEGs בלי שרתים רק כשיוצרים או עורכים מאזן עומסים באמצעות הדף איזון עומסים במסוףGoogle Cloud . בדף Network endpoint groups (קבוצות של נקודות קצה ברשת) אי אפשר ליצור או לערוך קבוצות NEG ללא שרתים, אבל אפשר לראות בו רשימה של כל קבוצות ה-NEG ללא שרתים בפרויקט.

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

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

לשירות לקצה העורפי גלובלי שמשמש מאזני עומסים גלובליים חיצוניים של אפליקציות יכול להיות רק NEG אחד בלי שרת לכל אזור. כדי לשלב כמה NEGs בלי שרת (serverless) בשירות לקצה העורפי יחיד, כל ה-NEGs צריכים לייצג פריסות שוות ערך מבחינה פונקציונלית באזורים שונים. לדוגמה, קבוצות ה-NEG יכולות להצביע על אותו משאב של Cloud Run,‏ App Engine או פונקציות Cloud Run שנפרס באזורים שונים.
לשירות קצה עורפי גלובלי שמשמש מאזני עומסים פנימיים של אפליקציות בין אזורים יכול להיות מצורף רק משאב אחד של Cloud Run או של פונקציות Cloud Run (דור שני).
אפשר לצרף לשירות לקצה העורפי אזורי רק קבוצת נקודות קצה בלי שרת (serverless) אחת.
הפניה לשירותים בפרויקטים שונים בפריסה של VPC משותף נתמכת בהגדרות שמכילות NEG בלי שרת. כדי להשתמש בתכונה הזו, אתם יוצרים את רכיבי הקצה הקדמי של מאזן העומסים (כתובת IP, כלל העברה, שרת proxy ביעד ומפת URL) בפרויקט שונה מרכיבי הבק-אנד של מאזן העומסים (שירות לקצה העורפי ו-NEG בלי שרת). שימו לב ששירות לקצה העורפי, ה-NEGs המשויכים ל-Serverless והמשאב התומך ב-Serverless (פונקציות 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 בלי שרת (serverless), ברירת המחדל של הזמן הקצוב לתפוגה היא 60 דקות. אי אפשר להגדיר את הזמן הקצוב לתפוגה. אם האפליקציה שלכם צריכה חיבורים ארוכים, אתם צריכים להגדיר את הלקוחות כך שינסו לשלוח מחדש בקשות במקרה של כשל.
כל ה-NEGs בלי שרת (serverless) שמשולבים בשירות לקצה העורפי צריכים להשתמש באותו סוג של בק-אנד. המשמעות היא שאפשר לשלב NEGs בלי שרת (serverless) ב-Cloud Run רק עם NEGs אחרים בלי שרת (serverless) ב-Cloud Run, ואפשר לשלב NEGs בלי שרת (serverless) ב-App Engine רק עם NEGs בלי שרת (serverless) ב-App Engine.
אי אפשר לשלב קבוצות NEG ללא שרת עם סוגים אחרים של קבוצות NEG באותו שירות backend. לדוגמה, אי אפשר לנתב לאשכול GKE ולשירות Cloud Run מאותו שירות לקצה העורפי.
כשמגדירים שירותים לקצה העורפי שמנתבים ל-NEGs ללא שרתים, יש שדות שמוגבלים:
- אי אפשר לציין מצב איזון. כלומר, לערכים RATE,‏ UTILIZATION ו-CONNECTION אין השפעה על חלוקת התנועה של מאזן העומסים.
- בדיקות תקינות לא נתמכות בבקאנדים ללא שרת. לכן, אי אפשר להגדיר בדיקות תקינות בשירותי קצה עורפיים שמכילים קצה עורפי של NEG בלי שרת (serverless). עם זאת, אפשר להפעיל זיהוי חריגים חשודים כטעויות כדי לזהות משאבים לא תקינים בלי שרתים ולהפנות בקשות חדשות למשאב תקין בלי שרתים.
אי אפשר להשתמש בפקודה gcloud compute backend-services edit כדי לשנות שירות לקצה העורפי עם קצה עורפי של NEG בלי שרת (serverless). כפתרון עקיף, אפשר להשתמש בפקודה gcloud compute backend-services update במקום זאת.

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

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

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

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

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

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

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

מגבלות ב-Cloud Run

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

מגבלות ב-App Engine

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

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

מגבלות ב-API Gateway

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

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

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

תמחור

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