קישוריות פרטית לאפליקציות של AI גנרטיבי עם יכולות RAG

Last reviewed 2026-11-03 UTC

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

  • הפרדה בין תת-המערכות באמצעות הרשאות של ניהול זהויות והרשאות גישה (IAM).
  • מחברים את רכיבי האפליקציה באמצעות כתובות IP פרטיות.

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

ארכיטקטורה

בתרשים הבא מוצגת ארכיטקטורת הרשת שמתוארת במסמך הזה:

ארכיטקטורת רשת לאפליקציות עם RAG.

חיבורים וזרימת תנועה בארכיטקטורת הרשת.

הארכיטקטורה בתרשים הקודם מציגה את הרכיבים הבאים:

רשת חיצונית, מקומית או בענן אחר

רשת חיצונית שמבצעת את הפונקציות הבאות:

  • מספק קישוריות רשת למהנדסי מערכות מידע שמעלים נתוני RAG גולמיים.
  • מנתק את הקישוריות לרשת החיצונית.
  • מארח נתבים חיצוניים.
  • מספק קישוריות לנקודת הקצה של Private Service Connect ברשת הניתוב של הענן הווירטואלי הפרטי (VPC) של Google Cloud .
  • מכיל שרתי DNS שמפנים לנקודת הקצה של Private Service Connect.
פרויקט ניתוב

פרויקט ב- Google Cloud שמבצע את הפונקציות הבאות:

  • מארח את רשת ה-VPC לניתוב, שמחוברת לרשת החיצונית באמצעות חיבור Cloud Interconnect או Cloud VPN.
  • מארח רכזת של מרכז הקישוריות לרשת (NCC) שמחברת בין הרשת החיצונית, רשת ה-VPC לניתוב ורשתות ה-VPC המשותפות.
  • מארח נקודת קצה (endpoint) של Private Service Connect שמחוברת לנקודת קצה אזורית של Cloud Storage. נקודת הקצה הזו מאפשרת למהנדסי מערכות מידע להעלות נתוני RAG לקטגוריה של Cloud Storage.
פרויקט מארח של VPC משותף ל-RAG

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

פרויקט שירות להטמעת נתונים

מכיל קטגוריה של Cloud Storage לקלט של נתונים גולמיים. מכיל את תת-המערכת להטמעת נתונים, שכוללת את הרכיבים הבאים:

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

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

  • מאגר נתונים של RAG שמכיל את הפלט של תת-המערכת להטמעת נתונים.
  • תהליכי הצגה שמזינים את המודל על ידי שילוב של שאילתת ההסקה עם נתונים ממאגר הנתונים של RAG.
  • המודל שבו משתמשת תת-המערכת להצגת מודעות כדי ליצור וקטורים מנתוני ה-RAG שהועלו ולעבד את הבקשה של משתמש הקצה.
פרויקט שירות של ממשק קצה (frontend)

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

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

היקף של VPC Service Controls

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

בקטעים הבאים מתוארים החיבורים וזרימת התנועה בארכיטקטורה.

חיבורים בין רכיבים

בקטע הזה מתוארים החיבורים בין הרכיבים והרשתות בארכיטקטורה הזו.

רשת חיצונית לרשת VPC לניתוב

הרשתות החיצוניות מתחברות לרשת ה-VPC לניתוב ב- Google Cloud באמצעות Cloud Interconnect או Cloud VPN, שהם רכיבי Spoke היברידיים של NCC Hub.

נתבי Cloud Router ברשת ה-VPC לניתוב והנתבים החיצוניים ברשת החיצונית מחליפים מסלולים של Border Gateway Protocol ‏(BGP):

  • נתבים ברשתות חיצוניות מפרסמים את המסלולים של רשתות המשנה החיצוניות ל-Cloud Router של ה-VPC המנתב. אפשר להגדיר את העדפת המסלולים באמצעות מדדים ומאפיינים של BGP.
  • נתבי Cloud Router ברשת ה-VPC לניתוב מפרסמים את המסלולים של הקידומות ברשתות ה-VPC של Google Cloudלרשתות החיצוניות.

ניתוב רשת VPC לרשת VPC משותפת

אתם מחברים את רשת ה-VPC לניתוב ואת רשת ה-VPC ל-RAG באמצעות ה-VPC spokes של ה-NCC hub. הרכזת גם מארחת את השלוחות ההיברידיות לרשת החיצונית.

ממשאב למשאב בתוך רשת ה-VPC המשותפת

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

  • לארח את כל המשאבים בתשתית ה-SaaS של Google, כמו קטגוריות של Cloud Storage, ‏Gemini Enterprise Agent Platform, ‏Cloud Run ו-Pub/Sub. במקרה כזה, הרכיבים מתקשרים דרך תשתית פרטית של Google.
  • לארח את כל עומסי העבודה שפועלים במכונות וירטואליות של Compute Engine, באשכולות GKE, במסדי נתונים של Cloud SQL או ברכיבים אחרים שפועלים ברשתות VPC. במקרה כזה, המערכות מתקשרות באמצעות כתובות IP פרטיות ברשתות שאתם מקשרים דרך NCC או קישור (peering) בין רשתות VPC שכנות.
  • להשתמש בשילוב של שירותים מנוהלים, שירותי פלטפורמה ושירותי תשתית. במקרה כזה, אפשר ליצור חיבורים בין רשת VPC לבין שירות שמנוהל במלואו באמצעות השיטות הבאות:
    • גישה פרטית ל-Google: בשיטה הזו, עומסי עבודה שאין להם כתובות IP חיצוניות ושפועלים ברשתות VPC יכולים לגשת לממשקי Google API. הגישה הזו מתבצעת באופן פנימי דרך התשתית של Google, והתהליך הזה לא חושף את התנועה הזו לאינטרנט.
    • ‫Private Service Connect: בשיטה הזו, אתם יכולים ליצור נקודת קצה בפרויקט השירות בשביל שירותים כמו AlloyDB ל-PostgreSQL, שמתארחים ברשתות VPC מנוהלות.

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

נקודת הקצה של מאזן העומסים הפנימי האזורי של האפליקציות היא כתובת IP ברשת RAG. רשת ה-RAG, רשת הניתוב והחיבורים ההיברידיים לרשת החיצונית הם כולם רשתות Spoke של אותו NCC Hub. לכן, אתם יכולים להורות ל-NCC לייצא את כל טווחי המשנה של ה-spoke ל-hub, ואז לייצא מחדש את טווחי המשנה האלה לרשתות ה-spoke האחרות. משתמשי הקצה של המערכת יכולים להגיע לשירות עם איזון עומסים מהרשת החיצונית.

זרימת התנועה

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

תהליך האכלוס של RAG

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

  1. מהרשת החיצונית, מהנדסי מערכות מידע מעלים נתונים גולמיים דרך החיבור של Cloud Interconnect או חיבור דרך VPN. הנתונים מועלים לנקודת הקצה של Private Service Connect ברשת ה-VPC לניתוב.
  2. הנתונים עוברים דרך התשתית הפנימית של Google לקטגוריה של Cloud Storage בפרויקט של שירות הטמעת הנתונים.

  3. בפרויקט של שירות הטמעת הנתונים, הנתונים עוברים בין מערכות באחת מהשיטות הבאות:

    • גישה פרטית ל-Google
    • נקודות קצה (endpoint) של Private Service Connect
    • תשתית ישירה של Google

    השיטה תלויה בשאלה אם המערכות מתארחות ברשתות VPC או ישירות ב-Google Cloud.Google Cloud כחלק מהתהליך הזה, תת-המערכת של הטמעת הנתונים מזינה למודל נתוני RAG מחולקים, והמודל מייצר וקטורים לכל חלק.

  4. תת-המערכת להטמעת נתונים כותבת את נתוני הווקטורים והנתונים המפוצלים למאגר הנתונים המתאים.

תהליך הסקת המסקנות

התהליך הזה מתאר בקשות של לקוחות.

  1. מהרשת החיצונית, לקוח שולח בקשה לכתובת ה-IP של השירות.
  2. הבקשה עוברת דרך החיבור של Cloud Interconnect או חיבור דרך VPN לרשת ה-VPC המנותבת.
  3. הבקשה עוברת דרך החיבור של ה-VPC Spoke לרשת ה-VPC של RAG.
  4. בקשת הלקוח מגיעה למאזן העומסים של האפליקציות, שמעביר את הבקשה לתת-המערכת של ממשק המשתמש.
  5. תת-המערכת של החזית מעבירה את הבקשה לתת-המערכת של ההצגה.
  6. תת-המערכת להצגת מודעות משפרת את הבקשה באמצעות הנתונים ההקשריים הרלוונטיים ממאגר הנתונים.
  7. תת-המערכת להצגת מודעות שולחת את ההנחיה המורחבת למודל ה-AI, שיוצר תשובה.

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

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

  • ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות גלובלית וניתנת להתאמה של רשתות לעומסי העבודה ב- Google Cloud . ‫VPC כולל את VPC Network Peering,‏ Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
  • VPC משותף: תכונה של ענן וירטואלי פרטי שמאפשרת לחבר משאבים מכמה פרויקטים לרשת VPC משותפת, באמצעות כתובות IP פנימיות של אותה הרשת.
  • ‫Private Service Connect: תכונה שמאפשרת לצרכנים לגשת לשירותים מנוהלים באופן פרטי מתוך רשת ה-VPC שלהם.
  • גישה פרטית ל-Google: תכונה שמאפשרת למכונות וירטואליות בלי כתובות IP חיצוניות להגיע לכתובות ה-IP החיצוניות של ממשקי ה-API והשירותים של Google.
  • ‫Cloud Interconnect: שירות שמרחיב את הרשת החיצונית לרשת של Google באמצעות חיבור עם זמינות גבוהה וזמן אחזור קצר.
  • ‫Cloud VPN: שירות שמרחיב באופן מאובטח את הרשת השכנה לרשת של Google באמצעות מנהרת IPsec VPN.
  • ‫Cloud Router: שירות מבוזר ומנוהל באופן מלא, שמספק יכולות של דובר ומשיב של Border Gateway Protocol ‏(BGP). ‫Cloud Router פועל עם Cloud Interconnect,‏ Cloud VPN ונתבים וירטואליים כדי ליצור מסלולים דינמיים ברשתות VPC, על סמך מסלולים שהתקבלו מ-BGP ומסלולים שנלמדו בהתאמה אישית.
  • thought ‫Network Connectivity Center: מסגרת תזמור (orchestration) שמפשטת את הקישוריות ברשת בין משאבי Spoke שמחוברים למשאב ניהול מרכזי שנקרא Hub.
  • ‫VPC Service Controls: פונקציונליות של רשת מנוהלת שמצמצמת את הסיכונים לזליגת נתונים מהמשאבים שלכם ב- Google Cloud .
  • ‫Cloud Load Balancing: מגוון של מאזני עומסים גלובליים ואזוריים, עם ביצועים גבוהים ויכולת התאמה לעומס.
  • ‫Model Armor: שירות שמגן על משאבי ה-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.

הגדרת השירות כזמין לכולם

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

שימוש ב-GKE Inference Gateway

אם תת-המערכת של ממשק המשתמש פועלת ב-GKE, אתם יכולים להשתמש ב-GKE Inference Gateway במקום במאזן עומסים של אפליקציות.

שיקולים בתכנון

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

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

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

  • סינון הנחיות ותשובות: פורסים את הגנה מוגברת על המודל לפני מודל ה-AI כדי להעריך את ההנחיות הנכנסות ואת התוצאות היוצאות, ולבדוק אם יש בהן החדרת פרומפטים, ניסיונות פריצה, דליפות של מידע אישי רגיש והפרות של מדיניות ה-AI האחראי. אתם יכולים לשלב את Model Armor ישירות עם Gemini Enterprise Agent Platform או לצרף את Model Armor למאזן העומסים של האפליקציות (ALB) באמצעות תוספי תנועה של Service Extensions, כדי לדחות בקשות בלתי הולמות לפני שהן מגיעות לתת-המערכת להצגת מודעות. כדי לגשת באופן פרטי לנקודות קצה אזוריות של Model Armor מתוך רשת VPC בלי שגיאות אישורים כשמשתמשים בגישה פרטית ל-Google או ב-VPC Service Controls, צריך ליצור נקודת קצה אזורית של Private Service Connect לממשקי ה-API של Model Armor.
  • חלוקה לרשתות משנה של רשתות וגבולות גזרה: בארכיטקטורה הזו משתמשים ב-VPC Service Controls כדי למנוע זליגת נתונים לא מורשית בפרויקטים של השירות. בנוסף לגבולות הגזרה לשירות, כדאי להשתמש בכללי מדיניות היררכיים וברשת של Cloud Next Generation Firewall עם תגים שמנוהלים על ידי IAM, כדי להגביל את התנועה ממזרח למערב בין עומסי העבודה של הטמעת הנתונים, הצגת הנתונים וה-frontend ברשת ה-VPC המשותפת.
  • זהות וגישה לפי מודל אבטחה של אפס אמון: כדי לאכוף בקרת גישה לפי מודל אבטחה של אפס אמון במאזן העומסים הפנימי של האפליקציות או במאזן העומסים החיצוני האזורי של האפליקציות, מפעילים את Identity-Aware Proxy ‏(IAP). כך רק משתמשים מאומתים ומורשים יכולים לשלוח שאילתות לאפליקציית ה-RAG. שלבו חשבונות שירות עם הרשאות מינימליות עם כללי מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) כדי להגביל את המשאבים שכל חשבון משתמש של תת-מערכת יכול לגשת אליהם. אם תת-המערכת להצגת מודעות מתזמרת סוכנים אוטונומיים או כלים של Model Context Protocol‏ (MCP) ברשתות פרטיות, השתמשו ב-Agent Identity וב-Agent Gateway כדי לאמת ולנהל את התנועה בין הסוכנים לכלים.
  • פרטיות והצפנת נתונים: משתמשים ב-Sensitive Data Protection בתת-המערכת של הטמעת הנתונים כדי לבדוק, לסווג ולהסיר פרטים אישיים מזהים (PII) ממסמכים גולמיים שהועלו לקטגוריה של Cloud Storage, לפני שיוצרים הטמעות וכותבים במאגר הנתונים של RAG. אם אתם צריכים לשלוט במפתחות ההצפנה כדי לעמוד בתקנות, הגדירו מפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud Key Management Service‏ (Cloud KMS) לקטגוריה של Cloud Storage, למאגר הנתונים של הווקטורים ולנקודות הקצה של המודל.

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

אמינות

כדי לבנות ולהפעיל תשתית רשת אמינה לאפליקציה עם יכולות RAG, כדאי לפעול לפי ההמלצות הבאות:

  • קישוריות היברידית עם יתירות: מגדירים מצורפים ל-VLAN של Cloud Interconnect או מנהרות HA VPN עם יתירות בכמה אזורים ודומיינים של זמינות בקצה הרשת, בשילוב עם נתבי Cloud Router עם יתירות, כדי לאפשר יתירות כשל דינמית של BGP בין הרשת החיצונית לבין רשת ה-VPC לניתוב.
  • אחסון ואיזון עומסים במספר אזורים: כדי להבטיח זמינות גבוהה באזורים שונים, השתמשו במאזן עומסים פנימי של אפליקציות (ALB) באזורים שונים כדי לפזר את תעבורת הנתונים של ההסקה בין הקצה הקדמי לבין הקצה העורפי שמספק את השירות במספר אזורים. בנוסף, השתמשו בקטגוריות של Cloud Storage בשני אזורים או במספר אזורים עם מאגרי נתונים וקטוריים משוכפלים.
  • הטמעה אסינכרונית ועמידות במכסות: הפרדה בין העלאות של נתונים גולמיים לקטגוריה של Cloud Storage לבין צינור עיבוד הנתונים של ההטמעה, באמצעות Pub/Sub עם נושאים להודעות ללא מוצא או כללי מדיניות של Eventarc לניסיונות חוזרים. כך אפשר לנסות שוב הטמעה או הוספה לאינדקס שנכשלו באופן זמני, בלי לאבד נתונים. כדי לקבל זמן אחזור וקיבולת צפויים במהלך יצירת הטמעות והסקת מסקנות בנפח גבוה, כדאי להזמין הקצאת משאבים לפי התפוקה שנקבעה ולהטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) לתגובות HTTP 429.

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

הוזלת עלויות

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

  • תעבורת נתונים יוצאת (egress) ברשת ובחירת נקודות קצה: כדי להימנע מחיובים על העברת נתונים בין אזורים שונים דרך ה-spokes של NCC, הציבו באותו אזור את רשת ה-VPC לניתוב, את נקודות הקצה של Private Service Connect, את הקטגוריה של Cloud Storage, את מאגר הנתונים של RAG ואת נקודות הקצה של המודל. כדי להפחית את החיובים השעתיים על נקודות קצה ועיבוד נתונים, כדאי לאחד את נקודות הקצה המשותפות של Private Service Connect ברשת ה-VPC המארחת או המנתבת.
  • ניהול מחזור החיים של האחסון: מגדירים את ניהול מחזור החיים של אובייקטים ב-Cloud Storage או Autoclass בקטגוריית הטמעת הנתונים הגולמיים, כדי להעביר מסמכי מקור מעובדים לסוגי אחסון (storage class) קרים יותר או למחוק קובצי Staging אחרי שהווקטורים נכתבים במאגר הנתונים של RAG.
  • הטמעה באצווה ושמירת הקשר במטמון: כדי לעדכן קורפוס RAG גדול ולא דחוף בתת-המערכת של הטמעת הנתונים, השתמשו בחיזוי באצווה להטמעות או בהסקת מסקנות באצווה בעלות נמוכה יותר מאשר בקשות אונליין. כדי להפחית את העלויות של טוקנים לקלט, בתת-המערכת של הצגת המודעות, הפעילו את האפשרות שמירת הקשר במטמון להוראות מערכת חוזרות ולמסמכי עזר שמאוחזרים לעיתים קרובות.

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

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

כדי להפעיל ולנהל ביעילות את תשתית הרשת וה-RAG, כדאי לפעול לפי ההמלצות הבאות:

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

אופטימיזציה של הביצועים

כדי לשפר את הביצועים של עומסי העבודה ברשת וב-RAG, כדאי לפעול לפי ההמלצות הבאות:

  • רוחב פס היברידי ומיקום משותף אזורי: הגדירו את הגודל של הצירופים ל-VLAN ב-Cloud Interconnect או של מנהרות Cloud VPN כך שיוכלו לטפל בנפחי העלאה של נתונים גולמיים בשיא מהרשת החיצונית, בלי להעמיס על רוחב הפס שמשותף עם בקשות הסקה אינטראקטיביות. כדי לצמצם את זמן האחזור של התקשורת הלוך ושוב ברשת, כדאי למקם את נקודת הקצה האזורית של Private Service Connect, את הקטגוריה של Cloud Storage, את מאגר הנתונים הווקטורי (כמו חיפוש וקטורי או AlloyDB ל-PostgreSQL) ואת נקודות הקצה של המודל באזור שהכי קרוב לנקודת הנוכחות (PoP) של החיבור ההיברידי.
  • שינוי קנה המידה של המחשוב וניתוב ההסקה: אם תת-המערכת של ממשק המשתמש או של ההצגה פועלת ב-Cloud Run, צריך להגדיר מינימום מכונות ולכוונן את הגדרות בו-הזמניות כדי למנוע זמן אחזור של התחלה קרה במהלך עליות חדות בתנועה. אם אתם מציגים מודלים פתוחים ב-GKE, השתמשו ב-Inference Gateway כדי לבצע ניתוב מבוסס-מטמון KV ומבוסס-עומס בין שרתי המודלים.

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

פריסה

בקטע הזה מוסבר איך ליצור את האפליקציה:

  1. זיהוי האזור של עומסי העבודה.
  2. יוצרים Google Cloud פרויקטים ורשתות VPC.
  3. מחברים את הרשתות החיצוניות לרשת ה-VPC לניתוב.
  4. קישור רשתות באמצעות NCC
  5. זיהוי רכיבים לפריסת RAG ויצירת חשבונות שירות.
  6. הגדרת VPC Service Controls.
  7. בניית תת-מערכת להטמעת נתונים.
  8. בניית תת-מערכת להצגת מודעות.
  9. בניית תת-המערכת של הקצה הקדמי.
  10. הגדרת האפליקציה כך שתהיה נגישה מהאינטרנט.

זיהוי האזור של עומסי העבודה

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

יצירת Google Cloud פרויקטים ורשתות VPC

אם הארגון שלכם כבר הגדיר Cross-Cloud Network לאפליקציות מבוזרות, פרויקט הניתוב ורשת ה-VPC לניתוב כבר אמורים להיות קיימים.

יוצרים את Google Cloud הפרויקטים ורשת VPC בסדר הבא:

  1. יוצרים את פרויקט הניתוב.
  2. יוצרים את רשת ה-VPC לניתוב עם גישה פרטית ל-Google.
  3. יוצרים את פרויקט ה-RAG.
  4. קידום פרויקט ה-RAG לפרויקט מארח של VPC משותף.
  5. יוצרים את הפרויקט של שירות הטמעת הנתונים.
  6. יוצרים את פרויקט השירות להצגת מודעות.
  7. יוצרים את פרויקט השירות של הקצה הקדמי.
  8. יוצרים את רשת ה-RAG של ה-VPC המשותף עם גישה פרטית ל-Google.
  9. נותנים לפרויקטים של השירות הרשאה להשתמש ברשת RAG.

חיבור הרשתות החיצוניות לרשת ה-VPC לניתוב

אם כבר הגדרתם את Cross-Cloud Network לאפליקציות מבוזרות, אתם יכולים לדלג על השלב הזה.

מגדירים את הקישוריות בין הרשתות החיצוניות לבין רשת הניתוב. כדי להבין את הטכנולוגיות הרלוונטיות, קראו את המאמר קישוריות חיצונית והיברידית. במאמר בחירת מוצרים של Network Connectivity מוסבר איך לבחור מוצר קישוריות.

  1. בפרויקט הניתוב, יוצרים מרכז NCC.
  2. מוסיפים את החיבורים של Cloud Interconnect בתור VLAN attachment spokes, או מוסיפים את החיבורים של Cloud VPN בתור VPN spokes.
  3. מוסיפים את רשת ה-VPC של RAG ואת רשת ה-VPC של הניתוב ל-Hub בתור VPC spokes.

זיהוי רכיבים לפריסת RAG ויצירת חשבונות שירות

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

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

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

הגדרת VPC Service Controls

  1. יוצרים גבולות גזרה של VPC Service Controls מסביב לפריסה.
  2. הגדרת כללי גישה.

בניית תת-מערכת להטמעת נתונים

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

  1. בפרויקט של שירות הטמעת הנתונים, יוצרים קטגוריה של Cloud Storage.
  2. ברשת ה-VPC לניתוב, יוצרים נקודת קצה אזורית של Private Service Connect ומחברים אותה לקטגוריה.
  3. ברשת החיצונית, מוסיפים רשומת DNS לנקודת הקצה באמצעות כתובת ה-IP וכתובת ה-URL שנוצרו בשלב הקודם.
  4. מעדכנים את הכללים של חומת האש ברשת החיצונית כדי לאפשר גישה לכתובת ה-IP של נקודת הקצה.
  5. בפרויקט של שירות הטמעת הנתונים, בונים את שאר צינור עיבוד הנתונים להטמעה בהתאם לארכיטקטורת ה-RAG שבחרתם.
  6. נותנים הרשאות IAM כדי שהמשאב הרלוונטי בצינור עיבוד הנתונים להטמעה יוכל לגשת למודל שמפיק את הווקטורים.
  7. נותנים הרשאות IAM כדי שהמשאב הרלוונטי בצינור עיבוד הנתונים להטמעה יוכל לכתוב במאגר הנתונים של הווקטורים.

בניית תת-מערכת להצגת מודעות

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

בניית תת-המערכת של הקצה הקדמי

בקטע הזה אנחנו מניחים שאתם משתמשים במאזן עומסים פנימי של אפליקציות (ALB) ברמת האזור, שמשתמש בקבוצת נקודות קצה של רשת (NEG) בלי שרת (serverless) לפני Cloud Run. עם זאת, אפשר להשתמש במאזן עומסים וב-backend אחרים.

  1. יוצרים את הקוד למערכת החזיתית.
  2. בפרויקט של שירות הקצה הקדמי, פורסים את מערכת הקצה הקדמי עם איזון העומסים, כולל השלב האופציונלי של הגדרת מדיניות אבטחה ב-Cloud Armor.
  3. מגדירים את Cloud Router ברשת ה-VPC לניתוב כדי להעביר נתיבים מרשת ה-VPC של RAG לנתבים המקומיים. ההגדרה הזו מאפשרת ללקוחות להגיע למאזן העומסים של האפליקציות.
  4. ברשת החיצונית, מגדירים את כללי חומת האש כך שיהיה אפשר להגיע אל ממשק ה-frontend של מאזן העומסים מהרשת החיצונית.
  5. ברשת החיצונית, מעדכנים את ה-DNS כך שיפנה לכלל ההעברה של מאזן העומסים של האפליקציות (ALB).

איך מאפשרים גישה לאפליקציה מהאינטרנט

הקטע הזה הוא אופציונלי.

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

כדי שהשירות יהיה נגיש מהאינטרנט:

  1. יוצרים מאזן עומסים חיצוני אזורי של אפליקציות (ALB) שמפנה לאותו קצה עורפי שאליו מפנה מאזן העומסים הפנימי של האפליקציות (ALB). מבצעים את השלב האופציונלי להגדרת מדיניות אבטחה של Cloud Armor.
  2. עדכון של VPC Service Controls כדי לאפשר ללקוחות של השירות להגיע לשירותים לקצה העורפי.

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

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

מחברים:

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