במסמך הזה מוצגת ארכיטקטורת הפניה שתעזור לכם לתכנן ולפרוס מערכת AI אקטיבי מרובת-דיירים ב- Google Cloud. ככל שהארגון שלכם מרחיב את השימוש בבינה מלאכותית גנרטיבית, יחידות עסקיות שונות צריכות סוכני AI מיוחדים שיכולים לגשת לכלים ייחודיים, לפעול לפי כללים תפעוליים ספציפיים ולעבד מידע רגיש. יחידות עסקיות עשויות לפתח איי מידע (Information Silos) מפוצלים של אפליקציות בארגון, מה שעלול לגרום להוצאות תפעול גבוהות, לפערים משמעותיים בניהול ולסיכון לחשיפת נתונים. הארכיטקטורה הזו מראה איך לבנות מערכת מרכזית שמאפשרת לצוותים מבוזרים להשתמש ביכולות AI אוטונומיות, תוך שמירה על אבטחה ותאימות מאוחדות.
קהל היעד של המסמך הזה כולל ארכיטקטים, מפתחים ואדמינים שיוצרים ומנהלים מערכות מרובות סוכנים ברמה ארגונית בענן. ההנחה במסמך הזה היא שיש לכם הבנה בסיסית במושגים של AI, ML ו-LLM, וגם במושגים של AI אקטיבי.
בקטע פריסה במסמך הזה מוסברת אסטרטגיית הטמעה שתעזור לכם לבנות ולפרוס מערכת AI אקטיבי עם כמה דיירים.
ארכיטקטורה
בתרשים הבא מוצגת ארכיטקטורה של מערכת AI עם סוכן מרובה-דיירים, שמבוססת על מודל hub-and-spoke. מודל hub-and-spoke הוא עיצוב רשת שבו סביבה מרכזית, שנקראת hub, מתחברת לכמה סביבות מבודדות, שנקראות spokes.
הארכיטקטורה מורכבת מהרכיבים הבאים:
| רכיב | תיאור |
|---|---|
| VPC Service Controls | הארכיטקטורה משתמשת ב-VPC Service Controls כדי להגדיר גבול גזרה לשירות ברמת הארגון. גבולות גזרה לשירות אלה מספקים גבול אבטחה ברור ומונעים זליגת מידע. |
| מרכז הניתוב |
מרכז הניתוב משמש כנקודת הכניסה המרכזית לארכיטקטורה, והוא כולל את הרכיבים הבאים:
|
| מרכז משילות ואבטחה מרכזי |
המרכז המרכזי לניהול ולאבטחה הוא Google Cloud פרויקט ייעודי שמספק ניהול זהויות והרשאות גישה (IAM), רישום ביומן, מעקב ואבטחה באופן מרוכז לכל הפלטפורמה. המרכז הזה כולל את הרכיבים הבאים:
|
| פרויקטים של דיירים (tenants) |
כל פרויקט של דייר הוא פרויקט ייעודי לכל יחידה עסקית. Google Cloud פרויקטים נפרדים לדיירים הם סביבות מבודדות שכוללות את הרכיבים הבאים:
|
תהליך ליצירת סוכן
במערכת מרובת הדיירים לדוגמה שמוצגת בארכיטקטורה הקודמת, התהליך הוא כזה:
- בקשה של משתמש מנותבת דרך מאזן עומסים חיצוני של אפליקציות. במרכז הניתוב, הבדיקות האלה מתבצעות כדי לוודא שרק תנועה מאומתת ובטוחה מגיעה לפורטל הקצה הקדמי:
- Cloud Armor מחיל מדיניות אבטחה כדי לספוג כל מתקפת מניעת שירות מבוזרת (DDoS) ראשונית שמבוססת על פרוטוקול רשת בשכבה 4. Cloud Armor בודק את הבקשה ומסנן תנועה זדונית, כמו הזרקת SQL (SQLi), פרצת אבטחה XSS (cross-site scripting) וחתימות של בוטים מוכרים.
- הגנה מוגברת על המודל מיירטת את מטען היישום כדי לזהות ולדחות מתקפות של החדרת פרומפטים או כוונות זדוניות.
- אם אחת מהשכבות האלה מזהה איום או גישה לא מורשית, מאזן העומסים משליך את הבקשה בקצה הרשת.
- אם שכבות האבטחה לא מזהות איום והן מאמתות את הגישה של המשתמש, מאזן העומסים מעביר את התנועה לשירות הקצה העורפי.
- אם הבקשה עוברת את כל הבדיקות, מאזן העומסים מעביר את הבקשה לפלטפורמת ה-Frontend, שמבצעת את הפעולות הבאות:
- שולף את הזהות של המשתמש, כמו היחידה העסקית או מזהה הדייר של המשתמש.
- משתמש ב-IAP כדי לאמת את הזהות הארגונית של המשתמש ואת תקינות המכשיר.
- הכלי משתמש במאגר נתונים דינמי כדי לזהות את דייר היעד הנכון.
- פורטל חזית האפליקציה מעביר את הבקשה לדייר. כדי לוודא שהסוכן לא יכול לגשת לפרויקטים אחרים בדייר או לשירותים לא מורשים, Agent Runtime משתמש במדיניות PAB כדי להגביל את המשאבים שהסוכן יכול לגשת אליהם. Google Cloud
- Model Armor משתמש בהגנה על נתונים רגישים כדי לבדוק ולהסתיר באופן דינמי פרטים אישיים מזהים (PII) או תוכן מוגבל. הגנה מוגברת על המודל מבצע בדיקה נוספת של החדרת הנחיות זדוניות מהבקשה כדי לוודא שהסוכן מעבד רק נתונים בטוחים.
כדי ליצור תשובה, Gemini מבצע את המשימות הבאות:
- מבצע מעבר נימוקים ראשוני כדי להבין את כוונת המשתמש.
- אם Gemini קובע שחסרות לו עובדות ספציפיות, הוא יוצר תוכנית להפעלת כלי נתונים ספציפיים של הדייר:
- כדי לוודא שלמשתמש יש הרשאה לגשת למשאבי הנתונים, הסוכן מאמת את הזהות של המשתמש ואת הקישורים של תפקיד IAM.
- כדי לאחזר הקשר, הסוכן מבצע קריאה לכלי דרך שרת ה-MCP למאגר הנתונים של הדייר.
- הסוכן יוצר תגובה מבוססת על ידי שילוב של הלוגיקה הפנימית שלו עם העובדות החדשות שאוחזרו וספציפיות לדייר.
אם Gemini לא צריך עובדות נוספות, הוא יוצר תשובה ושולח אותה ל-Model Armor.
הגנה מוגברת על המודל בודק ומבצע אנונימיזציה באופן דינמי לכל פרט אישי מזהה (PII) או תוכן מוגבל, ושולח את התגובה שעברה סניטציה לסוכן הדייר. הבדיקה הסופית הזו עוזרת לוודא שלא יהיו דליפות של נתונים רגישים בפלט.
התשובה מנותבת חזרה למשתמש, מהסוכן של הדייר דרך פלטפורמת הקצה הקדמי ואז דרך מאזן העומסים.
המוצרים שהשתמשו בהם
ארכיטקטורת ההפניה הזו משתמשת במוצרים ובכלים הבאים Google Cloud ובמוצרים ובכלים בקוד פתוח, שנבחרו בגלל האופי שלהם בלי שרת (serverless), יכולת המדרגיות שלהם ואמצעי האבטחה שלהם:
- VPC Service Controls: פונקציונליות מנוהלת של רשת שמצמצמת את הסיכונים לזליגת נתונים מהמשאבים שלכם ב- Google Cloud .
- Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים בעלי ביצועים גבוהים וניתנים להתאמה.
- Google Cloud Armor: שירות אבטחת רשת שמציע כללים של חומת אש ליישומי אינטרנט (WAF) ועוזר להגן מפני מתקפות DDoS ומתקפות על אפליקציות.
- הגנה מוגברת על המודל: שירות שמספק הגנה למשאבי AI גנרטיבי ו-AI אקטיבי מפני החדרת פרומפטים, דליפות של מידע אישי רגיש ותוכן פוגעני.
- שרת proxy לאימות זהויות (IAP): שירות שמאפשר מודל גישה של אפס אמון לאפליקציות ולמכונות וירטואליות.
- ניהול זהויות והרשאות גישה (IAM): מערכת שמאפשרת ליצור ולנהל הרשאות למשאבים ב- Google Cloud .
- Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ קונטיינרים ישירות על גבי התשתית הניתנת להרחבה של Google.
- Gemini Enterprise Agent Platform: פלטפורמה מקיפה שמאפשרת לכם ליצור סוכני AI ברמה ארגונית, להרחיב את השימוש בהם, לנהל אותם ולבצע אופטימיזציה שלהם.
- Gemini: משפחה של מודלים מולטי-מודאליים של AI שפותחו על ידי Google.
- Model Context Protocol (MCP): תקן קוד פתוח לחיבור אפליקציות מבוססות-AI למערכות חיצוניות.
- Cloud Logging: מערכת לניהול יומנים בזמן אמת עם אחסון, חיפוש, ניתוח והתראות.
תרחיש שימוש
מערכות AI אקטיביות עם ריבוי דיירים מתאימות לארגונים גדולים שרוצים להרחיב את פריסת ה-AI הגנרטיבי מעבר לאפליקציה אחת. כדי לזהות תרחישי שימוש שבהם הארכיטקטורה הזו מתאימה, צריך לנתח את התהליכים העסקיים ולזהות צוותים שונים שזקוקים לסוכני AI ייעודיים משלהם עם גישה לכלים ייחודיים ולמידע אישי רגיש. הגישה הזו עוזרת לכם להעניק לצוותים מבוזרים יכולות AI אוטונומיות, תוך שמירה על אבטחה מאוחדת ותאימות לתקנות החברה.
זו דוגמה לתרחיש שימוש במערכת AI אקטיבי עם ריבוי דיירים.
שירות לקוחות בכל הארגון
אתם יכולים להתאים את ארכיטקטורת ההפניה הזו כדי לספק שירות לקוחות מבוסס-AI בכל המחלקות העסקיות השונות. לדוגמה, כדי לתמוך בחטיבת מוצרי אלקטרוניקה ובחטיבת מוצרים לבית, פורסים סוכן אלקטרוניקה וסוכן מוצרים לבית כשני סוכנים נפרדים בפרויקטים נפרדים של דיירים. סוכני ה-AI המיוחדים האלה פועלים כעוזרים חכמים שמטפלים בפניות תמיכה ספציפיות לחטיבה, על ידי גישה למפרטים טכניים ייחודיים, לאחריות או למדיניות החזרת מוצרים. האוטומציה הזו מאפשרת לצוותי התמיכה האנושית להתמקד בהעברות מורכבות יותר של לקוחות לטיפול ברמה גבוהה יותר.
במקרה השימוש הזה, הארכיטקטורה מספקת את היתרונות הבאים:
- בידוד נתונים קפדני: העיצוב של ריבוי הדיירים מבטיח שהידע לתמיכה בכל חטיבה מבודד באופן קפדני. מדיניות PAB מספקת אמצעי הגנה שעוזרים לוודא שלסוכן עם זהות בדייר אחד לא תהיה גישה לנתונים בדייר אחר.
- ידע של סוכנים עם התמחויות שונות: כל סוכן נמצא בפרויקט דייר מבודד, ולכן הוא מאחזר הקשר רק ממאגר הנתונים הספציפי לחטיבה שלו. האחזור הממוקד הזה מבטיח רמת דיוק גבוהה ומונע מהסוכן לבלבל בין המדיניות של יחידות עסקיות שונות.
- צמצום הסיכון בין דומיינים: הארכיטקטורה עוזרת למנוע את הסיכון לחשיפת נתונים בין יחידות עסקיות. גם אם הזהות של סוכן נפרצה, הסוכן לא יכול לגשת למשאבים לא מורשים. Google Cloud
הארכיטקטורה הזו מתאימה במיוחד לארגונים גדולים בתחום הקמעונאות ולחברות שמנהלות כמה מותגים או יחידות עסקיות נפרדים, ונדרשת להן ריבונות נתונים מחמירה.
חלופות עיצוב
בקטע הזה מוצגות גישות עיצוב חלופיות שאפשר לשקול כשפורסים AI אקטיבי מרובה-דיירים ב- Google Cloud.
פריסת גישה פרטית
בארכיטקטורה שמתוארת במסמך הזה, משתמשים ניגשים למערכת AI אקטיבי עם כמה דיירים (multi-tenant) דרך האינטרנט הציבורי באמצעות מאזן עומסים חיצוני של אפליקציות (ALB) שחשוף באופן מרכזי. אם הארגון שלכם דורש מערכת שלא ניתן לגשת אליה מהאינטרנט הציבורי, אתם יכולים להתאים את הארכיטקטורה כך שתשתמש באחת מאסטרטגיות הגישה הפרטית הבאות.
חסימת תעבורה באמצעות מדיניות אבטחה של Edge
כדי לאפשר תנועה רק מכתובות ה-IP הארגוניות המאומתות שלכם, אתם יכולים להגדיר מדיניות אבטחה ב-Cloud Armor שתדחה כל תנועה אחרת. כלל האבטחה הזה, שמוגדר בעדיפות גבוהה, חוסם את כל הבקשות הלא מורשות בקצה הרשת. כדי להוסיף שכבת אבטחה נוספת, אפשר להשתמש ב-IAP כדי לדרוש הפעלה של סשן תקף של זהות ארגונית, ולקבוע הרשאות IAM לכל המשתמשים.
הגישה הזו מאפשרת לכם לנצל את מדיניות האבטחה של Cloud Armor edge כדי להעביר את ההגנה מפני מתקפות DDoS ואת הסינון של WAF, כמו SQLi ו-XSS, והיא מספקת חוויה של אפס אמון. עם זאת, כתובת ה-IP של הקצה הקדמי של מאזן העומסים החיצוני של אפליקציות (ALB) נשארת ציבורית, ויכול להיות שהיא לא תעמוד בדרישות התאימות של ארגונים מסוימים.
ניתוב תנועה דרך מאזן עומסים פנימי של אפליקציות (ALB)
הארכיטקטורה שמתוארת במסמך הזה משתמשת במאזן עומסים חיצוני של אפליקציות (ALB), שמספק מדיניות חזקה של Cloud Armor, תכונות אבטחה מתקדמות יותר ומורכבות תפעולית נמוכה יותר בהשוואה למאזני עומסים פנימיים. עם זאת, השימוש במאזן עומסים חיצוני אומר שהתעבורה עוברת דרך האינטרנט הציבורי.
כדי שהתנועה תישאר כולה בתוך הרשת הפרטית של Google, אפשר להשתמש במאזן עומסים פנימי של אפליקציות (ALB). השימוש במאזן עומסים פנימי של אפליקציות (ALB) תומך ב-IAP לצורך אימות זהות. מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) מעריך את מדיניות IAP בשכבת הקצה. לעומת זאת, מאזן עומסים של אפליקציות (ALB) פנימי מעריך את המדיניות בשכבת הרשת הפנימית. מכיוון שתעבורת הנתונים לעולם אינה עוברת באינטרנט הציבורי, השימוש במאזן עומסים פנימי של אפליקציות (ALB) עוזר לכם לעמוד בדרישות מחמירות של ריבונות הנתונים ושל כתובות IP ציבוריות אפס.
כדי לשמור על זמן אחזור נמוך ולעמוד בדרישות אזוריות בנוגע למיקום הנתונים, כדאי לפרוס מאזן עומסים פנימי אזורי של אפליקציות בכל אזור ראשי. באמצעות מאזן עומסים פנימי אזורי של אפליקציות (ALB), אפשר לנתב תעבורת נתונים מסביבות מקומיות דרך Cloud Interconnect או דרך Cloud VPN ישירות לכתובת ה-IP הפנימית של מאזן העומסים. מאזן עומסים פנימי אזורי של אפליקציות (ALB) תומך ב-Cloud Armor אזורי להגנה פנימית של WAF. עם זאת, בהשוואה למאזן עומסים חיצוני של אפליקציות (ALB), מאזני עומסים פנימיים אזוריים של אפליקציות תומכים בקבוצה מוגבלת של מדיניות אבטחה של Cloud Armor, חסרות להם תכונות אבטחה מתקדמות והם מגבירים את המורכבות התפעולית.
כדי לצמצם עוד יותר את זמן האחזור ולעזור להבטיח זמינות גבוהה שתעמוד בדרישות שלכם לתוכנית התאוששות מאסון (DR), אתם יכולים לפרוס מאזן עומסים פנימי של אפליקציות (ALB) בין אזורים. כשמשתמשים במאזן עומסים פנימי של אפליקציות (ALB) בין אזורים, משתמשים ב-Cloud DNS עם מדיניות של ניתוב לפי מיקום גיאוגרפי כדי לתרגם את כתובת ה-URL הפנימית של האפליקציה למאזן העומסים הפנימי של האפליקציות בין אזורים בGoogle Cloud אזור שהכי קרוב למשתמש. עם זאת, הגדרה חוצת-אזורים לא תומכת בשילוב עם Cloud Armor.
תשתית מחשוב
כדי לתת עדיפות לגישה שמתמקדת בפתרונות ללא שרתים, שמספקת ניהול קל יותר ותקורה תפעולית נמוכה יותר, הארכיטקטורה במסמך הזה משתמשת ב-Cloud Run לתשתית המחשוב שלה. אפשר גם להפעיל אפליקציות בקונטיינרים באשכולות GKE. Google Kubernetes Engine (GKE) הוא מנוע לניהול קונטיינרים שמבצע אוטומטית את הפריסה, ההרחבה והניהול של אפליקציות בקונטיינרים. GKE תומך באופן מלא במאזני עומסים פנימיים וחיצוניים של אפליקציות (ALB). מידע על בחירת שירות מחשוב לעומסי עבודה ב- Google Cloudזמין במאמר אירוח אפליקציות ב-Google Cloud.
שרתים של Model Context Protocol (MCP)
כדי לאפשר לרכיבים של המערכת האגנטית שלכם ליצור אינטראקציה, אתם צריכים להגדיר פרוטוקולי תקשורת ברורים. MCP הוא פרוטוקול פתוח שמספק ממשק סטנדרטי לסוכנים כדי לגשת לכלים, לנתונים ולשירותים אחרים שנדרשים להם ולהשתמש בהם.
כדי לחבר את הסוכנים של הדייר למאגר הנתונים, צריך לבחור מבין אפשרויות הפריסה הבאות של שרת ה-MCP בהתאם לדרישות האפליקציה. כשבוחרים בין פריסות מקומיות לבין פריסות משותפות של MCP, חשוב לשקול את היתרונות והחסרונות של בידוד הנתונים לעומת יעילות תפעולית.
שרת MCP מקומי: שרת MCP מקומי, או שרת MCP ספציפי לדייר, הוא שרת MCP שאתם פורסים בכל פרויקט דייר, ומספק לסוכנים גישה למאגרי נתונים ולכלים שספציפיים ליחידה העסקית הזו.
התכונות העיקריות של שרתי MCP מקומיים והדברים שחשוב לדעת עליהם:
- רשת: גבולות גזרה של VPC Service Controls ברמת הפרויקט ומדיניות לקביעת PAB מספקים אבטחה ובידוד מובנים, שעוזרים לוודא שאין גישה בין דיירים.
- ניהול: צוותי פיתוח ותפעול ספציפיים מנהלים את הפרויקטים של הדיירים באופן עצמאי. הבידוד הזה מאפשר לכל יחידה עסקית לפעול באופן עצמאי.
- אבטחה: גבולות ה-IAM הקבועים של פרויקט הדייר עוזרים לצמצם את הסיכון לפרצות אבטחה, והם לא דורשים מיפויים מורכבים של זהויות.
שרתי MCP מקומיים מציעים בידוד מקסימלי ויכולים לטפל בגישה לנתונים רגישים מאוד או לנתונים שחלים עליהם תקנות. עם זאת, אם פורסים כמה שרתי MCP מקומיים, עומס התפעול גדל. מומלץ להשתמש בשרתי MCP מקומיים באפליקציות שנדרשת בהן גישה מוגבלת למאגרי נתונים שעשויים להכיל מידע רגיש.
שרת MCP משותף: שרת MCP משותף, או שרת MCP גלובלי, הוא שרת MCP שאתם פורסים בפרויקט שירותים משותפים. שרתי MCP משותפים מספקים גישה לכלים ולמערכות שמשותפים לכמה דיירים.
אלה התכונות העיקריות ושיקולים חשובים לגבי שרתי MCP משותפים:
- רשת: כדי לוודא שהתנועה לא עוברת דרך האינטרנט הציבורי, שרתי MCP משותפים צריכים קישוריות פרטית, כמו Private Service Connect או VPC Network Peering.
- ניהול: צוות תפעול מרכזי מנהל את ההטמעה של כל המערכת. הניהול המאוחד הזה מייעל את היעילות התפעולית ומבטל את הצורך לשכפל הטמעות מקומיות בכמה דיירים.
- אבטחה: הזהות של משתמש הקצה מועברת בצורה מאובטחת מהסוכן בפרויקט הדייר לשרת ה-MCP המשותף. כדי לוודא שהמשתמשים יכולים לגשת רק לנתונים שהם מורשים לגשת אליהם או לשנות אותם, שרת ה-MCP המשותף משתמש בזהות המשתמש שהועברה כדי לאכוף בקרת גישה מדויקת במערכת העורפית.
שרתי MCP משותפים מרכזים את הניהול של כלים נפוצים, וכך מצמצמים את הכפילויות ומשפרים את היעילות התפעולית. למרות ששרתי MCP משותפים מצמצמים את התקורה של הניהול, הם דורשים הפצה חזקה של זהויות ולוגיקה של הרשאות כדי לשמור על גישה מאובטחת. אנחנו ממליצים על שרתי MCP משותפים לאינטראקציות עם מערכות וכלים ארגוניים נפוצים, כמו כלים לדיווח על הוצאות, מערכות משאבי אנוש (HR), מאגרי ידע ארגוניים או מערכות לניהול נוכחות.
באדריכלות הזו, אתם משתמשים בשרתי MCP כדי לתקנן את החיבור בין הסוכנים בדייר לבין מאגרי הנתונים. בהתאם לדרישות של עומס העבודה, יכול להיות שתשתמשו בסוגים אחרים של כלים לסוכנים כדי לחבר את הסוכנים לממשקי API ולמערכות חיצוניות ספציפיים. מידע נוסף על אינטראקציות עם כלי סוכן זמין במאמר כלי סוכן.
שיקולים בתכנון
בקטעים הבאים מתוארים גורמים שצריך לקחת בחשבון בתכנון, שיטות מומלצות והמלצות לשימוש בארכיטקטורת ההפניה הזו כדי לפתח טופולוגיה שעונה על הדרישות הספציפיות שלכם בנוגע לאבטחה, למהימנות, לעלות ולביצועים. ההנחיות שבקטע הזה הן לא רשימה מלאה. בהתאם לדרישות של עומס העבודה ולמוצרים ולתכונות שבהם אתם משתמשים, יכול להיות שיש עוד גורמים שצריך לקחת בחשבון כשמתכננים את הארכיטקטורה.
אבטחה, פרטיות ותאימות
בקטע הזה מפורטים שיקולים והמלצות לתכנון טופולוגיה ב- Google Cloud שעומדת בדרישות האבטחה, הפרטיות והתאימות של עומס העבודה.
| רכיב | שיקולים והמלצות לגבי עיצוב |
|---|---|
| ענן וירטואלי פרטי (VPC) | בידוד דיירים: בארכיטקטורה הזו, אתם פורסים כל דייר ב Google Cloud פרויקט ייעודי. כדי ליצור גבול אבטחה מחמיר, משלבים בידוד ברמת הפרויקט של הדייר עם מדיניות PAB ו-VPC Service Controls ברמת הארגון. |
| IAM | בקרת גישה: כדי ליישם את העיקרון של הרשאות מינימליות, כדאי להשתמש במודל גישה שמבוסס על פרסונה. לדוגמה, אתם יכולים להגדיר תפקידי IAM בהתאמה אישית כדי להבטיח שמפתח שבונה סוכן בדייר אחד לא יוכל לגשת לנתונים בדייר אחר. |
| Cloud Armor |
הגנה על WAF בקצה הרשת ובתוך הרשת: Cloud Armor מספק אבטחה והגנה על WAF כדי להגן על פורטל הקצה הקדמי מפני התקפות DDoS ונקודות חולשה באינטרנט. מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) תומך בחבילה המלאה של תכונות Edge מתקדמות, כמו ניהול בוטים והגנה אדפטיבית של Google Cloud Armor. אם פורסים מאזן עומסים אזורי פנימי של אפליקציות (ALB), Cloud Armor פועל עם קבוצה מוגבלת של מדיניות WAF רגילה. קבוצת המדיניות המוגבלת מותאמת לגבולות של רשתות פנימיות, והיא כוללת מדיניות כמו הגנה מפני SQLi ו-XSS. מידע נוסף זמין במאמר שילוב של Cloud Armor עם מוצרים אחרים של Google. |
| Agent Platform | נקודות קצה של מודל משותף: כדי למנוע שימוש לרעה ולהבטיח שימוש הוגן בנקודות קצה של מודל משותף, צריך להטמיע אחת מהאסטרטגיות הבאות:
|
| Cloud Run | עיבוד תוכן: כדי לשפר את רמת האבטחה של פורטל ה-Frontend, מומלץ לתת עדיפות לעיבוד בצד השרת (SSR) על פני עיבוד בצד הלקוח (CSR). בהשוואה ל-CSR, SSR מציע את היתרונות הבאים:
|
| Security Command Center | ניטור אבטחה מרכזי: כדי לנטר איומים ולאכוף מדיניות אבטחה כמו אימות רב-שלבי (MFA) והצפנת נתונים, אפשר להשתמש בכלים במרכז השליטה לאבטחה. |
עוד המלצות בנושא אבטחה
- Google Cloud Well-Architected Framework AI and ML perspective: Security
- הגישה של Google לסוכני AI מאובטחים: מבוא
אמינות
בקטע הזה מפורטים שיקולים והמלצות לתכנון ולתפעול של תשתית אמינה לפריסה ב- Google Cloud.
| רכיב | שיקולים והמלצות לגבי עיצוב |
|---|---|
| Cloud Load Balancing | ניתוב גלובלי: מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) מספק כתובת IP אחת מסוג Anycast שמנתבת אוטומטית את תעבורת הנתונים של המשתמשים לקצה של Google שנמצא הכי קרוב מבחינה גיאוגרפית. ההגדרה הזו מפחיתה את זמן האחזור באמצעות סיום שכבת שקע מאובטחת (SSL) בקצה הרשת. הוא גם מבטיח זמינות גבוהה אם מתרחש הפסקת חשמל באזור מסוים, כי הוא מנתב מחדש את התעבורה בצורה חכמה אל קצה עורפי אזורי תקין. |
| דייר (tenant) | סבילות לתקלות: כדי לסבול או לטפל בכשלים ברמת הסוכן, צריך לפרוס סוכנים בפרויקטים מבודדים של דיירים. הבידוד הזה עוזר לוודא שבעיות תפעוליות או אירועי אבטחה יישארו בגבולות של יחידה עסקית אחת ולא ישפיעו על משאבים או יחידות עסקיות אחרות. |
| Agent Platform | תכנון הקיבולת: אם מספר הבקשות למודל חורג מהקיבולת שהוקצתה, המודל מחזיר קוד שגיאה 429. עבור עומסי עבודה שחיוניים לעסק ודורשים תפוקה גבוהה באופן עקבי, ניתן להקצות תפוקה באמצעות הקצאת משאבים לפי התפוקה שנקבעה. |
| Agent Runtime |
יכולת הרחבה ללא שרת: סוכנים שנפרסים ב-Agent Runtime יכולים להתרחב באופן עצמאי בהתאם לביקוש. עלייה פתאומית בשימוש בדייר אחד לא תגרום למיצוי של משאבי המחשוב או תשפיע על הזמינות של סוכן בפרויקט דייר (tenant) אחר. טיפול בשגיאות: כדי לטפל בשגיאות זמניות כמו מגבלות קצב (rate limits) עם קוד השגיאה 429, לוגיקת תזמור הסוכנים משתמשת בהשהיה מעריכית לפני ניסיון חוזר. אם חלף הזמן שהוקצב להקשר, הסוכן מבצע כיבוי מסודר ומדווח למשתמש על התקדמות חלקית. לדוגמה, יכול להיות שחריגה מהזמן הקצוב להשלמת הקשר תתרחש בגלל קריאות איטיות לכלים, חביון של API מצד שלישי, עיבוד של מערכי נתונים גדולים או עיבוד שדורש הרבה משאבי מחשוב. |
עקרונות והמלצות בנושא מהימנות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Reliability (נקודת מבט על AI ו-ML: מהימנות) ב-Well-Architected Framework.
יעילות תפעולית
בקטע הזה מתוארים הגורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן טופולוגיה של Google Cloud שאפשר להפעיל ביעילות.
| רכיב | שיקולים והמלצות לגבי עיצוב |
|---|---|
| Google Cloud Observability | מעקב מרכזי: רישום ביומן ומעקב מאפשרים לעקוב אחרי התקינות והביצועים של הפלטפורמה כולה. אתם יכולים להגדיר התראות כדי לזהות ולפתור בעיות באופן יזום בלי לאפשר גישה למידע אישי רגיש. |
| כל המוצרים בארכיטקטורה | פריסות סטנדרטיות: שימוש ב-Agent Platform במסגרת תבנית ארכיטקטורה סטנדרטית של דייר מאפשר ליצור בסיס עקבי כשמצטרפים דיירים חדשים. כדי להפחית את העומס התפעולי, כדאי להפוך את תהליך הפריסה לאוטומטי באמצעות כלים של תשתית כקוד (IaC) כמו Terraform. קוד Terraform שאפשר להשתמש בו כדי ליצור ולפרוס מערכת AI אקטיבי מרובת דיירים, זמין בקטע פריסה במסמך הזה. |
עקרונות והמלצות ספציפיים למשימות שקשורות ל-AI ול-ML מפורטים במאמר AI and ML perspective: Operational excellence ב-Well-Architected Framework.
הוזלת עלויות
בקטע הזה מוסבר איך לבצע אופטימיזציה של העלות של הגדרת טופולוגיה של Google Cloud והפעלתה, שאתם בונים באמצעות ארכיטקטורת ההפניה הזו.
| רכיב | שיקולים והמלצות לגבי עיצוב |
|---|---|
| Agent Platform |
צריכת טוקנים: כדי לנהל את העלויות ולמנוע ממודל ה-AI לחרוג מחלונות ההקשר, אפשר להשתמש באסטרטגיות הבאות לניהול ההקשר של מודל ה-AI:
נקודות קצה של מודלים: כדי לנהל את מכסות ה-API ואת ניצול המשאבים, אפשר לפרוס נקודות קצה של Agent Platform בהגדרה ייעודית או בהגדרה משותפת:
מידע על העלויות ב-Agent Platform זמין במאמר עלויות של בנייה ופריסה של מודלים של AI ב-Agent Platform. |
| Cloud Run | הוספת מכשור: הוספת מכשור מאפשרת לכם לעקוב אחרי הביצועים, לפתור בעיות ולעקוב אחרי השימוש במשאבים בכל דייר. כדי לזהות את הדייר לכל בקשה, צריך לחלץ את זהות המשתמש מההקשר ש-IAP מספק. מידע על הטמעה של אפליקציה זמין במאמר בנושא בחירת שיטת הטמעה. |
| הגנה מוגברת על המודל | סינון ריכוזי של הנחיות: כדי לאכוף ניהול קפדני ולשמור על גישה של אפס אמון, הארכיטקטורה הזו פורסת את הגנה מוגברת על המודל בשתי שכבות: במרכז הניתוב ובכל פרויקט דייר (tenant). הגישה הזו בשתי שכבות עוזרת להבטיח את ריבונות הנתונים, אבל היא מגדילה את זמן האחזור ואת עלויות התפעול. כדי לצמצם את העלויות ואת מורכבות המערכת, אפשר לסנן את כל ההנחיות והתשובות באמצעות פריסת הגנה מוגברת על המודל באופן בלעדי במרכז הניתוב. |
| כל המוצרים בארכיטקטורה |
תשתית משותפת: רכיבי תשתית ליבה משותפים, כמו פורטל חזיתי, מרכז בקרה מרכזי לניהול ולאבטחה ו-Agent Platform, יכולים להוזיל עלויות בהשוואה למצב שבו יוצרים מחסנית נפרדת בהתאמה אישית לכל סוכן. תקורה של הפלטפורמה: כדי לחלק את העלויות המשותפות של מרכז הבקרה המרכזי לניהול ולאבטחה, צריך להשתמש במודל הקצאה שמתאים ליכולות המעקב ולדפוסי השימוש שלכם. מומלץ להשתמש באחד ממודלים הקצאת העלויות הבאים:
מידע נוסף על הקצאת עלויות של שירותים משותפים זמין במאמר Cloud FinOps: הקצאת עלויות של שירותים משותפים. ניהול עלויות ריכוזי: כדי לעקוב בצורה מדויקה אחרי עלות הבעלות הכוללת (TCO) על מערכת ה-AI האקטיבי שלכם, ולשייך עלויות ליחידות עסקיות ספציפיות, אתם יכולים להשתמש בתוויות ובנתונים שמיוצאים מחיוב ב-Cloud. מידע נוסף על שימוש בתוויות כדי להעלות את רמת המודעות לעלויות זמין במאמר טיפוח תרבות של מודעות לעלויות. |
כדי להעריך את העלות של המשאבים ב- Google Cloud , אתם יכולים להשתמש בGoogle Cloud מחשבון עלויות.
עקרונות והמלצות לאופטימיזציה של עלויות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Cost optimization ב-Well-Architected Framework.
פריסה
כדי לפרוס את ארכיטקטורת העזר הזו, אפשר להשתמש בדוגמה של Terraform AI אקטיבי מרובה דיירים שזמינה ב-GitHub.
המאמרים הבאים
- מידע נוסף על יצירת סוכן באמצעות ADK ו-Agents CLI ב-Agent Platform
- איך משתמשים בשרת MCP מרוחק של Agent Platform
- שיטות מומלצות להפעלת VPC Service Controls
- איך מנהלים סוכנים שנפרסו ב-Agent Runtime
- שיטות מומלצות להרחבת הפעילות ולניהול נפח תנועה גבוה
- כדי להטמיע אסטרטגיות של העלאת הרשאות בדיוק בזמן, כדאי ללמוד איך להשתמש ב-Privileged Access Manager.
- סקירה כללית של עקרונות והמלצות בנושא ארכיטקטורה שספציפיים לעומסי עבודה של AI ו-ML ב- Google Cloudמופיעה בפרספקטיבה של AI ו-ML ב-Well-Architected Framework.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- Shivank Awasthi | Field Solutions Architect
- Utkarsh Bhardwaj | Technical Solutions Consultant, Agentic AI, Apps, Cloud Platforms, and Infrastructure
תורמי תוכן אחרים:
- Adrian Corona | Manager, Global Services Delivery, Security
- Agnieszka Kołkiewicz | GSD AI Manager
- אמול סאצ'דבה | מהנדס פתרונות פרסום, Global Business
- אשיש אגרוול (Ashish Agarwal) | מנהל אזור צפון אירופה, המזרח התיכון ואפריקה, אספקת שירותים גלובלית
- Ashmita Kapoor | JAPAC GenAI FSA, and Applied AI CE Manager
- אשוּטוֹש גופטה | מנהל, אספקת שירותים גלובלית
- Aspen Sherrill | Cloud Security Architect
- Chinmay Deshpande | Cloud Migration Consultant, Infrastructure
- Gaurav Taneja | EMEA South Infra, Data, AI, and GDC Delivery Lead
- אישמיט מהטה | מומחה לפלטפורמות בצפון אמריקה, Apps CE
- Joanna Nowek | AI Transformation Consultant
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- מארק שלגנהוף | כותב טכני, רשתות
- מתיאס צינר | מנהל, אספקת שירותים גלובלית
- Olu Akinrolabu | Security Cloud Consultant
- Paweł Tokarski | EMEA South Infra, Data, AI, and GDC Delivery Lead
- Paweł Glica | Core EMEA Practise Lead
- Prabha Arya | Strategic Cloud Engineer
- Samantha He | Technical Writer
- Suchit Puri | Global AI Practice Lead
- תומאס קלייט | מנהל ב-delta AI
- ולנטין הוארטה | מהנדס AI