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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

רמת הרשת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

נניח שיש שירות לקצה העורפי עם שתי קבוצות NEGs בלי שרת (serverless) שמצורפות אליו – אחת באזור REGION_A ואחת באזור REGION_B. אם ה-NEG ללא שרתים שמשמש כבק-אנד למאזן עומסים גלובלי חיצוני של אפליקציות באזור REGION_A לא מגיב, מנגנון זיהוי החריגים מזהה את ה-NEG ללא שרתים כלא תקין. על סמך ניתוח של זיהוי חריגות, חלק מהבקשות החדשות נשלחות אל ה-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 במסמכי התיעוד של global backend service API.

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

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

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

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

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

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

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

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

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

מגבלות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלות ב-Cloud Run

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

מגבלות ב-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

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

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

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

תמחור

למידע על תמחור, אפשר לעיין במאמר בנושא תמחור רשת: איזון עומסים ב-Cloud.

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

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