שיטות מומלצות לשימוש ברשת ב-App Engine

בדף הזה מפורטות השיטות המומלצות להגדרת אפשרויות הרשת של משאבי App Engine. מומלץ לעיין בכל הסעיפים בדף הזה כדי להבין את אפשרויות הרשת שנתמכות ב-App Engine ואת ההשלכות שלהן.

שיטות מומלצות:

ניהול כתובות IP.
מעקב אחרי השימוש בכתובות IP.
שימוש בכתובות IP שהן לא RFC 1918.
שימוש בתת-רשתות של IPv4 ו-IPv6 (סטאק כפול).
שימוש במאגר חיבורים ושימוש חוזר בחיבורים.
שימוש בסביבות זמן ריצה נתמכות.
תפוקה חיצונית מהירה יותר לאינטרנט.
תפוקה פנימית מהירה יותר ל-Google API.

ניהול כתובות IP

אתם צריכים לנהל את כתובות ה-IP כי כל מכונה של שירות App Engine צורכת כתובות IP מרשת המשנה. כדי לנהל את כתובות ה-IP, אפשר להשתמש בשיטות הבאות:

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

  • גודל תת-רשת: ודאו שטווח כתובות ה-IPv4 של תת-הרשת הוא /26 או יותר, כדי לספק מספיק כתובות IP להתאמה לעומס.

  • הקצאת יתר של כתובות IP: מומלץ להקצות יותר כתובות IP זמינות בתת-הרשת כדי למנוע מצב שבו לא נשארות כתובות IP פנויות. בדומה לשירותים אחרים של App Engine, בדרך כלל צריך להשתמש במספר כתובות IP שגדול פי 4 ממספר המכונות הפועלות (פי 2 למצב יציב ופי 2 נוספים במהלך הפריסה) כדי לאפשר התאמה חלקה לעומס ועדכונים חלקים.

מעקב אחרי השימוש בכתובות IP

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

כדי להעריך את השימוש בכתובת ה-IP:

  1. במסוף Google Cloud , נכנסים לדף Metrics Explorer:

    לדף Metrics Explorer

  2. כדי לחפש את מספר המכונות בפרויקט, משתמשים בסוג המדד appengine.googleapis.com/system/instance_count. המדד הזה סופר את כל המכונות של App Engine בפרויקט. בגרסאות שמוגדרות עם Direct VPC egress, מסננים לפי התווית module_id שמזהה את השירות, או לפי התווית version_id. ב-Cloud Monitoring אפשר לראות את הערך של המדד הזה לאורך זמן.

  3. כדי לקבל הערכה של מספר כתובות ה-IP שבשימוש, מכפילים ב-2 את הערך של המדד "מספר המכונות".

אסטרטגיות לניצול כתובות IP

אם יש לכם מספר גדול של עומסי עבודה ב-App Engine, יכול להיות שתיתקלו בבעיות של מיצוי כתובות IP כשתשתמשו במרחב כתובות ה-IP הפרטיות RFC 1918 עם תעבורת נתונים יוצאת ב-Direct VPC. האסטרטגיות הבאות יכולות לעזור לכם לנהל את מיצוי כתובות ה-IP באמצעות טווחי כתובות IP חלופיים.

שימוש בכתובות IPv4 שהן לא RFC 1918

חוץ מטווחים של כתובות RFC 1918 IPv4, ‏App Engine תומך גם בטווחים של RFC 6598 ושל Class E/RFC 5735. כלGoogle Cloud השירותים והתכונות פועלים עם טווחי הכתובות האלה שהם לא RFC 1918, כולל רשתות VPC, Cloud Load Balancing ו-Private Service Connect.

כדי לקבל את התאימות הטובה ביותר, מומלץ להתחיל עם הטווח RFC 6598‏ (100.64.0.0/10). אם אתם כבר משתמשים בטווח הזה במקום אחר, כדאי להשתמש ב-Class E/RFC 5735‏ (240.0.0.0/4) במקום זאת. מחלקה E היא מרחב עצום עם יותר מ-268 מיליון כתובות IP זמינות, כך שהיא תתמוך בצמיחה שלכם לאורך זמן. עם זאת, יש כמה מגבלות על Class E. לדוגמה, אין תמיכה ב-Windows ובחלק מהחומרה המקומית. איך משתמשים בכתובות IPv4 מסוג Class E כדי לצמצם את בעיות המחסור בכתובות IPv4 ב-GKE

שימוש ב-Cloud NAT או ב-Private Service Connect

אם עומס העבודה של App Engine נמצא בטווח שאינו RFC 1918 וצריך להגיע ליעד מקומי שמקבל רק RFC 1918, בחרו באחד מהפתרונות הבאים:

  • משתמשים ב-Hybrid NAT כדי לבצע תרגום כתובות ותעבורת נתונים יוצאת דרך טווח קטן של RFC 1918.
  • חושפים את השירות המקומי כשירות היברידי של Private Service Connect.

שימוש בתת-רשתות של IPv4 ו-IPv6 (שני פרוטוקולים)

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

אסטרטגיות לצמצום ניצול יתר של יציאות

בקטע הבא מתוארות אסטרטגיות לצמצום ניצול יציאות ב-App Engine.

שימוש במאגר חיבורים ושימוש חוזר בחיבורים

כששולחים מספר גדול של בקשות מאפליקציית App Engine לכתובת IP אחת, כדאי להשתמש במאגר חיבורים כדי לשמור על החיבורים ליעד ולהשתמש בהם שוב. שיעורי חיבור גבוהים לכתובת IP אחת יכולים למצות את היציאות היוצאות ולגרום לשגיאות של דחיית החיבור.

אסטרטגיות לשיפור הביצועים וקצב העברת הנתונים

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

שימוש בסביבות זמן ריצה נתמכות

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

שימוש ב-Direct VPC egress כדי להגביר את קצב תפוקת הנתונים היוצאים ברשת

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

דוגמה 1: תנועה חיצונית לאינטרנט

אם אתם שולחים תעבורת נתונים חיצונית לאינטרנט הציבורי, אתם צריכים לנתב את כל תעבורת הנתונים דרך רשת ה-VPC. כדי לעשות את זה, צריך להגדיר את השדה vpc_egress לערך all-traffic בקובץ app.yaml. בגישה הזו, צריך להגדיר את Cloud NAT כדי להגיע לאינטרנט הציבורי.

כדי להגדיר את Cloud NAT לשירות App Engine, קראו את המאמר הגדרת כתובת IP סטטית לתעבורת נתונים יוצאת. להגדרות שער Cloud NAT לשימוש עם Direct VPC egress עבור Public NAT או Private NAT, ראו אינטראקציות של תעבורת נתונים יוצאת ישירה של VPC ב-Cloud NAT.

דוגמה 2: תנועה פנימית ל-Google API

אם אתם משתמשים ב-Direct VPC egress כדי לשלוח תעבורת נתונים ל-Google API, כמו Cloud Storage, בחרו אחת מהאפשרויות הבאות:

  • מציינים את private-ranges-only (ברירת המחדל) עם גישה פרטית ל-Google:
    1. מגדירים את vpc_egress: private-ranges-only בקובץ app.yaml.
    2. מפעילים את גישה פרטית ל-Google.
    3. הגדרת DNS לגישה פרטית ל-Google. מוודאים שדומיין היעד (למשל storage.googleapis.com) ממופה לאחד מהטווחים הבאים של כתובות IP פנימיות:
      • 199.36.153.8/30
      • 199.36.153.4/30
  • מציינים את all-traffic באמצעות גישה פרטית ל-Google:
    1. מגדירים את vpc_egress: all-traffic בקובץ app.yaml.
    2. מפעילים את גישה פרטית ל-Google.

שימוש בהגדרת ברירת המחדל של MTU ב-App Engine

אל תשנו את ההגדרה של יחידת השידור המקסימלית (MTU) של רשת VPC כשאתם משתמשים בה עם App Engine. במקום זאת, השתמשו בערך ברירת המחדל של MTU, שהוא 1,460 בייטים.

שיקולי עלות

כשמגדירים את אפשרויות הרשת של המשאבים, חשוב להביא בחשבון את הדברים הבאים:

  • למקם את המשאבים באותו אזור: נסו לפרוס את המשאבים של App Engine באותו אזור שבו נמצאים מסדי הנתונים של ה-backend, כמו Cloud SQL, ‏Firestore וקטגוריות של Cloud Storage. העברת נתונים בין משאבי Google Cloud באותו אזור היא בחינם.
  • מעבר ל-Direct VPC egress: אם אתם מנתבים באופן מאובטח את תעבורת הנתונים למשאבים פנימיים של רשת VPC, כדאי לשקול לעבור ל-Direct VPC egress ממחברים של גישה ל-VPC ללא שרת (Serverless). תעבורת נתונים יוצאת ישירה ל-Direct VPC לא כרוכה בחיובים בסיסיים על משאבי מחשוב, וכך נמנעים העלויות הבסיסיות של תקורה על משאבי המחשוב והעלויות על חוסר פעילות שמשויכות למכונות של המחבר.
  • שימוש ב-Cloud CDN: כדי להוריד את העומס מנכסים סטטיים ומתוכן שניתן לשמור במטמון, אפשר להציב את Cloud CDN לפני המשאבים של App Engine. הצגת נתונים מהקצה זולה משמעותית מתשלום על תעבורת נתונים לאינטרנט ישירות מ-App Engine. אי אפשר להפעיל את Cloud CDN ישירות בכתובת ה-URL שמוגדרת כברירת מחדל ב-appspot.com. במקום זאת, צריך לנתב את הבקשות דרך מאזן עומסים חיצוני של אפליקציות (ALB) עם קצה עורפי של קבוצת נקודות קצה (NEG) ברשת ללא שרת (serverless). מידע נוסף זמין במאמר הגדרת מאזן עומסים של אפליקציות (ALB) גלובלי חיצוני באמצעות App Engine.
  • מעקב אחרי תעבורת נתונים לאינטרנט: תעבורת נתונים יוצאת שעוברת בין אזורים או מגיעה לאינטרנט הציבורי כרוכה בחיובים רגילים. כדאי להתמקד במעקב אחרי תנועה יוצאת שחוצה את גבולות האזור.

למידע נוסף, אפשר לעיין במחירון של App Engine או להעריך את העלויות באמצעות מחשבון עלויות.

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