מערכת AI אקטיבי עם ריבוי דיירים

Last reviewed 2026-10-16 UTC

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

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

בקטע פריסה במסמך הזה מפורטת אסטרטגיית הטמעה שתעזור לכם ליצור ולפרוס מערכת AI אקטיבית עם כמה דיירים.

ארכיטקטורה

בתרשים הבא מוצגת ארכיטקטורה של מערכת AI אקטיבי עם כמה דיירים, שמבוססת על מודל Hub-and-Spoke. מודל Hub-and-Spoke הוא עיצוב רשת שבו סביבה מרכזית, שנקראת Hub, מתחברת לכמה סביבות מבודדות, שנקראות Spokes.

ארכיטקטורה של מערכת AI אקטיבי עם כמה דיירים.

הארכיטקטורה מורכבת מהרכיבים הבאים:

VPC Service Controls
הארכיטקטורה משתמשת ב-VPC Service Controls כדי להגדיר גבולות גזרה לשירות ברמת הארגון. גבולות הגזרה לשירות מספקים גבול אבטחה מחמיר ועוזרים למנוע זליגת מידע.
מרכז הניתוב

רכזת הניתוב משמשת כנקודת הכניסה המרכזית לארכיטקטורה, והיא כוללת את הרכיבים הבאים:

מרכז אבטחה ומשילות מרכזי

מרכז הבקרה והאבטחה הוא פרויקט ייעודי ב- Google Cloudשמספק ניהול זהויות והרשאות גישה (IAM), רישום ביומן, מעקב ואבטחה לכל הפלטפורמה. הרכזת הזו כוללת את הרכיבים הבאים:

  • ‫Security Command Center: שירות שעוקב אחרי כל מערכת ה-AI האקטיבי עם ריבוי דיירים כדי לזהות סיכוני אבטחה.
  • IAM: מסגרת לבקרת גישה שמנהלת את הזהויות וההרשאות במרכזים המשותפים ובפרויקטים של הדיירים. הרכיב הזה מספק ניהול מרכזי של כל הזהויות של בני אדם ומכונות.
  • ‫Cloud Logging: מערכת שאוספת את היומנים מהרכזות המשותפות ומפרויקטי הדיירים המבודדים, ומעבירה אותם למרכז הבקרה והאבטחה המרכזי.
פרויקטים של דיירים (tenants)

כל פרויקט של דייר הוא פרויקט Google Cloud ייעודי לכל יחידה עסקית. פרויקטים נפרדים של דיירים הם סביבות מבודדות שכוללות את הרכיבים הבאים:

  • מדיניות לקביעת PAB: מדיניות לקביעת PAB מספקת בידוד פנימי קשיח בין יחידות עסקיות שונות, ועוזרת לוודא שישויות מורשות יכולות לגשת רק למשאבים שנמצאים בגבולות שאושרו להן.
  • ‫Agent Runtime ב-Gemini Enterprise Agent Platform: סביבת זמן ריצה שמארחת את הסוכן של היחידה העסקית הספציפית ומריצה קוד תזמור בהתאמה אישית שאתם יוצרים באמצעות הערכה לפיתוח סוכנים (ADK).
  • Model Armor: שירות אבטחה מנוהל שבודק ומסנן הנחיות ותשובות זדוניות. הוא מגן על הנציג ועל משאבי המחשוב של הדייר מפני איומים כמו מתקפות של החדרת הנחיות.
  • שרתי Model Context Protocol (MCP): שרתי MCP מאפשרים גישה בין הסוכן של הדייר לבין מאגר הנתונים של הדייר.
  • מאגר נתונים של דייר: מאגר נתונים ייעודי, כמו BigQuery או AlloyDB ל-PostgreSQL, שבו מאוחסנים נתונים ספציפיים של היחידה העסקית. הסוכן מבצע יצירה משולבת-אחזור (RAG) כדי ליצור תשובות מדויקות יותר על סמך ההקשר במאגר הנתונים. כדי לשמור על ריבונות נתונים קפדנית, רק לסוכני הדייר יש גישה לנתונים האלה.
  • מודלים של Gemini: כדי להציג את ההסקה, הסוכנים בארכיטקטורה לדוגמה משתמשים במודל Gemini העדכני ב-Gemini Enterprise Agent Platform.

תהליך עבודה של סוכן

התהליך במערכת לדוגמה עם מספר דיירים בארכיטקטורה הקודמת הוא:

  1. בקשה של משתמש מנותבת דרך מאזן עומסים חיצוני של אפליקציות (ALB). במרכז הניתוב, הבדיקות הבאות מתבצעות כדי לוודא שרק תנועה מאומתת ובטוחה מגיעה לפורטל החזיתי:
    1. ‫Cloud Armor מחיל מדיניות אבטחה כדי לספוג מתקפות מניעת שירות מבוזרות (DDoS) ראשוניות שמבוססות על פרוטוקול רשת בשכבה 4. ‫Cloud Armor בודק את הבקשה ומסנן תנועה זדונית, כמו הזרקת SQL‏ (SQLi), פרצת אבטחה XSS‏ (cross-site scripting) וחתימות בוטים מוכרות.
    2. ‫Model Armor מיירט את המטען הייעודי (payload) כדי לזהות ולדחות התקפות של החדרת פרומפטים או כוונות זדוניות.
    3. אם אחת מהשכבות האלה מזהה איום או גישה לא מורשית, מאזן העומסים מבטל את הבקשה בקצה הרשת.
    4. אם שכבות האבטחה לא מזהות איום ומאמתות את הגישה של המשתמש, מאזן העומסים מנתב את התנועה לשירות לקצה העורפי.
  2. אם הבקשה עוברת את כל הבדיקות, מאזן העומסים מנתב את הבקשה לפלטפורמת החזית, שמבצעת את הפעולות הבאות:
    1. מחלץ את הזהות של המשתמש, כמו היחידה העסקית או מזהה הדייר (tenant) של המשתמש.
    2. משתמש ב-IAP כדי לאמת את הזהות הארגונית של המשתמש ואת תקינות המכשיר.
    3. משתמש במרשם שמנוהל באופן דינמי כדי לזהות את דייר היעד הנכון.
  3. הפורטל של ממשק המשתמש מנתב את הבקשה לדייר. כדי לוודא שהסוכן לא יוכל לגשת לפרויקטים אחרים של דיירים או לשירותי Google Cloudלא מורשים, Agent Runtime משתמש במדיניות לקביעת PAB כדי להגביל את המשאבים שהסוכן יכול לגשת אליהם.
  4. התכונה "הגנה מוגברת על המודל" משתמשת בSensitive Data Protection כדי לבדוק ולהסתיר באופן דינמי פרטים אישיים מזהים (PII) או תוכן מוגבל. כדי לוודא שהנציג מעבד רק נתונים בטוחים, Model Armor מבצע בדיקה נוספת של החדרת פרומפטים זדוניים מהבקשה.

  5. כדי ליצור תשובה, Gemini מבצע את המשימות הבאות:

    1. מבצע ניתוח ראשוני כדי להבין את כוונת המשתמש.
    2. אם Gemini מזהה שחסרות לו עובדות ספציפיות, הוא יוצר תוכנית לקריאה לכלי הנתונים הספציפיים של הדייר:
      1. כדי לבדוק אם למשתמש יש הרשאה לגשת למשאבי הנתונים, הנציג מאמת את זהות המשתמש ואת הקישורים לתפקידי IAM.
      2. כדי לאחזר הקשר, הנציג מבצע קריאת API לכלי דרך שרת ה-MCP למאגר הנתונים של הדייר.
      3. הסוכן יוצר תשובה מבוססת-קרקע על ידי שילוב הלוגיקה הפנימית שלו עם העובדות החדשות שאוחזרו, הספציפיות לדייר.

    אם Gemini לא צריך עובדות נוספות, הוא יוצר תשובה ושולח אותה ל-Model Armor.

  6. ‫Model Armor בודק ומסתיר באופן דינמי פרטים אישיים מזהים או תוכן מוגבל, ושולח את התשובה המטוהרת לסוכן של הדייר. הבדיקה הסופית הזו עוזרת לוודא שאין דליפה של מידע רגיש בפלט.

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

המוצרים שהשתמשו בהם

בארכיטקטורה לדוגמה הזו נעשה שימוש במוצרים ובכלים הבאים של Google Cloud ושל קוד פתוח, שנבחרו בגלל שהם פועלים בלי שרת (serverless), בגלל יכולת המדרגיות שלהם ובגלל אמצעי האבטחה שלהם:

  • ‫VPC Service Controls: פונקציונליות של רשת מנוהלת שמצמצמת את הסיכונים לזליגת נתונים מהמשאבים שלכם ב- Google Cloud .
  • ‫Cloud Load Balancing: מגוון של מאזני עומסים גלובליים ואזוריים, עם ביצועים גבוהים ויכולת התאמה לעומס.
  • ‫Google Cloud Armor: שירות אבטחת רשת שמציע כללים של חומת אש ליישומי אינטרנט (WAF) ועוזר להגן מפני מתקפות DDoS ומתקפות על אפליקציות.
  • ‫Model Armor: שירות שמגן על משאבי ה-AI הגנרטיבי וה-AI האקטיבי מפני החדרת פרומפטים, הדלפות של מידע אישי רגיש ותוכן פוגעני.
  • שרת proxy לאימות זהויות (IAP): שירות שמאפשר מודל גישה של אפס אמון לאפליקציות ולמכונות הווירטואליות.
  • ניהול זהויות והרשאות גישה (IAM): מערכת שמאפשרת ליצור ולנהל הרשאות למשאבים ב- Google Cloud .
  • ‫Cloud Run: פלטפורמת מחשוב בלי שרת (serverless computing) שמאפשרת להריץ קונטיינרים ישירות בתשתית של Google, שניתנת להתאמה לעומס.
  • ‫Gemini Enterprise Agent Platform: פלטפורמה מקיפה שמאפשרת לפתח, להרחיב, לנהל ולשפר סוכני AI ברמה שמתאימה לארגונים.
  • ‫Gemini: משפחה של מודלי AI מולטי-מודאליים שפותחו על ידי Google.
  • ‫Model Context Protocol‏ (MCP): תקן קוד פתוח לחיבור אפליקציות AI למערכות חיצוניות.
  • ‫Cloud Logging: מערכת לניהול יומנים בזמן אמת עם אחסון, חיפוש, ניתוח והתראות.

תרחיש לדוגמה

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

הנה דוגמה לתרחיש לדוגמה של מערכת AI אקטיבי עם כמה דיירים.

שירות לקוחות ברמת הארגון

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

במקרה הזה, הארכיטקטורה מספקת את היתרונות הבאים:

  • בידוד נתונים קפדני: העיצוב של ריבוי דיירים בענן עוזר להבטיח שמאגר הידע של התמיכה בכל מחלקה מבודד לחלוטין. מדיניות לקביעת PAB מספקת אמצעי הגנה שעוזרים לוודא שזהות של סוכן בדייר (tenant) אחד לא יכולה לגשת לנתונים בדייר (tenant) אחר.
  • ידע של סוכן מומחה: כל סוכן נמצא בפרויקט נפרד של דייר, ולכן הוא מאחזר הקשר רק ממאגר הנתונים הספציפי של המחלקה שלו. האחזור הממוקד הזה עוזר לשפר את הדיוק ומונע מהנציג לבלבל בין כללי המדיניות של יחידות עסקיות שונות.
  • סיכון מופחת בין דומיינים: הארכיטקטורה עוזרת למנוע את הסיכון לחשיפת נתונים בין יחידות עסקיות. גם אם זהות הסוכן נחשפת, הסוכן לא יכול לגשת למשאבי Google Cloud לא מורשים.

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

חלופות לעיצוב

בקטע הזה מוצגות גישות עיצוב חלופיות שאפשר לשקול לפריסה של AI אקטיבי עם כמה דיירים ב- Google Cloud.

פריסת גישה פרטית

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

חסימת תנועה באמצעות מדיניות אבטחה בקצה הרשת

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

הגישה הזו מאפשרת לכם להשתמש בכללי מדיניות האבטחה של Cloud Armor בקצה הרשת כדי להעביר את צמצום ההשפעה של DDoS ואת הסינון של WAF, כמו SQLi ו-XSS, ומספקת חוויית אפס אמון. עם זאת, כתובת ה-IP של ממשק הקצה של מאזן העומסים החיצוני של האפליקציות נשארת ציבורית, ויכול להיות שהיא לא תעמוד בדרישות התאימות של חלק מהארגונים.

ניתוב תנועה דרך מאזן עומסים פנימי של אפליקציות (ALB)

הארכיטקטורה במסמך הזה משתמשת במאזן עומסים חיצוני של אפליקציות (ALB), שמספק כללי מדיניות חזקים של Cloud Armor, אמצעי אבטחה מתקדמים יותר ומורכבות תפעולית נמוכה יותר בהשוואה למאזני עומסים פנימיים. עם זאת, השימוש במאזן עומסים חיצוני פירושו שתעבורת הנתונים עוברת דרך האינטרנט הציבורי.

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

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

כדי לצמצם עוד יותר את זמן האחזור ולהבטיח זמינות גבוהה שתעמוד בדרישות של תוכנית ההתאוששות מאסון, אתם יכולים לפרוס מאזן עומסים פנימי של אפליקציות (ALB) באזורים שונים. במאזן עומסים פנימי של אפליקציות (ALB) בכמה אזורים, משתמשים ב-Cloud DNS עם מדיניות ניתוב לפי מיקום גיאוגרפי כדי לפתור את כתובת ה-URL הפנימית של האפליקציה למאזן העומסים הפנימי של אפליקציות (ALB) בכמה אזורים, בGoogle Cloud אזור שהכי קרוב למשתמש. עם זאת, הגדרה חוצת-אזורים לא תומכת בשילוב של Cloud Armor.

תשתית המחשוב

כדי לתת עדיפות לגישה שמתמקדת ב-serverless, שמאפשרת ניהול קל יותר ועלויות תפעול נמוכות יותר, הארכיטקטורה במסמך הזה משתמשת ב-Cloud Run כתשתית המחשוב שלה. אתם יכולים גם להריץ אפליקציות בקונטיינרים באשכולות GKE. ‫Google Kubernetes Engine‏ (GKE) הוא מנוע לתזמור קונטיינרים, שמאפשר לבצע באופן אוטומטי את הפריסה, ההתאמה לעומס והניהול של אפליקציות בקונטיינרים. ‫GKE תומך באופן מלא במאזני עומסים פנימיים וחיצוניים של אפליקציות (ALB). במאמר אירוח אפליקציות ב-Google Cloud מוסבר איך לבחור שירות מחשוב לעומסי העבודה ב- Google Cloud.

שרתי 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 שכנות (peering).
    • ניהול: צוות תפעול מרכזי מנהל את ההטמעה של המערכת כולה. הניהול המאוחד הזה משפר את היעילות התפעולית ומבטל את הצורך לשכפל הטמעות מקומיות בכמה דיירים.
    • אבטחה: אתם מעבירים בצורה מאובטחת את זהות משתמש הקצה מהנציג בפרויקט של הדייר לשרת ה-MCP המשותף. כדי לוודא שהמשתמשים יכולים לגשת רק לנתונים שמותר להם ולשנות רק אותם, שרת ה-MCP המשותף משתמש בזהות המשתמש המופצת כדי לאכוף בקרת גישה מפורטת במערכת לקצה העורפי.

    שרתי MCP משותפים מרכזים את הניהול של כלים נפוצים, וכך מצמצמים את הכפילויות ומשפרים את היעילות התפעולית. למרות ששרתי MCP משותפים מפחיתים את עלויות הניהול, הם דורשים לוגיקה חזקה של הפצת זהויות והרשאות כדי לשמור על גישה מאובטחת. אנחנו ממליצים על שרתי MCP משותפים לאינטראקציות עם מערכות וכלים ארגוניים נפוצים, כמו כלים לדיווח על הוצאות, מערכות משאבי אנוש (HR), מאגרי ידע כלל-ארגוניים או מנהלי נוכחות.

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

שיקולים שקשורים לעיצוב

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

אבטחה, פרטיות ותאימות

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

שיקולי אבטחה לסוכנים

סוכני AI מציגים סיכוני אבטחה ייחודיים וקריטיים, ששיטות אבטחה דטרמיניסטיות רגילות לא תמיד יכולות לצמצם בצורה מספקת. ‫Google ממליצה על גישה לאבטחת סוכני AI שמשלבת את היתרונות של אמצעי אבטחה דטרמיניסטיים עם הגנות דינמיות שמבוססות על הסקת מסקנות. הגישה הזו מבוססת על שלושה עקרונות ליבה: פיקוח אנושי, הגדרה קפדנית של האוטונומיה של הנציג ויכולת תצפית. ההמלצות הספציפיות הבאות תואמות לעקרונות הליבה האלה:

  • פיקוח אנושי: לפעמים מערכת AI אקטיבי עלולה להיכשל או לא לפעול כמו שצריך. לדוגמה, המודל עלול ליצור תוכן לא מדויק או שהסוכן עלול לבחור כלים לא מתאימים. במערכות AI אקטיביות שקריטיות לעסק, כדאי לשלב תהליך עבודה שכולל את האדם שבתהליך כדי לאפשר למפקחים אנושיים לעקוב אחרי הסוכנים, לשנות את הפעולות שלהם ולהשהות אותם. לדוגמה, משתמשים אנושיים יכולים לבדוק את הפלט של הנציגים, לאשר או לדחות את הפלט ולספק הנחיות נוספות לתיקון שגיאות או לקבלת החלטות אסטרטגיות. הגישה הזו משלבת את היעילות של מערכות AI אקטיבי עם החשיבה הביקורתית והמומחיות בתחום של משתמשים אנושיים.
  • זהות הסוכן וגישה עם הרשאות מינימליות:
    • באמצעות Agent Identity, נותנים לכל סוכן זהות שמבוססת על SPIFFE וקשורה לעומס העבודה. אתם יכולים להשתמש ב-Agent Identity כשאתם פורסים סוכנים ב-Agent Runtime או ב-Cloud Run.
    • להגדיר הרשאות לכל נציג באמצעות כללי מדיניות הגישה של IAM ובקרת הגישה של Agent Platform באמצעות IAM. תנו לכל נציג רק את ההרשאות שהוא צריך כדי לבצע את המשימות שלו ולתקשר עם כלים ועם נציגים אחרים. כדי לבודד עוד יותר כל סוכן ולהגביל את ההשפעה הפוטנציאלית של פרצת אבטחה, צריך לקשר מדיניות לקביעת PAB לזהות הסוכן.
    • כשנציגים צריכים לבצע אימות בכלים חיצוניים או בממשקי API של צד שלישי, משתמשים במנהל האימות של Agent Identity. בגישה הזו, אתם יכולים לשלוט באופן מרכזי באסימוני OAuth ובמפתחות API, במקום להטמיע את פרטי הכניסה בקוד או בהנחיות של הנציג.

  • ניהול תעבורת הנתונים הנכנסת והיוצאת: אתם יכולים לנתב את תעבורת הנתונים של הנציג דרך Agent Gateway כדי לאכוף את מדיניות האבטחה בזמן הריצה גם בגבולות של תעבורת הנתונים הנכנסת וגם בגבולות של תעבורת הנתונים היוצאת. למידע על פלטפורמות Agent Runtime שתומכות ב-Agent Gateway, קראו את המאמר Agent Runtime נתמכים של סוכנים.

    • מלקוח לסוכן (תעבורת נתונים נכנסת): פורסים את Agent Gateway לפני Agent Runtime. השער עוזר לאמת את המתקשרים ולבדוק את ההנחיות הנכנסות בזמן אמת באמצעות הגנה מוגברת על המודל.

    • ‫Agent-to-Anywhere (egress):

      • לנתב בקשות יוצאות מסוכן לסוכן (A2A) ומסוכן לכלי (MCP) דרך Agent Gateway במצב תעבורת נתונים יוצאת.
      • אכיפה של כללי מדיניות גישה שמוגדרים כברירת מחדל לדחייה, באמצעות כללי מדיניות גישה של IAM ו-IAP.
      • מוודאים שהסוכנים והכלים הרלוונטיים רשומים ב-Agent Registry.
      • לבדוק את הקריאות והתשובות של כלים יוצאים באמצעות Model Armor כדי למנוע זליגת נתונים, החדרת פרומפטים עקיפה ושימוש לרעה בכלים.

  • מעקב: מעקב אחרי ההתנהגות של הנציג באמצעות יכולות מעקב מקיפות שנותנות לכם תצוגה של כל פעולה שהנציג מבצע, כולל תהליך החשיבה, בחירת הכלים ונתיבי הביצוע שלו. מידע נוסף זמין במאמרים רישום ביומן של נציג ב-Agent Runtime ורישום ביומן ב-ADK.

מידע נוסף על אבטחת סוכני AI זמין במאמר בטיחות ואבטחה של סוכני AI.

שיקולי אבטחה של ענן וירטואלי פרטי (VPC)

בארכיטקטורה הזו, פורסים כל דייר בGoogle Cloud פרויקט ייעודי. כדי ליצור גבול אבטחה קפדני, שלבו בידוד ברמת הפרויקט של הדייר עם מדיניות לקביעת PAB ו-VPC Service Controls ברמת הארגון.

שיקולי אבטחה ב-IAM

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

שיקולי אבטחה של Cloud Armor

‫Cloud Armor מספק אבטחה והגנה של WAF כדי להגן על פורטל החזית מפני התקפות DDoS ונקודות חולשה באינטרנט. מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) תומך בכל חבילת התכונות המתקדמות של הקצה, כמו ניהול בוטים והגנה מותאמת אישית של Google Cloud Armor.

אם פורסים מאזן עומסים פנימי אזורי של אפליקציות (ALB), ‏Cloud Armor פועל עם קבוצה מוגבלת של כללי מדיניות WAF סטנדרטיים. קבוצת כללי המדיניות המוגבלת מותאמת לגבולות הרשת הפנימית, והיא כוללת כללי מדיניות כמו הגנה מפני SQLi ו-XSS. מידע נוסף זמין במאמר שילוב של Cloud Armor עם מוצרים אחרים של Google.

שיקולי אבטחה ב-Agent Platform

כדי לוודא שההגדרות והשימוש ב-Agent Platform עומדים בדרישות האבטחה שלכם, כדאי לפעול לפי ההמלצות הבאות:

  • אחריות משותפת: האבטחה היא באחריות משותפת. פלטפורמת הסוכנים מאבטחת את התשתית הבסיסית ומספקת כלים ואמצעי בקרה לאבטחה שיעזרו לכם להגן על הנתונים, הקוד והמודלים שלכם. אתם אחראים להגדיר נכון את השירותים, לנהל את אמצעי בקרת הגישה ולאבטח את האפליקציות שלכם. מידע נוסף זמין במאמר אחריות משותפת ב-Agent Platform.
  • אמצעי בקרה לאבטחה: פלטפורמת Agent תומכת Google Cloud באמצעי בקרה לאבטחה שבהם אתם יכולים להשתמש כדי לעמוד בדרישות שלכם לגבי מיקום אחסון הנתונים, מפתחות הצפנה בניהול הלקוח (CMEK), אבטחת רשת באמצעות VPC Service Controls ו-Access Transparency. מידע נוסף זמין במשאבי העזרה הבאים:
  • בטיחות: מודלי AI עלולים ליצור תגובות מזיקות, לפעמים בתגובה לפרומפטים זדוניים.
    • כדי לשפר את הבטיחות ולמנוע שימוש לרעה במערכת ה-AI האקטיבי, אתם יכולים להגדיר מסנני תוכן שיחסמו קלט ותשובות שעלולים להזיק. מידע נוסף זמין במאמר מסנני בטיחות ותוכן.
    • כדי לבדוק בקשות להסקת מסקנות, הנחיות לסוכנים, קריאות לכלים ותשובות, ולהסיר מהן תוכן זדוני או רגיש כמו החדרת הנחיות ותוכן פוגעני, אתם יכולים להשתמש בהגנה מוגברת על המודל לקריאות ישירות ל-API של המודל וגם לבקשות שמועברות דרך Agent Gateway. הגנה מוגברת על המודל עוזרת למנוע קלט זדוני, לאמת את בטיחות התוכן, להגן על מידע אישי רגיש, לשמור על תאימות ולאכוף מדיניות בטיחות ואבטחה באופן עקבי.
  • גישה למודלים: אתם יכולים להגדיר כללי מדיניות בארגון כדי להגביל את הסוג והגרסאות של מודלי ה-AI שאפשר להשתמש בהם בפרויקט ב- Google Cloud . למידע נוסף, קראו את המאמר שליטה בגישה למודלים ב-Model Garden.
  • הגנה על נתונים: כדי לזהות ולהסיר פרטי זיהוי של מידע רגיש בהנחיות, בתשובות ובנתוני היומנים, אתם יכולים להשתמש ב-Cloud Data Loss Prevention API. למידע נוסף, צפו בסרטון הגנה על מידע אישי רגיש באפליקציות AI.

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

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

      1. מחלצים את זהות הדייר מההקשר של IAP.
      2. מעקב אחרי השימוש בהשוואה למגבלות שהוגדרו מראש לכל דייר, באמצעות מאגר חיצוני כמו Memorystore for Redis.
      3. לדחות בקשות מדיירים שחורגים מהמגבלות שלהם.

    • ‫API Gateway: כדי לאכוף מכסות לכל דייר באמצעות מפתחות API ותוכניות שימוש, מטמיעים את API Gateway לפני נקודת הקצה המשותפת.

שיקולי אבטחה של MCP

כדי לוודא שהטמעת ה-MCP עומדת בדרישות האבטחה, כדאי לפעול לפי ההמלצות הבאות:

  • רישום וגילוי של כלים: רישום שרתי MCP וכלים ב-Agent Registry כדי שהסוכנים יתחברו רק לנקודות קצה (endpoints) של MCP שנמצאות במלאי ומאושרות על ידי האדמין.
  • בקרת גישה ובדיקת תנועה: אפשר לנתב את התנועה מהסוכן ל-MCP דרך Agent Gateway במצב Agent-to-Anywhere (תנועה יוצאת), ולהגן על שרתי MCP (כמו שרתי MCP שמתארחים ב-Cloud Run) באמצעות IAP וכללי מדיניות גישה של IAM. הגדירו את "הגנה מוגברת על המודל" או את מדיניות הפיקוח בשפה טבעית ב-Agent Gateway כדי לבדוק את הקלט והפלט של כלי ה-MCP, וכך למנוע חשיפה של מידע רגיש והחדרת פרומפטים עקיפה.
  • אבטחה כללית של MCP: כשמגדירים את הנציגים להשתמש ב-MCP, חשוב לוודא שהגישה לנתונים ולכלים חיצוניים מאושרת, להטמיע אמצעי בקרה על פרטיות כמו הצפנה, להחיל מסננים כדי להגן על נתונים רגישים ולעקוב אחרי האינטראקציות של הנציגים. מידע נוסף זמין במאמר MCP ואבטחה.

שיקולי אבטחה ב-Cloud Run

כדי לשפר את מצב האבטחה של פורטל החזית, כדאי לתת עדיפות לעיבוד בצד השרת (SSR) על פני עיבוד בצד הלקוח (CSR). בהשוואה ל-CSR, ל-SSR יש את היתרונות הבאים:

  • מריץ את הלוגיקה של האפליקציה ומנהל את הסודות בסביבה מבוקרת שלGoogle Cloud .
  • מצמצם את שטח המתקפה בצד הלקוח ועוזר למנוע דליפות של נתונים רגישים לדפדפן הלא מהימן של המשתמש.
  • מגביל את חשיפת הנתונים על ידי שליחת ה-HTML הנדרש בלבד ללקוח.
  • מספק קידוד פלט מרכזי להגנה מפני מתקפות שמקורן בפרצת אבטחה XSS‏ (cross-site scripting).

שיקולי אבטחה ב-Security Command Center

כדי לעקוב אחרי איומים ולאכוף מדיניות אבטחה כמו אימות רב-שלבי (MFA) והצפנת נתונים, השתמשו בכלים של Security Command Center.

המלצות נוספות בנושא אבטחה

אמינות

בקטע הזה מתוארים שיקולים והמלצות לתכנון, לבנייה ולהפעלה של תשתית אמינה לפריסה ב- Google Cloud.

שיקולי אמינות ב-Cloud Load Balancing

מאזן עומסים חיצוני גלובלי של אפליקציות מספק כתובת IP אחת מסוג Anycast, שמנתבת באופן אוטומטי את תנועת המשתמשים לנקודת הקצה הגיאוגרפית הקרובה ביותר של Google. ההגדרה הזו מקצרת את זמן האחזור באמצעות סיום של שכבת שקע מאובטחת (פרוטוקול SSL) בקצה. בנוסף, הוא עוזר להבטיח זמינות גבוהה במקרה של הפסקה זמנית בשירות באזור מסוים, כי הוא מנתב מחדש באופן חכם את התנועה לקצוות עורפיים אזוריים תקינים.

שיקולי אמינות של דיירים

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

שיקולי אמינות ב-Agent Platform

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

שיקולי אמינות של Agent Runtime

כדי לוודא שההגדרות והשימוש ב-Agent Runtime עומדים בדרישות האמינות שלכם, כדאי לפעול לפי ההמלצות הבאות:

  • יכולת התאמה לעומס (scalability) בלי שרת (serverless): סוכנים שנפרסים ב-Agent Runtime משנים את קנה המידה שלהם באופן עצמאי בהתאם לדרישה. עלייה פתאומית בשימוש בדייר אחד לא מנצלת את כל משאבי המחשוב ולא משפיעה על הזמינות של נציג בפרויקט של דייר אחר.
  • טיפול בשגיאות: כדי לטפל בשגיאות זמניות, כמו מגבלות קצב של קוד שגיאה 429, לוגיקת ניהול הסוכנים משתמשת בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff). אם חורגים מהמועד האחרון של ההקשר, הסוכן מבצע כיבוי מבוקר ומדווח למשתמש על התקדמות חלקית. לדוגמה, חריגה מהמועד האחרון להקשר יכולה לקרות בגלל קריאות איטיות ל-API של כלים, זמן אחזור של API של צד שלישי, עיבוד של מערכי נתונים גדולים או עיבוד שדורש הרבה משאבי מחשוב.

במאמר נקודת מבט על AI ו-ML: אמינות ב-Well-Architected Framework מפורטים עקרונות והמלצות לאמינות שספציפיים לעומסי עבודה של AI ו-ML.

יעילות תפעולית

בקטע הזה מתוארים הגורמים שצריך להביא בחשבון כשמשתמשים בארכיטקטורה לדוגמה הזו כדי לתכנן טופולוגיית Google Cloud שאפשר להפעיל ביעילות.

שיקולים לגבי Google Cloud Observability

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

שיקולי יעילות תפעולית לכל המוצרים בארכיטקטורה

שימוש ב-Agent Platform במסגרת דפוס ארכיטקטורה סטנדרטי של דיירים מאפשר לכם ליצור בסיס עקבי כשאתם מצרפים דיירים חדשים. כדי להפחית את הנטל התפעולי, כדאי להפוך את תהליך הפריסה לאוטומטי באמצעות כלים של תשתית כקוד (IaC) כמו Terraform. בקטע פריסה במסמך הזה מופיע קוד Terraform שאפשר להשתמש בו כדי ליצור ולפרוס מערכת AI אקטיבית עם כמה דיירים.

במאמר נקודת מבט על AI ו-ML: מצוינות תפעולית ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות למצוינות תפעולית שספציפיים לעומסי עבודה של AI ו-ML.

הוזלת עלויות

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

שיקולי עלות ב-Agent Platform

כדי לוודא שההגדרות והשימוש ב-Agent Platform עומדים בדרישות העלות שלכם, כדאי להביא בחשבון את ההמלצות הבאות:

  • צריכת טוקנים: כדי לנהל את העלויות ולמנוע ממודל ה-AI לחרוג מחלונות ההקשר, אפשר להשתמש באסטרטגיות הבאות לניהול ההקשר של מודל ה-AI:
    • סיכום ההקשר: במקום לשמור את כל השיחה בסשן כהקשר, אפשר להשתמש במודל AI כדי לסכם שיחות ישנות יותר ומידע פחות קריטי.
    • צמצום הפלט: זיהוי והסרה של חלקים פחות רלוונטיים או ארוכים מדי בפלט של הכלים או בהקשר שאוחזר. לדוגמה, אם אתם צריכים רק את שמות העמודות מהנתונים, אתם יכולים להסיר מטא-נתונים מיותרים מאחזור סכימה של מסד נתונים. האסטרטגיה הזו דורשת לוגיקה מותאמת אישית שמשתמשת בהיוריסטיקה, בסינון או במודל שפה קטן (SLM) כדי לחלץ את המידע החשוב ביותר.
    • מגבלת טוקנים מקסימלית: כדי למנוע לולאות אינסופיות ולשלוט בעלויות, כדאי לאכוף מגבלת טוקנים מקסימלית לסשן.

  • נקודות קצה של מודלים: כדי לנהל את מכסות ה-API ואת ניצול המשאבים, אתם יכולים לפרוס את נקודות הקצה של Agent Platform בהגדרה ייעודית או בהגדרה משותפת:

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

    עלויות הפיתוח והפריסה של מודלים של AI ב-Agent Platform

שיקולי עלות ב-Cloud Run

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

שיקולי עלות של Model Armor

כדי לאכוף משטר קפדני וגישת אבטחה של אפס אמון, בארכיטקטורה הזו פורסים את Model Armor בשתי שכבות: ברכזת הניתוב ובכל פרויקט של דייר. למרות שהגישה הדו-שכבתית הזו עוזרת להבטיח את ריבונות הנתונים, היא מגדילה את זמן האחזור ואת עלויות התפעול. כדי להפחית את העלויות ואת מורכבות המערכת, אתם יכולים לסנן את כל ההנחיות והתשובות על ידי פריסת Model Armor רק במרכז הניתוב.

שיקולי עלות לכל המוצרים בארכיטקטורה

כדי לוודא שהארכיטקטורה עומדת בדרישות העלות, כדאי להביא בחשבון את ההמלצות הכלליות הבאות:

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

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

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

    למידע נוסף על הקצאת עלויות של שירותים משותפים, קראו את המאמר Cloud FinOps: הקצאת עלויות של שירותים משותפים.

  • ניהול עלויות ריכוזי: כדי לעקוב במדויק אחרי עלות הבעלות הכוללת (TCO) של מערכת ה-AI האקטיבי ולשייך עלויות ליחידות עסקיות ספציפיות, השתמשו בתוויות ובנתוני הייצוא של החיוב ב-Cloud. איך משתמשים בתוויות כדי להגביר את המודעות לעלויות?

כדי להעריך את העלות של המשאבים ב- Google Cloud , אתם יכולים להשתמש במחשבון העלויות שלGoogle Cloud .

במאמר נקודת מבט על AI ו-ML: אופטימיזציה של עלויות ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות לאופטימיזציה של עלויות שספציפיות לעומסי עבודה של AI ו-ML.

פריסה

כדי לפרוס את ארכיטקטורת העזר הזו, משתמשים בדוגמה של AI אקטיבי מרובה דיירים ב-Terraform שזמינה ב-GitHub.

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

שותפים ביצירת התוכן

מחברים:

תורמים אחרים: