למידה משותפת (Federated) חוצת-סילו ומקושרת למכשיר אחר ב-Google Cloud

Last reviewed 2024-06-03 UTC

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

  • למידה משותפת (Federated) בין סילו
  • למידה משותפת (Federated) מקושרת למכשיר אחר, שמבוססת על ארכיטקטורה חוצת-סילו

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

ארכיטקטורה

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

ארכיטקטורה חוצת-סילו

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

ארכיטקטורה חוצת-סילו, הרכיבים מתוארים בטקסט הבא.

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

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

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

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

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

  • רשת של ענן וירטואלי פרטי (VPC) ותת-רשת.
  • אשכול GKE פרטי שעוזר לכם לבצע את הפעולות הבאות:
    • בידוד של צמתי האשכול מהאינטרנט.
    • כדי להגביל את החשיפה של צמתי האשכול ומישור הבקרה לאינטרנט, אפשר ליצור אשכול GKE פרטי עם רשתות מורשות.
    • שימוש בצמתים מוגנים באשכול שמשתמשים בתמונה של מערכת הפעלה מאובטחת.
    • הפעלה של Dataplane V2 לטובת אופטימיזציה של רשתות Kubernetes.
  • מאגרי צמתים ייעודיים ל-GKE: אתם יוצרים מאגר צמתים ייעודי לאירוח בלעדי של אפליקציות ומשאבים של הדייר. לצמתים יש taints כדי לוודא שרק עומסי עבודה של דיירים מתוזמנים בצמתים של הדיירים. משאבים אחרים באשכול מתארחים במאגר הצמתים הראשי.

  • הצפנת נתונים (מופעלת כברירת מחדל):

  • הצפנת נתונים בשימוש באמצעות הפעלה אופציונלית של Confidential Google Kubernetes Engine Nodes.

  • כללי חומת אש של VPC שחלים על הדברים הבאים:

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

  • ‫Cloud NAT כדי לאפשר תעבורת נתונים יוצאת לאינטרנט.

  • רשומות Cloud DNS כדי להפעיל גישה פרטית ל-Google כך שאפליקציות באשכול יוכלו לגשת ל-Google APIs בלי לעבור דרך האינטרנט.

  • חשבונות שירות, שהם:

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

  • תמיכה בשימוש בקבוצות Google לבקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes.

  • מאגר Git לאחסון של מתארי הגדרות.

  • מאגר Artifact Registry לאחסון קובצי אימג' של קונטיינרים.

  • ‫סנכרון תצורות ו-Policy Controller כדי לפרוס הגדרות וכללי מדיניות.

  • שערי Cloud Service Mesh כדי לאפשר באופן סלקטיבי תעבורת נתונים נכנסת (ingress) ויוצאת (egress) באשכול.

  • ‫קטגוריות של Cloud Storage לאחסון משקלים של מודלים גלובליים ומקומיים.

  • גישה ל-Google ולממשקי API אחרים Google Cloud . לדוגמה, יכול להיות שעומס עבודה של אימון יצטרך לגשת לנתוני אימון שמאוחסנים ב-Cloud Storage, ב-BigQuery או ב-Cloud SQL.

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

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

ארכיטקטורה מקושרת למכשיר אחר, הרכיבים מוסברים בטקסט הבא.

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

  • שירות Cloud Run שמדמה מכשירים שמתחברים לשרת
  • Certificate Authority Service שיוצר אישורים פרטיים לשרת וללקוחות כדי להפעיל
  • ‫Vertex AI TensorBoard להצגת התוצאה של האימון
  • קטגוריה של Cloud Storage לאחסון המודל המאוחד
  • אשכול GKE פרטי שמשתמש בצמתים סודיים כמאגר הראשי שלו כדי לעזור לאבטח את הנתונים שבשימוש

הארכיטקטורה של התכונה 'המשכיות בין מכשירים' מבוססת על רכיבים מפרויקט Federated Compute Platform ‏ (FCP) של קוד פתוח. הפרויקט הזה כולל את הפריטים הבאים:

  • קוד לקוח לתקשורת עם שרת ולביצוע משימות במכשירים
  • פרוטוקול לתקשורת בין לקוחות לשרתים
  • נקודות חיבור ל-TensorFlow Federated כדי להקל על הגדרת החישובים המאוחדים

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

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

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

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

‫GKE מספק גם את היכולות הבאות לפלטפורמת הלמידה המאוחדת שלכם:

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

בנוסף ליתרונות האלה, GKE מספק גם מספר תכונות שיכולות להיות שימושיות לפריסות של למידה מאוחדת, כמו התכונות הבאות:

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

‫TFF מספק את התכונות הבאות כדי להקל על ההטמעה של תרחישי שימוש של למידה מאוחדת:

  • היכולת להגדיר חישובים מאוחדים, שהם קבוצה של שלבי עיבוד שמופעלים בשרת ובקבוצה של לקוחות. אפשר לפרוס את החישובים האלה בסביבות זמן ריצה שונות.
  • אפשר ליצור צוברים מותאמים אישית באמצעות קוד פתוח של TFF.
  • תמיכה במגוון אלגוריתמים של למידה משותפת (Federated), כולל האלגוריתמים הבאים:
    • ממוצע משוקלל מאוחד: אלגוריתם שמחשב את הממוצע של פרמטרי המודל של לקוחות משתתפים. הוא מתאים במיוחד לתרחישי שימוש שבהם הנתונים הומוגניים יחסית והמודל לא מורכב מדי. תרחישים נפוצים לדוגמה:
      • המלצות מותאמות אישית: חברה יכולה להשתמש בממוצע משוקלל מאוחד כדי לאמן מודל שממליץ למשתמשים על מוצרים על סמך היסטוריית הרכישות שלהם.
      • זיהוי תרמיות: קבוצה של בנקים יכולה להשתמש בממוצע משוקלל מאוחד כדי לאמן מודל שמזהה עסקאות שמקורן בתרמית.
      • אבחון רפואי: קבוצה של בתי חולים יכולה להשתמש בממוצע משוקלל מאוחד כדי לאמן מודל שמבצע אבחון של סרטן.
    • ירידה סטוכסטית של גרדיאנטים משותפים (FedSGD): אלגוריתם שמשתמש בירידה סטוכסטית של גרדיאנטים כדי לעדכן את פרמטרי המודל. הוא מתאים במיוחד לתרחישי שימוש שבהם הנתונים הטרוגניים והמודל מורכב. תרחישים נפוצים לדוגמה:
      • עיבוד שפה טבעית (NLP): חברה יכולה להשתמש ב-FedSGD כדי לאמן מודל שמשפר את הדיוק של זיהוי הדיבור.
      • זיהוי תמונות: חברה יכולה להשתמש ב-FedSGD כדי לאמן מודל שיכול לזהות אובייקטים בתמונות.
      • תחזוקה חזויה (PdM): חברה יכולה להשתמש ב-FedSGD כדי לאמן מודל שמנבא מתי מכונה עלולה להיכשל.
    • ‫Federated Adam: אלגוריתם שמשתמש באופטימיזציה של Adam כדי לעדכן את פרמטרים של המודל. תרחישים נפוצים לדוגמה:
      • מערכות המלצה: חברה יכולה להשתמש ב-Federated Adam כדי לאמן מודל שממליץ למשתמשים על מוצרים על סמך היסטוריית הרכישות שלהם.
      • דירוג: חברה יכולה להשתמש ב-Adam מאוחד כדי לאמן מודל שמדרג תוצאות חיפוש.
      • חיזוי של שיעור הקליקים: חברה יכולה להשתמש ב-Adam המאוחד כדי לאמן מודל שמנבא את הסבירות שמשתמש ילחץ על מודעה.

תרחישים לדוגמה

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

למידה משותפת (Federated) היא הגדרה של למידת מכונה שבה הרבה לקוחות מאמנים מודל ביחד. התהליך הזה מנוהל על ידי רכז מרכזי, ונתוני האימון נשארים מבוזרים.

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

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

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

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

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

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

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

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

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

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

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

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

הנה כמה תרחישים לדוגמה ללמידה מאוחדת חוצת-סילו:

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

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

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

הנה כמה תרחישי שימוש לדוגמה ללמידה משותפת (Federated) מקושרת למכשיר אחר:

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

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

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

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

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

שיקולים בתכנון ארכיטקטורה חוצת-סילו

כדי להטמיע ארכיטקטורה של למידה מאוחדת חוצת-סילו ב-Google Cloud, צריך להטמיע את תנאי הסף המינימליים הבאים, שמוסברים בפירוט רב יותר בקטעים הבאים:

  1. הקמת קונסורציום ללמידה משותפת (Federated).
  2. קובעים את מודל שיתוף הפעולה שבו ישתמש קונסורציום הלמידה המשותפת.
  3. קובעים את האחריות של הארגונים המשתתפים.

בנוסף לדרישות המוקדמות האלה, יש פעולות נוספות שבעלי הפדרציה צריכים לבצע, שלא נכללות במסגרת המסמך הזה, כמו:

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

הקמת קונסורציום ללמידה משותפת (Federated)

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

קביעת מודל שיתוף פעולה לקונסורציום של למידה משותפת (Federated)

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

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

במסמך הזה אנחנו מניחים שמודל שיתוף הפעולה הוא מודל ריכוזי.

הגדרת האחריות של הארגונים המשתתפים

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

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

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

הארגונים המשתתפים אחראים לדברים הבאים:

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

הבעלים של הפדרציה והארגונים המשתתפים יכולים להשתמש ב-Cloud Storage כדי לשתף מודלים מעודכנים ותוצאות אימון.

הבעלים של הפדרציה והארגונים המשתתפים משפרים את האימון של המודל ללמידת מכונה עד שהמודל עומד בדרישות שלהם.

הטמעת למידה משותפת (Federated) ב- Google Cloud

אחרי שמקימים את קבוצת הארגונים ללמידה מאוחדת וקובעים איך קבוצת הארגונים ללמידה מאוחדת תשתף פעולה, מומלץ לארגונים המשתתפים לבצע את הפעולות הבאות:

  1. הקצאה והגדרה של התשתית הנדרשת לקונסורציום ללמידה מאוחדת.
  2. הטמעה של מודל שיתוף הפעולה.
  3. איך מתחילים להשתמש בלמידה משותפת

הקצאה והגדרה של התשתית עבור קונסורציום ללמידה משותפת

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

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

הטמעה של מודל שיתוף הפעולה

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

התחלת תהליך הלמידה המשותפת (Federated)

אחרי הטמעת מודל שיתוף הפעולה, הבעלים של הפדרציה מטמיע את המודל הגלובלי של למידת מכונה (ML) כדי לאמן את המודלים של למידת מכונה ולשתף אותם עם הארגון המשתתף. אחרי שהמודלים האלה של למידת מכונה מוכנים, הבעלים של הפדרציה מתחיל את הסבב הראשון של מאמץ הלמידה המאוחדת.

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

  1. מפיץ את מודלי ה-ML לשיתוף עם הארגונים המשתתפים.
  2. המערכת ממתינה לארגונים המשתתפים שיספקו את תוצאות האימון של מודלים של למידת מכונה שבעלי הפדרציה שיתפו.
  3. איסוף ועיבוד של תוצאות האימון שהפיקו הארגונים המשתתפים.
  4. עדכון המודל הגלובלי ללמידת מכונה כשמתקבלות תוצאות הדרכה מתאימות מארגונים משתתפים.
  5. עדכון של מודלים של ML לשיתוף עם שאר חברי הקונסורציום, כשזה רלוונטי.
  6. הכנת נתוני האימון לסבב הבא של למידה משותפת (Federated).
  7. מתחיל את הסיבוב הבא של למידה משותפת.

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

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

עומסי העבודה של למידה משותפת (Federated) שאתם פורסים בסביבות שלכם עשויים לחשוף אתכם, את הנתונים שלכם, את המודלים של למידה משותפת (Federated) ואת התשתית שלכם לאיומים שעשויים להשפיע על העסק שלכם.

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

אמצעי בקרה לאבטחה ב-GKE

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

אבטחה משופרת של אשכולות GKE

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

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

כללי חומת אש ב-VPC

כללי חומת האש של הענן הווירטואלי הפרטי (VPC) קובעים איזו תעבורה מותרת למכונות וירטואליות של Compute Engine או מהן. הכללים מאפשרים לכם לסנן תעבורה ברמת המכונה הווירטואלית, בהתאם למאפיינים של שכבה 4.

יוצרים אשכול GKE עם כללי ברירת המחדל של חומת האש באשכול GKE. כללי חומת האש האלה מאפשרים תקשורת בין צמתי האשכול לבין מישור הבקרה של GKE, ובין צמתים לבין Pods באשכול.

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

מרחבי שמות

מרחבי שמות מאפשרים לספק היקף למשאבים קשורים באשכול – לדוגמה, Pods,‏ Services ו-replication controllers. באמצעות מרחבי שמות, אפשר להעביר את האחריות האדמיניסטרטיבית למשאבים הקשורים כיחידה אחת. לכן, מרחבי שמות הם חלק בלתי נפרד מרוב דפוסי האבטחה.

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

גישה נפוצה היא ליצור מרחבי שמות לאפליקציות ספציפיות. לדוגמה, אפשר ליצור את מרחב השמות myapp-frontend לרכיב ממשק המשתמש של אפליקציה.

ארכיטקטורות ההפניה האלה עוזרות לכם ליצור מרחב שמות ייעודי לאירוח אפליקציות צד שלישי. מרחב השמות והמשאבים שלו נחשבים לדייר (tenant) באשכול. אתם יכולים להחיל מדיניות ואמצעי בקרה על מרחב השמות כדי להגביל את היקף המשאבים במרחב השמות.

כללי מדיניות הרשת

כללי מדיניות לרשת אוכפים זרימות של תעבורת רשת בשכבה 4 באמצעות כללי חומת אש ברמת ה-Pod. מדיניות הרשת מוגבלת למרחב שמות.

בארכיטקטורות ההפניה שמתוארות במסמך הזה, אתם מחילים מדיניות רשת על מרחב השמות של הדייר שמארח את האפליקציות של צד שלישי. כברירת מחדל, מדיניות רשת ב-Kubernetes דוחה את כל התעבורה אל ומקבוצות ה-Pod במרחב השמות. צריך להוסיף באופן מפורש לרשימת ההיתרים את כל התנועה הנדרשת. לדוגמה, מדיניות הרשת בארכיטקטורות ההפניה האלה מאפשרת במפורש תעבורה לשירותי אשכול נדרשים, כמו DNS פנימי של האשכול ומישור הבקרה של Cloud Service Mesh.

סנכרון תצורות

‫סנכרון תצורות שומר על סנכרון בין אשכולות GKE לבין הגדרות שמאוחסנות במקור אמת. מאגר Git משמש כמקור אמת יחיד לגבי ההגדרות והמדיניות של האשכול. ‫סנכרון תצורות הוא דקלרטיבי. הוא בודק באופן רציף את מצב האשכול ומחיל את המצב שמוצהר בקובץ ההגדרות כדי לאכוף את מדיניות ההרשאות, וכך עוזר למנוע סחף בהגדרות.

מתקינים את סנכרון תצורות באשכול GKE. מגדירים את סנכרון תצורות לסנכרון של תצורות ומדיניות של אשכולות ממקור האמת. רשימת המשאבים שמסונכרנים כוללת את המשאבים הבאים:

  • הגדרת Cloud Service Mesh ברמת האשכול
  • כללי מדיניות אבטחה ברמת האשכול
  • הגדרה ומדיניות ברמת מרחב השמות של הדייר, כולל מדיניות רשת, חשבונות שירות, כללי RBAC והגדרה של Cloud Service Mesh

Policy Controller

‫Policy Controller הוא dynamic admission controller ל-Kubernetes שמחיל מדיניות מבוססת CustomResourceDefinition (CRD) שמופעלת על ידי Open Policy Agent (OPA).

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

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

Cloud Service Mesh

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

  • הוספה אוטומטית של פרוקסי מסוג sidecar.
  • הוא אוכף תקשורת mTLS בין שירותים ברשת.
  • מגבילה את התנועה היוצאת ברשת Mesh רק למארחים מוכרים.
  • מגבילה תנועה נכנסת רק מלקוחות מסוימים.
  • מאפשרת להגדיר מדיניות אבטחת רשת על סמך זהות השירות ולא על סמך כתובת ה-IP של עמיתים ברשת.
  • הגבלות על תקשורת מורשית בין שירותים ברשת. לדוגמה, אפליקציות במרחב השמות של הדייר יכולות לתקשר רק עם אפליקציות באותו מרחב שמות, או עם קבוצה של מארחים חיצוניים מוכרים.
  • התכונה הזו מעבירה את כל התנועה הנכנסת והיוצאת דרך שערי רשת, שבהם אפשר להחיל אמצעי בקרה נוספים על התנועה.
  • תמיכה בתקשורת מאובטחת בין אשכולות.

דחיות (taints) וזיקות (affinities) של צמתים

Node taints וnode affinity הם מנגנונים של Kubernetes שמאפשרים להשפיע על האופן שבו קבוצות Pod מתוזמנות בצמתי אשכולות.

צמתים עם כתמים דוחים פודים. מערכת Kubernetes לא תתזמן Pod בצומת עם דחייה (taint), אלא אם ל-Pod יש טולרנטיות לדחייה (taint). אפשר להשתמש ב-taints של צמתים כדי לשריין צמתים לשימוש רק על ידי עומסי עבודה או דיירים מסוימים. לרוב משתמשים ב-Taints וב-Tolerations באשכולות מרובי דיירים. מידע נוסף זמין במאמר בנושא צמתים ייעודיים עם כתמי רעל וסבילות.

התכונה Node affinity מאפשרת להגביל את הפודים לצמתים עם תוויות מסוימות. אם יש לקבוצת Pod דרישה של התאמה לצומת, Kubernetes לא מתזמן את ה-Pod לצומת אלא אם לצומת יש תווית שתואמת לדרישת ההתאמה. אפשר להשתמש בהעדפת צומת כדי לוודא שהפודים מתוזמנים לצמתים המתאימים.

אפשר להשתמש יחד ב-node taints וב-node affinity כדי לוודא שפודים של עומסי עבודה של דיירים מתוזמנים באופן בלעדי לצמתים ששמורים לדייר.

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

  • יצירת מאגר צמתים ב-GKE שמוקדש לדייר. לכל צומת במאגר יש taint שקשור לשם הדייר.
  • החלה אוטומטית של טולרנטיות וזיקה לצומת מתאימות על כל Pod שמטרגט את מרחב השמות של הדייר. אתם מחילים את הטולרנטיות והזיקה באמצעות שינויים ב-PolicyController.

הרשאות מינימליות

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

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

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

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

  • יוצרים תפקיד לדוגמה ב-RBAC ב-Kubernetes עם הרשאות מוגבלות לניהול אפליקציות. אתם יכולים להעניק את התפקיד הזה למשתמשים ולקבוצות שמפעילים את האפליקציות במרחב השמות של הדייר. התפקיד המוגבל הזה מאפשר למשתמשים ולקבוצות לשנות רק את משאבי האפליקציה במרחב השמות של הדייר. אין להם הרשאות לשנות משאבים ברמת האשכול או הגדרות אבטחה רגישות כמו מדיניות Cloud Service Mesh.

Binary Authorization

Binary Authorization מאפשרת לאכוף מדיניות שאתם מגדירים לגבי קובצי האימג' בקונטיינרים שנפרסים בסביבת GKE. ‫Binary Authorization מאפשר לפרוס רק קובצי אימג' של קונטיינרים שעומדים במדיניות שהגדרתם. היא אוסרת על פריסה של קובצי אימג' אחרים של קונטיינרים.

באדריכלות ההפניה הזו, Binary Authorization מופעל עם הגדרות ברירת המחדל שלו. כדי לבדוק את הגדרת ברירת המחדל של Binary Authorization, אפשר לעיין במאמר בנושא ייצוא קובץ ה-YAML של המדיניות.

מידע נוסף על הגדרת מדיניות מפורט במאמרים הבאים:

אימות הצהרות חוצה-ארגונים

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

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

  1. מקבלים את המפתחות הציבוריים שגורם הצד השלישי השתמש בהם כדי ליצור את האישורים שצריך לאמת.
  2. יוצרים את המאמתים כדי לאמת את האישורים.
  3. מוסיפים את המפתחות הציבוריים שקיבלתם מהצד השלישי למאמתים שיצרתם.

למידע נוסף על יצירת מאמתים, אפשר לעיין בהנחיות הספציפיות הבאות:

שיקולי אבטחה בלמידה משותפת (Federated)

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

האיומים הנפוצים ביותר על הטמעה של למידה מאוחדת הם:

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

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

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

בעלי הפדרציה צריכים לבצע גם את השלבים הנוספים הבאים:

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

אמינות

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

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

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

בהתאם לסוג האשכול ולאופן שבו מישור הבקרה וצמתי האשכול מפוזרים באזורים ובאזורי זמינות, GKE מציע יכולות שונות של תוכנית התאוששות מאסון (DR) כדי להגן על עומסי העבודה מפני הפסקות חשמל באזורי זמינות ובאזורים. מידע נוסף על יכולות ההתאוששות מאסון של GKE זמין במאמר תכנון התאוששות מאסון (DR) להפסקות בשירותי התשתית בענן: Google Kubernetes Engine.

‫Google Cloud Load Balancing: ב-GKE יש כמה דרכים לאיזון עומסים של תנועה בעומסי העבודה. הטמעות GKE של ממשקי ה-API של Kubernetes Gateway ושל Kubernetes Service מאפשרות הקצאה והגדרה אוטומטיות של Cloud Load Balancing כדי לחשוף בצורה מאובטחת ואמינה את עומסי העבודה שפועלים באשכולות GKE.

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

אתגרים באמינות של למידה משותפת (Federated) בין מכשירים

ללמידה מאוחדת מקושרת למכשיר אחר יש כמה אתגרים שקשורים לאמינות, שלא קיימים בתרחישים של למידה מאוחדת בין סילו. למשל:

  • קישוריות לא אמינה או לסירוגין של המכשיר
  • נפח האחסון במכשיר מוגבל
  • מגבלות על כוח המחשוב והזיכרון

חיבור לא אמין עלול לגרום לבעיות כמו:

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

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

אפשר לתכנן ארכיטקטורת מערכת שמריצה את פרוטוקול FCP כך שתעמוד בדרישות הבאות:

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

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

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

הוזלת עלויות

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

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

מידע נוסף על אופטימיזציה של העלויות בסביבות GKE זמין במאמר שיטות מומלצות להרצה של אפליקציות Kubernetes שעברו אופטימיזציה לעלויות ב-GKE.

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

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

כדי להגביר את האוטומציה והמעקב של ארכיטקטורת הלמידה המאוחדת, מומלץ לאמץ עקרונות של MLOps, שהם עקרונות של DevOps בהקשר של מערכות למידת מכונה. התפקיד שלכם הוא לתמוך באוטומציה ובמעקב בכל השלבים של בניית מערכת ML, כולל שילוב, בדיקה, הפצה, פריסה וניהול תשתית. מידע נוסף על MLOps זמין במאמר בנושא MLOps: Continuous delivery and automation pipelines in machine learning (MLOps: צינורות אספקה רציפה ואוטומציה בלמידת מכונה).

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

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

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

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

כדי לשפר את הביצועים של עומסי העבודה של ML, אפשר להשתמש ב-Cloud Tensor Processing Units (יחידות TPU בענן), מאיצי AI שפותחו על ידי Google ועברו אופטימיזציה לאימון ולהסקת מסקנות של מודלים גדולים של AI.

פריסה

כדי לפרוס את ארכיטקטורות העזר חוצות-הסילו ומקושרות למכשיר אחר שמתוארות במסמך הזה, אפשר לעיין במאגר GitHub‏ Federated Learning on Google Cloud.

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

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

מחברים:

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