תעבורת נתונים יוצאת (egress) ישירה מ-VPC

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

יתרונות מרכזיים

  • ניהול פשוט יותר: אין צורך לנהל את המכונות של המחברים, את סוגי המכונות ואת הגדרות ההתאמה לעומס. ב-App Engine, ההגדרות מטופלות ישירות בקובץ app.yaml של השירות.
  • חיסכון בעלויות: השימוש ב-Direct VPC egress לא כרוך בתשלום נוסף, ולא צריך לשלם חיובים חודשיים קבועים על מכונות וירטואליות של מחברים.
  • ביצועים ואמינות משופרים: מכיוון שאין צורך להשתמש במחבר, תעבורת הנתונים היוצאת של Direct VPC מספקת חיבור מהיר ואמין יותר למשאבים של רשת ה-VPC. הוא משתנה בהתאם לשירות App Engine ומונע ניתוקים שעלולים להתרחש במחברים במהלך תחזוקה.

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

  • תמיכה ביומני זרימה של VPC: אתם יכולים להפעיל את יומני הזרימה של VPC ברשת המשנה כדי לתעד את תנועת הנתונים היוצאת משירות App Engine.

מגבלות

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

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

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

  • תעבורת נתונים נכנסת ישירה ל-VPC: ב-App Engine אין תמיכה בתעבורת נתונים נכנסת ישירה ל-VPC.

  • מספר המכונות: אפשר להגדיר עד 100 מכונות לכל גרסה של App Engine לשימוש בתעבורת נתונים יוצאת ישירה של VPC.

  • ‫VPC Flow Logs: גרסת השירות של App Engine לא מוצגת ברשומות היומן. שם השירות מופיע בשדה AppEngineServiceDetails.

הקצאת כתובות IP

כדי להציב את שירות App Engine ברשת VPC, צריך לציין רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, לרשת המשנה יהיה אותו שם כמו לרשת. ‫App Engine מקצה כתובות IP מתת-הרשת שלכם.

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

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

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

כדי להגדיל את קנה המידה מהר יותר במהלך עלייה חדה בתעבורת נתונים, App Engine שומר כתובות IP בבלוקים של 16 (מסכה של רשת משנה 28) בכל פעם. כדי לוודא שיש לכם מספיק כתובות IPv4 זמינות לשימוש ב-App Engine, טווח כתובות ה-IPv4 של רשת המשנה צריך להיות /26 או יותר.

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

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

צריכת כתובות IP לשירותים

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

לדוגמה, אם משדרגים גרסאות כך ש-version 1 משתנה מ-100 מכונות לאפס, ו-version 2 משתנה מאפס ל-100, App Engine שומר את כתובות ה-IP של version 1 למשך עד 20 דקות אחרי ההתאמה לעומס. במהלך חלון השמירה של 20 הדקות, צריך לשמור לפחות 400 כתובות IP‏ ((100 + 100) * 2).

טווחי IPv4 נתמכים

‫App Engine תומך בטווחי ה-IPv4 הבאים של רשת המשנה:

  • RFC 1918
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • RFC 6598
    • 100.64.0.0/10
  • Class E
    • 240.0.0.0/4

לפני שמתחילים

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

  2. מפעילים את Compute Engine API ואת Cloud Build API:

    הפעלת ממשקי API

  3. כדי להשתמש ב-Direct VPC egress, צריך לוודא שאתם משתמשים בגרסה העדכנית ביותר של Google Cloud CLI:

    gcloud components update

התפקידים הנדרשים

כדי לוודא של-App Engine יש גישה לרשת ה-VPC, צריך להקצות את התפקידים הבאים לחשבון השירות שמשמש לפריסה:

  • התפקיד "סוכן שירות של App Engine": כברירת מחדל, לסוכן השירות של App Engine יש את התפקיד "סוכן שירות של App Engine" (roles/appengine.serviceAgent), שכולל את ההרשאות הנדרשות.

  • הרשאות בהתאמה אישית: כדי לקבל שליטה מפורטת יותר, צריך לתת לסוכן השירות של App Engine את ההרשאות הנוספות הבאות בפרויקט:

    • compute.networks.get
    • compute.subnetworks.get
    • ‫compute.subnetworks.use בפרויקט או ברשת המשנה הספציפית
    • compute.addresses.get
    • compute.addresses.list
    • compute.addresses.create
    • compute.addresses.delete
    • compute.addresses.createInternal
    • compute.addresses.deleteInternal
    • compute.regionOperations.get

  • התפקיד "משתמש ברשת של Compute": אם אתם לא משתמשים בתפקיד ברירת המחדל של סוכן השירות של App Engine או בהרשאות בהתאמה אישית, אתם צריכים להקצות את התפקיד "משתמש ברשת של Compute" (roles/compute.networkUser) בחשבון השירות של סוכן השירות של App Engine. ברשתות משנה עם כתובת IPv6 חיצונית נדרש גם התפקיד "אדמין של כתובת IP ציבורית ב-Compute"‏ (roles/compute.publicIpAdmin).

    לדוגמה, כדי להקצות את התפקיד "משתמש ברשת של Compute", מריצים את הפקודה הבאה:

    gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@gcp-gae-service." \
--role "roles/compute.networkUser"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט.
    • ‫PROJECT_NUMBER: מספר הפרויקט שבו פורסים את שירות App Engine.

הגדרת שירות App Engine עם Direct VPC egress

כדי לאפשר לשירות חדש או קיים של App Engine להתחבר ישירות לרשת ה-VPC, פועלים לפי השלבים הבאים:

  1. מוסיפים את ההגדרה הבאה של vpc_access לקובץ app.yaml:

    vpc_access:
  network_interface:
    network: NETWORK
    subnet: SUBNET
    tags:
        - NETWORK_TAGS
  vpc_egress: EGRESS_SETTING

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫NETWORK: השם של הרשת הקיימת שאליה מתחברים המכונות של האפליקציה, לדוגמה default. מציינים רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, לרשת המשנה יהיה אותו שם כמו לרשת.

    • ‫SUBNET: השם של רשת המשנה הקיימת שאליה מתחברים המכונות של האפליקציה, לדוגמה default. מציינים רשת VPC או רשת משנה, או את שתיהן. אם מציינים רק רשת, לרשת המשנה יהיה אותו שם כמו לרשת.

    • אופציונלי: NETWORK_TAGS: רשימה של תגי רשת שמשויכים למכונות של שירות App Engine, לשימוש בכללי חומת אש ובמדיניות ניתוב.

    • אופציונלי: EGRESS_SETTING: קובע איך תנותב תנועה יוצאת. בשדה הזה אפשר להגדיר את ההגדרות הבאות:

      • ‫all-traffic: כל הבקשות היוצאות מנותבות דרך רשת ה-VPC.
      • ‫private-ranges-only (ברירת המחדל): רק תנועה לכתובות IP פנימיות מנותבת דרך רשת ה-VPC. תעבורת הנתונים באינטרנט משתמשת בנתיב ברירת המחדל של App Engine.

  2. מריצים את הפקודה הבאה כדי לפרוס ב-App Engine:

    gcloud beta app deploy

ניתוק שירות

כדי לנתק את השירות מרשת ה-VPC:

  1. מסירים את הקטע vpc_access מהקובץ app.yaml.

  2. פורסים מחדש את השירות:

    gcloud beta app deploy

שיטות מומלצות לניהול כתובות IP

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

  • טווח כתובות ה-IP המומלץ: כדי להבטיח תאימות, מומלץ להתחיל עם הטווח של RFC 6598 ‏ (100.64.0.0/10).

  • טווחי כתובות IP חלופיים: אם אתם כבר משתמשים בטווח כתובות ה-IP המומלץ 100.64.0.0/10, אתם יכולים להשתמש בטווחים שאינם RFC 1918, כמו Class E ‏(240.0.0.0/4) ברשת המשנה.

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

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

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

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

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

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

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

פתרון בעיות

בקטע הזה מתוארות השגיאות הנפוצות שעלולות להתרחש כשפורסים את שירות App Engine עם Direct VPC egress.

אי אפשר למחוק את רשת המשנה

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

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

כשלים בפריסה

אם הפריסה נכשלת, ב-Google Cloud CLI מוצגות הודעות שגיאה שמציינות את שורש הבעיה. הנה כמה בעיות נפוצות:

  • מטא-נתונים שגויים של VPC, כמו איות שגוי של שם הרשת או רשת המשנה בקובץ app.yaml. כדי לתקן שגיאות אפשריות, בודקים את הגדרות ה-VPC בקובץ app.yaml.

  • הרשאות IAM לא מספיקות. חשוב לוודא שנתתם את ההרשאות הנדרשות לחשבון השירות שמשמש לפריסה. אם נתקלתם בשגיאות הרשאה במהלך הפריסה, ודאו שהקציתם לחשבון השירות את התפקידים הנוספים הבאים:

מיצוי כתובות IP

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

זליגות של כתובות IP

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

  • לחשבון השירות לפריסה יש רק הרשאות לשמירת כתובות (create, createInternal) ואין לו הרשאות לשחרור כתובות (delete, deleteInternal).
  • חשבון השירות נמחק בזמן שהזמנות אחרות של כתובות Google Cloud היו פעילות.
  • החשבון לחיוב ב-Cloud הוסר מהפרויקט והופעל בו מחדש מאוחר יותר, בזמן שההזמנות של כתובות ללא שרת היו פעילות.
  • הפרויקט Google Cloud נמחק ואז שוחזר, בזמן שעדיין היו קיימות הזמנות של כתובות ללא שרת (serverless).

כדי לפתור את הבעיה, בצע את הצעדים הבאים:

  1. כדי לזהות את הכתובות שדלפו, שולחים שאילתה ליומנים הבאים ב-Logs Explorer:

    protoPayload.authorizationInfo.permission=~"compute.addresses.delete.*"
protoPayload.authorizationInfo.resourceAttributes.type="compute.addresses"
protoPayload.resourceName=~"projects/.*/regions/.*/addresses/serverless-.*"
severity>=WARNING

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

  2. אם השאילתה מחזירה תוצאות, ודאו שחשבון השירות לפריסה מכיל את התפקיד "סוכן שירות של App Engine"‏ (roles/appengine.serviceAgent). אם אתם לא יכולים להשתמש בתפקיד הזה, ודאו שאתם נותנים תפקידים והרשאות נדרשים אחרים בחשבון השירות לפריסה.

  3. מוחקים ידנית את כתובות ה-IP שדלפו באמצעות מסוף Google Cloud או Google Cloud CLI:

    המסוף

    1. נכנסים לדף IP addresses במסוף Google Cloud :

      לדף כתובות ה-IP

    2. מריצים את השאילתה ובוחרים את כתובות ה-IP שדלפו שזיהיתם בשלב הקודם.

    3. לוחצים על Release static address כדי להסיר את הכתובות שדלפו.

    gcloud

    מריצים את הפקודה gcloud compute addresses delete:

    gcloud compute addresses delete ADDRESS_NAME --region=REGION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫ADDRESS_NAME: השם של כתובת ה-IP שדלפה.
    • ‫REGION: האזור של כתובת ה-IP שדלפה.