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

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

תהליך האימון

האימון מורכב מזרימות נתונים בין לקוח FC לבין שרת FC. FC Client הוא מודול ליבה של Android שמכשיר מודלים של למידת מכונה במכשיר ומתקשר עם FC Server. שרת ה-FC מעבד ומצטבר את התוצאות מלקוח ה-FC בצורה מאובטחת בסביבת מחשוב אמינה (TEE).

האימון כולל את השלבים הבאים:

1. לקוח FC במכשיר מוריד מפתח ציבורי להצפנה משירותי המפתחות.
2. לקוח ה-FC מתחבר לשרת ה-FC ומקבל משימת אימון.
3. אפליקציית הלקוח של FC מורידה תוכנית אימונים, וגם את הגרסה העדכנית של המודל, גרסה N.
4. לקוח ה-FC מתאמן באמצעות הנתונים המקומיים והתוכנית.
5. לקוח ה-FC מצפין את התרומות של המכשיר באמצעות המפתח הציבורי שהתקבל בשלב 0 ומעלה אותן לשרת ה-FC.
6. לקוח ה-FC מודיע לשרת ה-FC שהאימון שלו הסתיים.
7. השרת של FC ממתין עד שמספיק לקוחות ישלחו את התרומות שלהם.
8. מופעלת צבירת נתונים.
9. הנתונים המוצפנים נטענים על ידי שירות הצבירה לתוך סביבת מחשוב אמינה (TEE).
10. האגרגטור מאמת את עצמו, בהתאם לארכיטקטורה של RFC 9334 Remote ATtestation procedureS (RATS)‎ של NIST, מול הרכזים. אם האימות יצליח, שירותי המפתחות יעניקו לו את מפתחות הפענוח. יכול להיות שהמפתחות האלה יפוצלו בין כמה ספקי מפתחות במסגרת תוכנית Shamir secret sharing.
11. האגרגטור מבצע צבירה בין מכשירים, חיתוך ורעשים לפי מנגנוני פרטיות דיפרנציאלית (DP) מתאימים, ומפיק את התוצאות עם הרעשים.
12. האגרגטור מפעיל את כלי עדכון המודלים.
13. הכלי לעדכון מודלים טוען את התרומה המצטברת ומחיל אותה על מודל גרסה N כדי ליצור מודל גרסה N + 1. המודל החדש מועבר לאחסון המודלים.

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

ארכיטקטורה ברמה גבוהה

רכיבי ה-FC Server הבאים נפרסים ב-Google Cloud:

רכיב	תיאור
שירות לניהול משימות	שירות אינטרנט לניהול משימת האימון. השותפים צריכים להשתמש ב-Task Management API כדי ליצור משימת אימון, להציג רשימה של כל משימות האימון הקיימות, לבטל משימה ולאחזר את כל סטטוסי האימון.
שירות הקצאת משימות	שירות אינטרנט מבוסס-HTTPS שבו מכשירי הלקוח מתחברים מדי פעם כדי לקבל משימות אימון ולדווח על סטטוס האימון.
אתר אגרגטור	שירות ברקע שפועל ב-Confidential Space. הוא מריץ עומסי עבודה שנוצרו על ידי ODP. הם צריכים לאמת את עצמם מול רכיבי התיאום, שמגנים על הגישה למפתחות ההצפנה. רק אגרגטורים שעברו אימות יכולים לפענח תכנים שנוספו על ידי מכשירי לקוח ולבצע אגרגציה בין מכשירים.
כלי לעדכון מודלים	שירות ברקע שפועל ב-Confidential Space ומחיל את הגרדיאנטים המצטברים על המודל.

פרטי הרכיב

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

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

שירות ניהול המשימות מכיל שני רכיבי משנה: שירות האינטרנט לניהול משימות ושירות מתזמן המשימות, שניהם נפרסים ב-GKE.

ניהול משימות

זהו אוסף של שירותי אינטרנט לקצה חזיתי שמקבלים בקשות HTTPS ויוצרים משימות או מאחזרים משימות ממסד הנתונים של המשימות.

מתזמן המשימות

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

מסד נתונים של משימות

מסד נתונים תואם ANSI SQL שבו מאוחסנים פרטי המשימה, האיטרציה וההקצאה. בהטמעה הזו, Google Cloud Spanner משמש כשירות מסד הנתונים הבסיסי.

שירות הקצאת משימות

שירות הקצאת המשימות הוא שירות אינטרנט חזיתי שמתארח ב-GKE. הוא מקבל בקשות מלקוחות FC ומפיץ משימות אימון כשזה רלוונטי.

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

Aggregator Service

כלי לעדכון מודלים ואגרגטורים

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

מעברי צבע, מעברי צבע מצטברים, מודל ותוכנית

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

תוכנת Collector

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

מארחי שירות

כל השירותים שאין להם גישה למידע רגיש מתארחים ב-GKE.

כל השירותים שעשויים לגעת במידע רגיש מתארחים במרחב סודי.

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

ביחידת שירות אחת, משאב המחשוב נראה כך:

מדרגיות

התשתית שתוארה קודם מתמקדת ביחידת שירות אחת.

יחידת שירות אחת משתמשת ב-Cloud Spanner אחד. במאמר מכסות ומגבלות ב-Spanner מפורטות מגבלות חשובות.

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

• שירות אינטרנט להקצאת משימות
• שירות אינטרנט לניהול משימות
• מכונות של אתרי אגרגטור
• Model Updater Instances

חוסן

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

Spanner

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

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

ב-Spanner מתועדת היסטוריית השינויים. הנתונים נשמרים ב-Aggregator וב-Model Updater לפי סבב אימון, והתוצאה של כל סבב נשמרת בנפרד בלי לדרוס את התוצאות של סבבים אחרים. לכן, במקרה של אסון, השירות יכול להתחדש מהסבב האחרון של האימון.

Google Cloud Storage

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

העיצוב כולל שלוש דוגמאות של GCS:

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

הנתונים שמאוחסנים ב-GCS הם:

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

כדאי להעריך את האיזון בין עקביות לזמינות ולבחור את התכונות המתאימות של זמינות ועמידות נתונים ב-GCS. מומלץ לציין מדיניות משלכם בנושא שמירת נתונים.

שכפול וגיבויים

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