במסמך הזה מפורטת ארכיטקטורת הפניה שאפשר להשתמש בה כדי לאבטח את תשתית הרשת של אפליקציות עם יצירה משולבת-אחזור (RAG). בדרך כלל, ארכיטקטורת RAG מכילה מערכות משנה נפרדות לטיפול בתהליכי עיבוד הנתונים ואחזור התוכן. ארכיטקטורת ההפניה הזו מדגימה איך להשתמש ב-VPC משותף כדי:
- ליצור הפרדה בין מערכות המשנה באמצעות הרשאות לניהול זהויות והרשאות גישה (IAM).
- חיבור רכיבי האפליקציה באמצעות כתובות IP פרטיות.
קהל היעד של המסמך הזה כולל אדריכלים, מפתחים ומנהלי רשתות ואבטחה. ההנחה במאמר הזה היא שיש לכם הבנה בסיסית של רשתות. במסמך הזה לא מתואר תהליך היצירה של אפליקציה שמבוססת על RAG.
ארכיטקטורה
התרשים הבא מציג את ארכיטקטורת הרשת שמתוארת במסמך הזה:
הארכיטקטורה בתרשים שלמעלה מציגה את הרכיבים הבאים:
| רכיב | מטרה |
|---|---|
| רשת חיצונית, בארגון או בענן אחר |
|
| פרויקט ניתוב |
|
| פרויקט מארח של VPC משותף של RAG | מארח רשת VPC משותפת שמארחת את שירות ה-frontend, את איזון העומסים הפנימי של האפליקציה ושירותים אחרים שזקוקים לרשת VPC. לכל הפרויקטים של השירות יש גישה לרשת ה-VPC המשותפת הזו. |
| פרויקט שירות להטמעת נתונים |
כולל קטגוריה של Cloud Storage לקלט של נתונים גולמיים. מכיל את מערכת המשנה להעברת נתונים, שכוללת את הרכיבים הבאים:
|
| הצגת פרויקט שירות |
מכיל את מערכת המשנה להצגת מודעות, שכוללת את הרכיבים הבאים שמספקים את השירותים והפונקציות להסקת מסקנות ולתקשורת:
|
| פרויקט שירות קצה קדמי |
מכיל את מערכת המשנה להצגת נתונים, שהיא מאזן עומסים של אפליקציות בחלק הקדמי של שירות אינטראקציה עם משתמשים שפועל ב-Cloud Run או ב-Google Kubernetes Engine (GKE). הפרויקט מכיל גם את Google Cloud Armor, שעוזר להגביל את הגישה לשירות. אם רוצים לספק גישה מהאינטרנט, אפשר להוסיף מאזן עומסים חיצוני אזורי של אפליקציות (ALB). |
| גבולות גזרה של VPC Service Controls | עוזרת להגן מפני זליגת מידע. אי אפשר להעתיק נתונים שמאוחסנים בקטגוריות של Cloud Storage לשום מקום מחוץ לגבולות גזרה, והפעולות במישור הבקרה מוגנות. |
בקטעים הבאים מתוארים החיבורים וזרימות התנועה בארכיטקטורה.
קשרים בין רכיבים
בקטע הזה מוסבר על החיבורים בין הרכיבים והרשתות בארכיטקטורה הזו.
רשת חיצונית לניתוב רשת VPC
הרשתות החיצוניות מתחברות לרשת ה-VPC של Google Cloud הניתוב דרך Cloud Interconnect או Cloud VPN, שהם רשתות מסוג Hub-and-Spoke היברידיות של NCC.
נתבי Cloud Router ברשת הניתוב של ה-VPC והנתבים החיצוניים ברשת החיצונית מחליפים מסלולי Border Gateway Protocol (BGP):
- נתבים ברשתות חיצוניות מכריזים על הנתיבים של תת-רשתות חיצוניות ל-Cloud Router של ה-VPC לניתוב. אפשר להביע את העדפת המסלולים באמצעות מדדים ומאפיינים של BGP.
- נתבי Cloud Router ברשת ה-VPC של הניתוב מפרסמים את המסלולים לקידומות ב-VPC של Google Cloudלרשתות החיצוניות.
ניתוב רשת VPC לרשת VPC משותפת
אתם מחברים את רשת ה-VPC של הניתוב ואת רשת ה-VPC של RAG באמצעות רכיבי ה-VPC של NCC ב-NCC hub. המרכז מארח גם את ה-spokes ההיברידיים לרשת החיצונית.
משאב למשאב ברשת ה-VPC המשותפת
בתרשים הזה, קטגוריה של Cloud Storage מקבלת נתונים מהרשת החיצונית. בקשות להסקת מסקנות מגיעות דרך מאזן עומסים פנימי אזורי של אפליקציות. לגבי שאר המערכת, יש לכם את האפשרויות הבאות:
- אירוח של הכול בתשתית Google SaaS, כמו קטגוריות של Cloud Storage, Gemini Enterprise Agent Platform, Cloud Run ו-Pub/Sub. במקרה כזה, הרכיבים מתקשרים דרך תשתית פרטית של Google.
- אירוח של הכול בעומסי עבודה שפועלים במכונות וירטואליות של Compute Engine, באשכולות GKE, במסדי נתונים של Cloud SQL או ברכיבים אחרים שפועלים ברשתות VPC. במקרה כזה, המערכות מתקשרות באמצעות כתובות IP פרטיות ברשתות שמקושרות דרך NCC או דרך קישור בין רשתות VPC שכנות (peering).
- שימוש בשילוב של שירותים מנוהלים, שירותי פלטפורמה ושירותי תשתית. במקרה כזה, אפשר ליצור חיבורים בין רשת VPC לבין שירות בניהול מלא באמצעות השיטות הבאות:
- גישה פרטית ל-Google: בשיטה הזו, עומסי עבודה שאין להם כתובות IP חיצוניות ושפועלים ברשתות VPC יכולים לגשת לממשקי Google APIs. הגישה הזו מתבצעת באופן פנימי דרך התשתית של Google, והתהליך הזה לא חושף את התנועה הזו לאינטרנט.
- Private Service Connect: בשיטה הזו אפשר ליצור נקודת קצה בפרויקט השירות לשירותים כמו AlloyDB ל-PostgreSQL שמארחים ברשתות VPC מנוהלות.
מאזן עומסים של אפליקציות (ALB) מרשת חיצונית לשירות קצה קדמי
נקודת הקצה של מאזן העומסים הפנימי האזורי של אפליקציות (ALB) היא כתובת IP ברשת RAG. רשת ה-RAG, רשת הניתוב והחיבורים ההיברידיים לרשת החיצונית הם כולם רשתות משנה של אותו מרכז NCC. לכן, אפשר להנחות את NCC לייצא את כל טווחי המשנה של הרשתות המסועפות לרשת המרכזית, ואז הרשת המרכזית מייצאת מחדש את טווחי המשנה האלה לרשתות המסועפות האחרות. משתמשי הקצה במערכת יכולים לגשת לשירות עם איזון העומסים מהרשת החיצונית.
תנועות תנועה
זרימות התנועה בארכיטקטורת ההפניה הזו כוללות זרימת נתונים של RAG וזרימת הסקה.
רשימת השלבים של RAG
בתרשים הזה מתואר איך נתוני RAG זורמים במערכת ממהנדסי נתונים אל אחסון וקטורי.
- מהרשת החיצונית, מהנדסי נתונים מעלים נתונים גולמיים דרך חיבור Cloud Interconnect או חיבור Cloud VPN. הנתונים מועלים לנקודת הקצה של Private Service Connect ברשת ה-VPC של הניתוב.
- הנתונים מועברים בתשתית הפנימית של Google לקטגוריית Cloud Storage בפרויקט של שירות הטמעת הנתונים.
בפרויקט של שירות הטמעת הנתונים, הנתונים עוברים בין המערכות באחת מהשיטות הבאות:
- גישה פרטית ל-Google
- נקודות קצה של Private Service Connect
- תשתית ישירה של Google
השיטה תלויה בשאלה אם המערכות מתארחות בGoogle Cloud רשתות VPC או ישירות ב-Google Cloud. כחלק מהתהליך הזה, מערכת המשנה להזנת נתונים מעבירה למודל נתוני RAG בחלקים, והמודל יוצר וקטורים לכל חלק.
מערכת המשנה להטמעת נתונים כותבת את נתוני הווקטורים ואת הנתונים המקובצים למאגר הנתונים המתאים.
תהליך ההסקה
בתרשים הזה מתוארות בקשות של לקוחות.
- לקוח שולח בקשה מתוך הרשת החיצונית לכתובת ה-IP של השירות.
- הבקשה עוברת דרך חיבור Cloud Interconnect או חיבור Cloud VPN לרשת ה-VPC של הניתוב.
- הבקשה עוברת דרך חיבור ה-VPC מסוג spoke לרשת ה-VPC של RAG.
- בקשת הלקוח מגיעה למאזן העומסים של אפליקציות (ALB), שמעביר את הבקשה למערכת המשנה של הקצה הקדמי.
- מערכת המשנה של החזית מעבירה את הבקשה למערכת המשנה של ההגשה.
- מערכת המשנה להצגת מודעות מרחיבה את הבקשה באמצעות נתונים רלוונטיים מהקשר מאגר הנתונים.
- מערכת המשנה להצגת התוצאות שולחת את ההנחיה המשופרת למודל ה-AI, שמייצר תשובה.
המוצרים שהשתמשו בהם
הארכיטקטורה הזו כוללת את המוצרים הבאים: Google Cloud
- ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . VPC כולל קישור בין רשתות VPC שכנות (peering), Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
- VPC משותף: תכונה של ענן וירטואלי פרטי שמאפשרת לכם לחבר משאבים מכמה פרויקטים לרשת VPC משותפת באמצעות כתובות IP פנימיות של אותה הרשת.
- Private Service Connect: תכונה שמאפשרת לצרכנים לגשת לשירותים מנוהלים באופן פרטי מתוך רשת ה-VPC שלהם.
- גישה פרטית ל-Google: תכונה שמאפשרת למכונות וירטואליות (VM) ללא כתובות IP חיצוניות להגיע לכתובות IP חיצוניות של שירותים וממשקי Google API.
- Cloud Interconnect: שירות שמרחיב את הרשת החיצונית שלכם לרשת של Google באמצעות חיבור עם זמינות גבוהה וזמן אחזור קצר.
- Cloud VPN: שירות שמרחיב באופן מאובטח את הרשת השכנה לרשת של Google באמצעות מנהרת VPN מסוג IPsec.
- Cloud Router: שירות מבוזר ומנוהל במלואו שמספק יכולות של פרוטוקול Border Gateway Protocol (BGP) לדיבור ולתגובה. Cloud Router פועל עם Cloud Interconnect, Cloud VPN ומכשירי נתב כדי ליצור מסלולים דינמיים ברשתות VPC על סמך מסלולים שהתקבלו מ-BGP ומסלולים מותאמים אישית שנלמדו.
- Network Connectivity Center: מסגרת תזמור שמפשטת את קישוריות הרשת בין משאבי spoke שמחוברים למשאב ניהול מרכזי שנקרא hub.
- VPC Service Controls: פונקציונליות מנוהלת של רשת שמצמצמת את הסיכונים לזליגת נתונים מהמשאבים שלכם ב- Google Cloud .
- Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים בעלי ביצועים גבוהים ורמת מדרגיות גבוהה.
- הגנה מוגברת על המודל: שירות שמספק הגנה למשאבי AI גנרטיבי ו-AI אקטיבי מפני החדרת פרומפטים, דליפות של מידע אישי רגיש ותוכן פוגעני.
- Google Cloud Armor: שירות אבטחת רשת שמציע כללים של חומת אש ליישומי אינטרנט (WAF) ועוזר להגן מפני מתקפות DDoS ומתקפות על אפליקציות.
- Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך ומחוץ Google Cloud, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
תרחישים לדוגמה
הארכיטקטורה הזו מיועדת לתרחישים ארגוניים שבהם הקלט, הפלט והתקשורת הפנימית של המערכת הכוללת חייבים להשתמש בכתובות IP פרטיות ואסור להם לעבור באינטרנט:
- קלט פרטי: הנתונים שהועלו לא מועברים באינטרנט. במקום זאת, אתם מארחים את קטגוריית Cloud Storage מאחורי נקודת קצה של Private Service Connect ברשת ה-VPC של הניתוב Google Cloud. אתם מעתיקים נתוני RAG דרך Cloud Interconnect או חיבור Cloud VPN באמצעות כתובות IP פרטיות בלבד.
- קישוריות פרטית בין שירותים: שירותים מתקשרים ביניהם באמצעות ממשקים פנימיים של Google או באמצעות כתובות פרטיות שהן פנימיות לרשתות ה-VPC.
- פלט פרטי: אי אפשר לגשת לתוצאות ההסקה דרך האינטרנט, אלא אם בוחרים להגדיר גישה כזו. כברירת מחדל, רק משתמשים ברשת החיצונית המיועדת יכולים להגיע לנקודת הקצה הפרטית של השירות.
חלופות עיצוב
בקטע הזה מוצגות גישות חלופיות לעיצוב רשת שאפשר לשקול עבור אפליקציה עם יכולות RAG ב- Google Cloud.
הגדרת השירות כגלוי לכולם
בארכיטקטורה שמוצגת במסמך הזה, רק משתמשים ברשת הפנימית שלכם יכולים לשלוח שאילתות לאפליקציה. אם האפליקציה שלכם צריכה להיות נגישה ללקוחות באינטרנט, צריך להשתמש במאזן עומסים חיצוני אזורי של אפליקציות.
שימוש ב-GKE Inference Gateway
אם מערכת המשנה של קצה קדמי פועלת ב-GKE, אפשר להשתמש בשער היקש במקום במאזן עומסים של אפליקציות.
שיקולים בתכנון
בקטע הזה מפורטות הנחיות נוספות שיעזרו לכם לפרוס רשת כדי לתמוך בקישוריות פרטית לארכיטקטורה עם יכולות RAG. ההנחיות האלה יכולות לעזור לכם לעמוד בדרישות הספציפיות שלכם בנושא אבטחה ותאימות, אמינות, עלות וביצועים. ההנחיות בקטע הזה הן לא מלאות. יכול להיות שתצטרכו להתייחס לגורמים נוספים שלא מפורטים בקטע הזה, בהתאם לפריסה הספציפית שלכם.
אבטחה, פרטיות ותאימות
ברוב המקרים, פורסים את Model Armor לפני מודל ה-AI כדי להעריך את ההנחיות הנכנסות ואת התוצאות היוצאות. Model Armor עוזר למנוע סיכונים פוטנציאליים ומבטיח שימוש ב-AI בצורה אחראית.
כדי לדחות בקשות לא הולמות לפני שהן מגיעות למערכת המשנה של השרת, אתם יכולים לחבר את הגנה מוגברת על המודל אל מאזן העומסים של אפליקציות (ALB).
הארכיטקטורה הזו משתמשת ב-VPC Service Controls, שעוזר למנוע זליגת נתונים לא מורשית.
העיצוב הזה מבוסס על עקרונות אבטחה מוכחים כדי לעזור לכם לאבטח את עומסי העבודה של RAG. עקרונות והמלצות אבטחה שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Security ב-Well-Architected Framework.
הוזלת עלויות
עקרונות והמלצות לאופטימיזציה של עלויות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Cost optimization ב-Well-Architected Framework.
אופטימיזציה של הביצועים
עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ולמידת מכונה מפורטים במאמר AI and ML perspective: Performance optimization ב-Well-Architected Framework.
פריסה
בקטע הזה מוסבר איך ליצור את האפליקציה:
- זיהוי האזור לעומסי עבודה.
- יצירת Google Cloud פרויקטים ורשתות VPC.
- חיבור של רשתות חיצוניות לרשת VPC של הניתוב.
- קישור רשתות באמצעות NCC.
- זיהוי רכיבים לפריסת RAG ויצירת חשבונות שירות
- הגדרת VPC Service Controls
- בניית מערכת המשנה להטמעת נתונים.
- בניית מערכת המשנה להצגת מודעות.
- בניית מערכת המשנה של הקצה הקדמי.
- הגדרת האפליקציה כך שאפשר יהיה להגיע אליה מהאינטרנט.
זיהוי האזור של עומסי העבודה
באופן כללי, מומלץ למקם את הקישוריות, רשתות המשנה של ה-VPC ועומסי העבודה של Google Cloudבסמיכות לרשתות המקומיות או ללקוחות ענן אחרים. מידע נוסף על בחירת אזור לעומסי העבודה זמין במאמרים Google Cloud Region Picker ושיטות מומלצות לבחירת אזורים ב-Compute Engine.
יצירה של Google Cloud פרויקטים ורשתות VPC
אם הארגון שלכם כבר הגדיר רשת חוצת-ענן לאפליקציות מבוזרות, פרויקט הניתוב ורשת ה-VPC לניתוב כבר אמורים להתקיים.
יוצרים את Google Cloud הפרויקטים ואת רשת ה-VPC בסדר הבא:
- יוצרים את פרויקט הניתוב.
- יוצרים את רשת ה-VPC לניתוב עם גישה פרטית ל-Google.
- יוצרים את פרויקט ה-RAG.
- העלאת הפרויקט RAG לרמה של פרויקט מארח ב-VPC משותף.
- יוצרים את פרויקט השירות להעברת נתונים.
- יוצרים את פרויקט שירות ההצגה.
- יוצרים את פרויקט השירות של הקצה הקדמי.
- יוצרים את רשת ה-RAG של ה-VPC המשותף עם גישה פרטית ל-Google.
- נותנים לפרויקטים של השירות הרשאה להשתמש ברשת RAG.
חיבור של רשתות חיצוניות לרשת VPC לניתוב
אפשר לדלג על השלב הזה אם כבר הגדרתם רשת חוצת-ענן לאפליקציות מבוזרות.
הגדרת הקישוריות בין הרשתות החיצוניות לבין רשת הניתוב. כדי להבין את הטכנולוגיות הרלוונטיות, אפשר לעיין במאמר בנושא קישוריות חיצונית והיברידית. הנחיות לבחירת מוצר קישוריות זמינות במאמר בחירת מוצר של Network Connectivity.
קישור רשתות באמצעות NCC
- בפרויקט הניתוב, יוצרים רכזת NCC.
- מוסיפים את חיבורי Cloud Interconnect בתור VLAN attachment spokes או מוסיפים חיבורי Cloud VPN בתור VPN spokes.
- מוסיפים את רשת ה-VPC של RAG ואת רשת ה-VPC של הניתוב כרשתות VPC מסוג Hub.
זיהוי רכיבים לפריסת RAG ויצירת חשבונות שירות
- בוחרים פריסת RAG ויוצרים רשימה של הרכיבים שנדרשים לה.
- לזהות את הגישה שכל רכיב צריך.
- לכל רכיב, יוצרים חשבון שירות עם ההרשאות המתאימות. במקרים מסוימים, המשמעות היא שאתם נותנים לרכיב הרשאה לקרוא מפרויקט שירות אחר או לכתוב בו.
העיצוב הזה מניח שאתם משתמשים בקטגוריה של Cloud Storage כרכיב קלט הנתונים, ומשתמשים במאזן עומסים של אפליקציות בחלק הקדמי של ההסקה. שאר העיצוב יכול להשתנות לפי הצורך.
מומלץ שכל רכיב יפעל כחשבון שירות משלו. מוודאים שלכל רכיב יש רק את הרשאות ה-IAM המינימליות שנדרשות לביצוע הפונקציות שלו. לדוגמה, משימת Cloud Run במערכת המשנה להעברת נתונים צריכה לקרוא מהקטגוריה של Cloud Storage שמשמשת כקלט, אבל היא לא צריכה לכתוב לקטגוריה. בדוגמה הזו, לפרויקט השירות שמריץ את משימת Cloud Run צריכה להיות הרשאה לקרוא מהקטגוריה בלבד, ללא הרשאת כתיבה.
הגדרת VPC Service Controls
- יוצרים גבול גזרה של VPC Service Controls מסביב לפריסה.
- הגדרת כללי גישה.
בניית מערכת המשנה להעברת נתונים
מערכת המשנה להזנת נתונים מקבלת נתונים גולמיים ממהנדסי נתונים ומעבדת אותם לשימוש במערכת המשנה להצגת נתונים.
- בפרויקט של שירות הטמעת הנתונים, יוצרים קטגוריה של Cloud Storage.
- ברשת ה-VPC של הניתוב, יוצרים נקודת קצה אזורית של Private Service Connect ומקשרים את נקודת הקצה לדלי.
- ברשת החיצונית, מוסיפים רשומת DNS לנקודת הקצה באמצעות כתובת ה-IP וכתובת ה-URL שנוצרו בשלב הקודם.
- מעדכנים את הכללים של חומת האש ברשת החיצונית כדי לאפשר גישה לכתובת ה-IP של נקודת הקצה.
- בפרויקט של שירות הטמעת הנתונים, בונים את שאר צינור ההטמעה בהתאם לארכיטקטורת ה-RAG שבחרתם.
- צריך להעניק הרשאות IAM כדי שהמשאב הרלוונטי בצינור ההטמעה יוכל לגשת למודל שמפיק את הווקטורים.
- צריך להעניק הרשאות IAM כדי שהמשאב הרלוונטי בצינור להעברת נתונים יוכל לכתוב למאגר הנתונים הווקטורי.
בניית מערכת המשנה להצגת התוכן
- בפרויקט של שירות ההגשה, בונים את צינור עיבוד הנתונים להגשה.
- נותנים הרשאות IAM כדי שחשבון השירות במערכת הקצה הקדמי יוכל לגשת לפלט של מערכת המשנה להצגת מודלים.
בניית מערכת המשנה של הקצה הקדמי
בקטע הזה מניחים שאתם משתמשים במאזן עומסים פנימי אזורי של אפליקציות (ALB) שמשתמש ב-NEG בלי שרת מול Cloud Run. עם זאת, אפשר להשתמש במאזן עומסים ובקצה עורפי אחרים.
- יוצרים את הקוד למערכת הקצה הקדמי.
- בפרויקט שירות הקצה הקדמי, פורסים את מערכת הקצה הקדמי עם איזון עומסים, כולל השלב האופציונלי של הגדרת מדיניות אבטחה של Cloud Armor.
- מגדירים את Cloud Router ברשת הניתוב של ה-VPC כדי להעביר מסלולים מרשת ה-VPC של RAG לנתבים המקומיים. ההגדרה הזו מאפשרת ללקוחות להגיע למאזן העומסים של האפליקציה.
- ברשת החיצונית, מגדירים את כללי חומת האש כך שחלק הקצה הקדמי של מאזן העומסים יהיה נגיש מהרשת החיצונית.
- ברשת החיצונית, מעדכנים את ה-DNS כך שיפנה לכלל ההעברה של מאזן העומסים של האפליקציה.
הפיכת האפליקציה לנגישה מהאינטרנט
הקטע הזה הוא אופציונלי.
העיצוב הזה מניח שאתם רוצים שהשירות יהיה נגיש רק מהרשת החיצונית שלכם, אבל אתם יכולים גם להפוך את השירות לנגיש מהאינטרנט.
כדי שהשירות יהיה נגיש מהאינטרנט, צריך לבצע את השלבים הבאים:
- יוצרים מאזן עומסים חיצוני אזורי של אפליקציות (ALB) שמפנה לאותו בק-אנד שאליו מפנה מאזן העומסים הפנימי של האפליקציות. משלימים את השלב האופציונלי להגדרת מדיניות אבטחה של Cloud Armor.
- עדכון של VPC Service Controls כדי לאפשר ללקוחות שירות להגיע לשירותי קצה עורפיים.
המאמרים הבאים
- מידע על רשתות חוצות ענן לאפליקציות מבוזרות
- איך מארחים אפליקציות וסוכנים מבוססי-AI ב-Cloud Run
- מידע על שיטות מומלצות לאתיקה של בינה מלאכותית ומסנני בטיחות ב-Agent Platform
- מידע על אסטרטגיות להנחיות עבור מודלים גדולים של שפה (LLM)
- סקירה כללית של עקרונות והמלצות לארכיטקטורה שספציפיים לעומסי עבודה של AI ו-ML ב- Google Cloudזמינה בפרספקטיבה של AI ו-ML ב-Well-Architected Framework.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- Deepak Michael | Networking Specialist Customer Engineer
- מארק שלגנהוף | כותב טכני, רשתות
תורמי תוכן אחרים:
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Victor Moreno | Product Manager, Cloud Networking
- Samantha He | Technical Writer
- אמט וויליאמס | מהנדס קשרי מפתחים
- Aspen Sherrill | Cloud Security Architect