האפליקציות שלכם יכולות להתחבר לממשקי API בסביבת Production של Google מתוך Google Cloud או מרשתות היברידיות (on-premises ומרובות עננים).Google Cloud מציעה את אפשרויות הגישה הציבורית והפרטית הבאות, שמאפשרות גישה גלובלית ואבטחת SSL/TLS:
- גישה ציבורית לאינטרנט: שליחת תנועה אל
REGION-aiplatform.googleapis.com. - נקודות קצה מסוג Private Service Connect לממשקי Google API: אפשר להשתמש בכתובת IP פנימית שהוגדרה על ידי המשתמש, כמו
10.0.0.100, כדי לגשת אלREGION-aiplatform.googleapis.com, או בשם DNS שהוקצה, כמוaiplatform-genai1.p.googleapis.com.
התרשים הבא ממחיש את אפשרויות הגישה האלה.
חלק מהספקים של שירותי Vertex AI דורשים להתחבר לשירותים שלהם דרך נקודות קצה של Private Service Connect או ממשקי Private Service Connect. השירותים האלה מפורטים בטבלה אפשרויות גישה פרטיות ל-Vertex AI.
בחירה בין נקודות קצה אזוריות וגלובליות של Vertex AI
נקודת הקצה האזורית של Vertex AI (REGION-aiplatform.googleapis.com) היא הדרך הרגילה לגשת לממשקי API של Google. אם האפליקציות שלכם נפרסות בכמה Google Cloudאזורים, מומלץ מאוד להשתמש בנקודת הקצה הגלובלית (aiplatform.googleapis.com) כדי לבצע קריאה ל-API באופן עקבי וליצור עיצוב חזק יותר, אלא אם המודל או התכונה הרצויים זמינים רק באזור מסוים. היתרונות של שימוש בנקודת הקצה הגלובלית כוללים בין היתר:
- זמינות של מודלים ותכונות: חלק מהמודלים והתכונות הכי חדשים, המיוחדים או הספציפיים לאזור ב-Vertex AI מוצעים בהתחלה, או באופן קבוע, רק דרך נקודת קצה אזורית (לדוגמה,
us-central1-aiplatform.googleapis.com). אם האפליקציה שלכם תלויה באחד מהמשאבים הספציפיים האלה, אתם צריכים להשתמש בנקודת הקצה האזורית שמתאימה למיקום של המשאב הזה. זהו האילוץ העיקרי כשקובעים את אסטרטגיית נקודות הקצה. - פישוט של עיצובים מרובי-אזורים: אם מודל תומך בנקודת הקצה הגלובלית, השימוש בה מייתר את הצורך של האפליקציה להחליף באופן דינמי את נקודת הקצה ל-API בהתאם לאזור הפריסה הנוכחי שלה. הגדרה סטטית אחת מתאימה לכל האזורים, וכך מפשטת מאוד את הפריסה, הבדיקה והתפעול.
- הפחתת ההשפעה של הגבלת קצב (מניעת שגיאות
429): במודלים נתמכים, ניתוב בקשות דרך נקודת הקצה הגלובלית מפזר את התעבורה באופן פנימי ברשת של Google לשירות האזורי הזמין הקרוב ביותר. החלוקה הזו יכולה לעזור לכם לצמצם את העומס בשירותים מקומיים או את השגיאות שקשורות להגבלת קצב (429) באזורים מסוימים, כי היא מתבססת על רשת הליבה של Google לאיזון עומסים פנימי.
כדי לבדוק את הזמינות הגלובלית של מודלים של שותפים, אפשר לעיין בכרטיסייה Global בטבלת מיקומי נקודות הקצה של המודלים, שמופיעים בה גם מיקומים אזוריים. Google Cloud
שיקולים לגבי VPC משותף ב-Vertex AI
שימוש ב-VPC משותף הוא Google Cloud שיטה מומלצת ליצירת ממשל חזק ברשת ובארגון. במודל הזה יש הפרדה בין האחריות של צוותים שונים. יש פרויקט מארח מרכזי שמנוהל על ידי אדמינים של אבטחת רשת, ויש כמה פרויקטים של שירותים שמשמשים צוותים של אפליקציות.
ההפרדה הזו מאפשרת לאדמינים של הרשת לנהל ולאכוף באופן מרכזי את אבטחת הרשת (כולל כללי חומת אש, רשתות משנה ומסלולים), תוך העברת הסמכות ליצירה ולניהול של משאבים (לדוגמה, מכונות וירטואליות, אשכולות GKE וחיוב) לפרויקטים של השירות.
שימוש ב-VPC משותף מאפשר פילוח רב-שכבתי באמצעות האפשרויות הבאות:
- פילוח אדמיניסטרטיבי וחיוב: לכל פרויקט שירות (לדוגמה, Finance-AI-Project או Marketing-AI-Project) יש חיוב, מכסות ובעלות על משאבים משלו. כך אפשר למנוע מצוות אחד לצרוך את כל המכסה של הארגון, ולקבל שיוך ברור של העלויות.
- IAM ופילוח גישה: אפשר להחיל הרשאות מפורטות לניהול זהויות והרשאות גישה (IAM) ברמת הפרויקט, למשל:
- לקבוצת Google 'משתמשי כספים' מוקצה התפקיד roles/aiplatform.user רק ב-Finance-AI-Project.
- קבוצת Google 'משתמשי שיווק' מקבלת את אותו תפקיד רק ב-'Marketing-AI-Project'.
- ההגדרה הזו מבטיחה שמשתמשים בקבוצת הכספים יוכלו לגשת רק לנקודות הקצה, למודלים ולמשאבים של Vertex AI שמשויכים לפרויקט שלהם. הם מבודדים לחלוטין מעומסי העבודה של ה-AI של צוות השיווק.
אכיפה ברמת ה-API: נקודת קצה ל-API של Vertex AI מתוכננת לאכוף את הפילוח הזה שמבוסס על פרויקטים. כפי שמוצג במבנה של הקריאה ל-API, מזהה הפרויקט הוא חלק חובה ב-URI:
https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/google/models/${MODEL_ID}:streamGenerateContent
כשמשתמש מבצע את הקריאה הזו, המערכת מאמתת שלזהות המאומתת יש את הרשאות ה-IAM הנדרשות עבור ${PROJECT_ID} הספציפי שצוין בכתובת ה-URL. אם למשתמש יש הרשאות רק ל-Finance-AI-Project, אבל הוא מנסה לקרוא ל-API באמצעות המזהה של Marketing-AI-Project, הבקשה תידחה. הגישה הזו מספקת מסגרת חזקה וניתנת להרחבה, וכך מבטיחה שעם אימוץ ה-AI בארגון, תישמר הפרדה ברורה בין התפקידים, העלויות וגבולות האבטחה.
גישה ל-Vertex AI API דרך האינטרנט הציבורי
אם האפליקציה שלכם משתמשת בשירות Google שמופיע בטבלה של שיטות גישה נתמכות ל-Vertex AI כאינטרנט ציבורי, האפליקציה יכולה לגשת ל-API על ידי ביצוע חיפוש DNS מול נקודת הקצה של השירות (REGION-aiplatform.googleapis.com או aiplatform.googleapis.com), שמחזירה כתובות IP וירטואליות שניתנות לניתוב ציבורי. אפשר להשתמש ב-API מכל מקום בעולם, כל עוד יש חיבור לאינטרנט.
עם זאת, תעבורת נתונים שנשלחת ממשאבי Google Cloud לכתובות ה-IP האלה נשארת בתוך הרשת של Google. כדי להגביל את הגישה הציבורית ל-Vertex AI API, צריך להשתמש ב-VPC Service Controls.
נקודות קצה של Private Service Connect ל-Vertex AI API
באמצעות Private Service Connect, אתם יכולים ליצור נקודות קצה פרטיות באמצעות כתובות IP פנימיות גלובליות ברשת ה-VPC שלכם.
אפשר להקצות שמות DNS לכתובות ה-IP הפנימיות האלה עם שמות משמעותיים כמו aiplatform-genai1.p.googleapis.com ו-bigtable-adsteam.p.googleapis.com. השמות וכתובות ה-IP האלה הם פנימיים לרשת ה-VPC ולכל רשת מקומית שמחוברת אליה דרך שירותי רשת היברידית.
אתם יכולים לקבוע לאיזו נקודת קצה תועבר התנועה, ולהוכיח שהתנועה נשארת בתוך Google Cloud.
- אפשר ליצור כתובת IP של נקודת קצה (endpoint) גלובלית של Private Service Connect (/32) שמוגדרת על ידי המשתמש. מידע נוסף זמין במאמר בנושא הדרישות לגבי כתובות IP.
- יוצרים את נקודת הקצה של Private Service Connect באותה רשת VPC שבה נמצא Cloud Router.
- אפשר להקצות שמות DNS לכתובות ה-IP הפנימיות האלה עם שמות משמעותיים כמו
aiplatform-prodpsc.p.googleapis.com. מידע נוסף מופיע במאמר מידע על גישה לממשקי Google API דרך נקודות קצה. - ב-VPC משותף, פורסים את נקודת הקצה של Private Service Connect בפרויקט המארח.
שיקולים לגבי פריסה
בהמשך מפורטים כמה שיקולים חשובים שמשפיעים על האופן שבו משתמשים בגישה פרטית ל-Google וב-Private Service Connect כדי לגשת אל Vertex AI API.
גישה פרטית ל-Google
מומלץ להפעיל גישה פרטית ל-Google ברשתות משנה של VPC כדי לאפשר למשאבי מחשוב (כמו מכונות וירטואליות של Compute Engine ו-GKE) שאין להם כתובות IP חיצוניות להגיע אל Google Cloud ממשקי API ושירותים (כמו Vertex AI, Cloud Storage ו-BigQuery).
פרסום כתובת IP
צריך לפרסם את טווח תת-הרשתות של גישה פרטית ל-Google או את כתובת ה-IP של נקודת הקצה של Private Service Connect בסביבות מקומיות ומרובות עננים מ-Cloud Router כנתיב מותאם אישית לפרסום. מידע נוסף זמין במאמר בנושא פרסום טווחי כתובות IP בהתאמה אישית.
כללי חומת אש
צריך לוודא שהגדרת חומת האש בסביבות מקומיות ובסביבות מרובות עננים מאפשרת תעבורת נתונים יוצאת מכתובות ה-IP של תת-רשתות של גישה פרטית ל-Google או Private Service Connect.
הגדרת DNS
- צריך להגדיר את האזורים והרשומות של ה-DNS ברשת המקומית כך שבקשה אל
REGION-aiplatform.googleapis.comאו אלaiplatform.googleapis.comתופנה אל רשת המשנה של הגישה הפרטית ל-Google או אל כתובת ה-IP של נקודת הקצה של Private Service Connect. - אפשר ליצור אזורים פרטיים מנוהלים ב-Cloud DNS ולהשתמש במדיניות שרתים נכנסים של Cloud DNS, או להגדיר שרתי שמות מקומיים. לדוגמה, אפשר להשתמש ב-BIND או ב-Microsoft Active Directory DNS.
- אם הרשת המקומית שלכם מחוברת לרשת VPC, אתם יכולים להשתמש ב-Private Service Connect כדי לגשת לשירותים ולממשקי Google API ממארחים מקומיים באמצעות כתובת ה-IP הפנימית של נקודת הקצה. מידע נוסף זמין במאמר גישה לנקודת הקצה ממארחים מקומיים.