האפליקציות שלכם יכולות להתחבר לממשקי API בסביבת הייצור של Google מתוך Google Cloud או מרשתות היברידיות (מקומיות ומרובות עננים).Google Cloud מציעה את אפשרויות הגישה הציבוריות והפרטיות הבאות, שמספקות נגישות גלובלית ואבטחת SSL/TLS:
- גישה ציבורית לאינטרנט: שליחת תנועה אל
REGION-aiplatform.googleapis.com. - נקודות קצה (endpoints) של Private Service Connect ל-Google APIs: אפשר להשתמש בכתובת IP פנימית שמוגדרת על ידי המשתמש, כמו
10.0.0.100, כדי לגשת אלREGION-aiplatform.googleapis.com, או בשם DNS שהוקצה, כמוaiplatform-genai1.p.googleapis.com.
בתרשים הבא מודגמות אפשרויות הגישה האלה.
חלק מהבעלים של שירותים בפלטפורמת הסוכנים של Gemini Enterprise מחייבים אתכם להתחבר לשירותים שלהם דרך נקודות קצה של Private Service Connect או ממשקים של Private Service Connect. השירותים האלה מפורטים בטבלה אפשרויות לגישה פרטית ל-Gemini Enterprise Agent Platform.
בחירה בין נקודות קצה אזוריות וגלובליות של Gemini Enterprise Agent Platform
נקודת הקצה האזורית של Gemini Enterprise Agent Platform (REGION-aiplatform.googleapis.com) היא הדרך הרגילה לגשת ל-Google APIs. אם האפליקציות שלכם נפרסות בכמה אזורים Google Cloud, מומלץ מאוד להשתמש בנקודת הקצה הגלובלית (aiplatform.googleapis.com) כדי לבצע קריאות עקביות ל-API וליהנות מתכנון חזק יותר, אלא אם המודל או התכונה שאתם רוצים להשתמש בהם זמינים רק באזור מסוים. היתרונות של שימוש בנקודת הקצה הגלובלית כוללים:
- זמינות של מודלים ותכונות: חלק מהמודלים והתכונות העדכניים, המיוחדים או הספציפיים לאזור ב-Gemini Enterprise Agent Platform מוצעים בהתחלה, או באופן קבוע, רק דרך נקודת קצה אזורית (לדוגמה,
us-central1-aiplatform.googleapis.com). אם האפליקציה שלכם מסתמכת על אחד מהמשאבים הספציפיים האלה, אתם צריכים להשתמש בנקודת הקצה האזורית שמתאימה למיקום של המשאב הזה. זהו האילוץ העיקרי כשקובעים את אסטרטגיית נקודות הקצה. - פישוט של עיצובים מרובי-אזורים: אם מודל תומך בנקודת הקצה הגלובלית, השימוש בה מבטל את הצורך של האפליקציה להחליף באופן דינמי את נקודת הקצה ל-API בהתאם לאזור הפריסה הנוכחי שלה. הגדרה סטטית אחת מתאימה לכל האזורים, וכך מפשטת מאוד את הפריסה, הבדיקה והתפעול.
- הפחתת הסיכון להגעה למגבלת קצב (הימנעות משגיאות
429): במודלים נתמכים, ניתוב בקשות דרך נקודת הקצה הגלובלית מפזר את התעבורה באופן פנימי ברשת של Google לשירות האזורי הזמין הקרוב ביותר. החלוקה הזו יכולה לעזור לכם להפחית את העומס בשירותים מקומיים או את השגיאות שקשורות להגבלת קצב (429) באזורים מסוימים, כי היא מתבססת על רשת הליבה של Google לאיזון עומסים פנימי.
כדי לבדוק את הזמינות הגלובלית של מודלים של שותפים, אפשר לעיין בכרטיסייה Global ב Google Cloud טבלת מיקומי נקודות הקצה של המודלים, שמופיעים בה גם מיקומים אזוריים.
שיקולים לגבי VPC משותף ב-Gemini Enterprise Agent Platform
שימוש ב-VPC משותף הוא Google Cloud שיטת עבודה מומלצת ליצירת ממשל חזק של הרשת והארגון. במודל הזה יש הפרדה בין האחריות של צוותי האפליקציות לבין האחריות של מנהלי אבטחת הרשת. צוותי האפליקציות משתמשים בפרויקטים של שירותים, ומנהלי אבטחת הרשת מנהלים פרויקט מארח מרכזי.
ההפרדה הזו מאפשרת לאדמינים של הרשת לנהל ולאכוף באופן מרכזי את אבטחת הרשת (כולל כללי חומת אש, רשתות משנה ומסלולים), תוך הקצאת יצירה וניהול של משאבים (לדוגמה, מכונות וירטואליות, אשכולות GKE וחיוב) לפרויקטים של השירות.
VPC משותף מאפשר גישה רב-שכבתית לפילוח על ידי הפעלת האפשרויות הבאות:
- פילוח אדמיניסטרטיבי ופילוח לחיוב: לכל פרויקט שירות (לדוגמה, Finance-AI-Project או Marketing-AI-Project) יש חיוב, מכסות ובעלות על משאבים משלו. כך נמנע מצב שבו צוות אחד צורך את כל המכסה של הארגון, ומתקבלת שיוך ברור של העלויות.
- IAM ופילוח גישה: אפשר להחיל הרשאות מפורטות לניהול זהויות והרשאות גישה (IAM) ברמת הפרויקט, למשל:
- לקבוצת Google 'משתמשי כספים' מוקצה התפקיד roles/aiplatform.user רק ב-Finance-AI-Project.
- קבוצת Google 'משתמשי שיווק' מקבלת את אותו תפקיד רק ב-'Marketing-AI-Project'.
- ההגדרה הזו מבטיחה שמשתמשים בקבוצת הכספים יוכלו לגשת רק לנקודות הקצה, למודלים ולמשאבים של Gemini Enterprise Agent Platform שמשויכים לפרויקט שלהם. הם מבודדים לחלוטין מעומסי העבודה של ה-AI של צוות השיווק.
אכיפה ברמת ה-API: נקודת קצה ל-API של Gemini Enterprise עצמה מתוכננת לאכוף את הפילוח הזה שמבוסס על פרויקטים. כפי שמוצג במבנה של קריאת ה-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, תישמר הפרדת תפקידים ברורה, עלויות וגבולות אבטחה.
גישה לאינטרנט ל-Agent Platform API
אם האפליקציה שלכם משתמשת בשירות של Google שמופיע בטבלה של שיטות הגישה הנתמכות ל-Gemini Enterprise Agent Platform כאינטרנט ציבורי, האפליקציה יכולה לגשת ל-API על ידי ביצוע חיפוש DNS מול נקודת הקצה של השירות (REGION-aiplatform.googleapis.com או aiplatform.googleapis.com), שמחזירה כתובות IP וירטואליות שניתנות לניתוב באופן ציבורי. אפשר להשתמש ב-API מכל מקום בעולם, כל עוד יש חיבור לאינטרנט.
עם זאת, תעבורת נתונים שנשלחת ממשאבי Google Cloud לכתובות ה-IP האלה נשארת בתוך הרשת של Google. כדי להגביל את הגישה הציבורית ל-Gemini Enterprise API, צריך להשתמש ב-VPC Service Controls.
נקודות קצה של Private Service Connect ל-Agent Platform 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 (PSC) גלובלית (/32) שמוגדרת על ידי המשתמש. מידע נוסף זמין במאמר בנושא דרישות לגבי כתובות IP.
- יוצרים את נקודת הקצה של Private Service Connect באותה רשת VPC שבה נמצא Cloud Router.
- אפשר להקצות שמות DNS לכתובות ה-IP הפנימיות האלה עם שמות משמעותיים כמו
aiplatform-prodpsc.p.googleapis.com. מידע נוסף מופיע במאמר מידע על גישה לממשקי Google API דרך נקודות קצה. - ב-VPC משותף, פורסים את נקודת הקצה של Private Service Connect בפרויקט המארח.
שיקולים לגבי פריסה
בהמשך מפורטות כמה נקודות חשובות שמשפיעות על השימוש ב-Private Google Access וב-Private Service Connect כדי לגשת אל Agent Platform API.
גישה פרטית ל-Google
מומלץ להפעיל גישה פרטית ל-Google ברשתות משנה של VPC כדי לאפשר למשאבי מחשוב (כמו מכונות וירטואליות של Compute Engine ו-GKE) שאין להם כתובות IP חיצוניות להגיע אל Google Cloud ממשקי API ושירותים (כמו Gemini Enterprise Agent Platform, 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תופנה אל כתובת ה-IP של תת-הרשת של גישה פרטית ל-Google או של נקודת הקצה (endpoint) של Private Service Connect. - אתם יכולים ליצור תחומים פרטיים מנוהלים ב-Cloud DNS ולהשתמש במדיניות שרתים נכנסים של Cloud DNS, או להגדיר שרתי שמות מקומיים. לדוגמה, אפשר להשתמש ב-BIND או ב-Microsoft Active Directory DNS.
- אם הרשת המקומית שלכם מחוברת לרשת VPC, אתם יכולים להשתמש ב-Private Service Connect כדי לגשת לממשקי Google APIs ולשירותים ממארחים מקומיים באמצעות כתובת ה-IP הפנימית של נקודת הקצה. מידע נוסף זמין במאמר גישה לנקודת הקצה ממארחים מקומיים.