שיטות מומלצות לשימוש ברשת ב-Cloud Run

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

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

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

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

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

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

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

    כניסה ל-Metrics Explorer ב-Cloud Monitoring

  2. כדי לחפש את מספר המכונות של מאגרים בפרויקט, משתמשים בסוג המדד run.googleapis.com/container/instance_count. ב-Cloud Monitoring אפשר לראות את הערך של המדד הזה לאורך זמן.

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

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

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

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

בנוסף לטווחי הכתובות RFC 1918 IPv4, ‏Cloud Run תומך גם בטווחים 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

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

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

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

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

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

בקטע הבא מתוארות אסטרטגיות לצמצום ניצול יתר של יציאות ב-Cloud Run.

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

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

בידוד תעבורת נתונים יוצאת לאינטרנט

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

במקום זאת, הגדירו Direct VPC egress באמצעות --vpc-egress=all-traffic, ונתבו את תעבורת הנתונים דרך Cloud NAT באמצעות כתובות IP סטטיות ייעודיות לתעבורת נתונים יוצאת במקרים הבאים:

  • עומס העבודה מתחבר לנקודות קצה חיצוניות שרגישות למוניטין, כמו Payment Gateway, מסדי נתונים שמתארחים או ממשקי API של שותפים מאחורי חומות אש של אפליקציות אינטרנט (WAF) של צד שלישי. כתובות IP סטטיות ייעודיות מונעות מתנועה רועשת מדיירים אחרים במאגר המשותף להפעיל חסימות WAF חיצוניות או שגיאות HTTP 403.
  • עומס העבודה שלכם מריץ סריקת רשת מורשית, ספירת יציאות, טביעת אצבע של מארח, בדיקת פגיעויות, גירוד נתונים מהאינטרנט או בדיקת עומסים. הפעלת עומסי העבודה האלה במאגר ברירת המחדל של כתובות ה-IP המשותפות פוגעת במוניטין של כתובות ה-IP, עלולה לשבש את השירות ללקוחות אחרים תוך הפרה של Google Cloud מדיניות השימוש המקובל, ועלולה לגרום ל-Google להגביל או להשעות את עומס העבודה שלכם.

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

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

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

שימוש בסביבת ההפעלה מהדור השני

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

אפשר לבחור את סביבת ההפעלה באמצעות מסוף Google Cloud , ה-CLI של gcloud,‏ YAML או Terraform.

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

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

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

אם אתם שולחים תעבורת נתונים חיצונית לאינטרנט הציבורי, אתם צריכים לנתב את כל תעבורת הנתונים דרך רשת ה-VPC באמצעות הגדרת --vpc-egress=all-traffic. בגישה הזו, צריך להגדיר את Cloud NAT כדי להגיע לאינטרנט הציבורי.

כדי לאפשר ל-Cloud Run להשתמש בשער Cloud NAT ל-NAT ציבורי או ל-NAT פרטי, קראו את המאמר אינטראקציות של תעבורת נתונים יוצאת (egress) ישירה של VPC ב-Cloud NAT.

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

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

שימוש בהגדרת ברירת המחדל של MTU ב-Cloud Run

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

שיקולי עלות

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

  • מיקום משותף של המשאבים: נסו לפרוס את המשאבים של Cloud Run באותו אזור שבו נמצאים מסדי הנתונים של הקצה העורפי (כמו Cloud SQL או Firestore) והקטגוריות של Cloud Storage. העברת נתונים בין משאבי Google Cloud באותו אזור היא בחינם.
  • מעבר ל-Direct VPC egress: אם אתם מנתבים באופן מאובטח תעבורת נתונים למשאבים פנימיים של רשת VPC, כדאי לשקול לעבור ל-Direct VPC egress ממחברים של Serverless VPC Access. תעבורת הנתונים היוצאת ב-Direct VPC מצטמצמת לאפס, וכך מבטלת את התקורה הבסיסית של המחשוב ואת העלויות של מצב חוסר פעילות שמשויכות למכונות של המחבר.
  • שימוש ב-Cloud CDN: כדי להעביר נכסים סטטיים ותוכן שניתן לשמור במטמון, אפשר להציב את Cloud CDN לפני המשאבים של Cloud Run. הצגת נתונים מהקצה זולה משמעותית מתשלום על תעבורת נתונים לאינטרנט ישירות מ-Cloud Run.
  • מעקב אחרי תעבורת נתונים לאינטרנט: תעבורת נתונים נכנסת (ingress) היא תמיד בחינם, ואתם מקבלים 1GiB של העברת נתונים יוצאת בחינם לאינטרנט בחודש בתוך צפון אמריקה. כדאי להתמקד במעקב אחרי תנועה יוצאת שחוצה את גבולות האזור או חורגת מהתוכנית בחינם.

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

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