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

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

קבוצת נקודות קצה ללא שרת (serverless) מפנה למשאב של Cloud Run,‏ App Engine,‏ פונקציות Cloud Run או API Gateway, ויכולה לייצג אחד מהבאים:

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

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

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

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

Cloud Run

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

Cloud Functions

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

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

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

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

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

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

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

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

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

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

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

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

סוגי נקודות קצה (endpoint)

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

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

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

מסלול רשת

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

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

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

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

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

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

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

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

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

אזורי חיצוני

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

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

פנימי אזורי

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

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

בין אזורים שונים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זיהוי חריגים בקבוצות של נקודות קצה ברשת (NEG) ללא שרת (serverless)

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

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

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

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

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

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

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

  • 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, אתם יכולים לפרוס כמה משאבים בתתי-דומיינים או בנתיבים שונים באותו דומיין. במקרים כאלה, במקום ליצור לכל משאב בק-אנד נפרד של קבוצת נקודות קצה ברשת בלי שרת (serverless), אפשר ליצור קבוצת נקודות קצה אחת ברשת בלי שרת (serverless) עם מסכת כתובת URL גנרית לדומיין מותאם אישית (לדוגמה, example.com/<service>). קבוצת נקודות הקצה ברשת מחלצת את שם השירות מכתובת ה-URL של הבקשה.

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

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

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

מגבלות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תמחור

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

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