אופטימיזציה של עומסי עבודה של AI ולמידת מכונה באמצעות Cloud Storage FUSE

Last reviewed 2025-08-22 UTC

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

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

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

ארכיטקטורה

בהתאם לדרישות שלכם לגבי ביצועים, זמינות והתאוששות מאסון (DR), אתם יכולים לבחור אחד מה Google Cloud ארכיטיפים של פריסה Google Cloudכדי להריץ את עומסי העבודה של AI ו-ML:

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

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

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

אזורי

בתרשים הבא מוצגת ארכיטקטורה אזורית לדוגמה שמשתמשת ב-Cloud Storage FUSE כדי לבצע אופטימיזציה של הביצועים של תהליכי העבודה של אימון המודל והצגת המודל:

ארכיטקטורה אזורית שמשתמשת ב-Cloud Storage FUSE כדי לבצע אופטימיזציה של עומסי עבודה של AI ו-ML.

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

  • אשכול GKE: GKE מנהל את צמתי החישוב שבהם פועלים תהליכי האימון וההפעלה של מודלים של AI ולמידת מכונה. ‫GKE מנהל את התשתית הבסיסית של אשכולות Kubernetes, כולל מישור הבקרה, הצמתים וכל רכיבי המערכת.
  • מתזמן Kubernetes: מישור הבקרה של GKE מתזמן עומסי עבודה ומנהל את מחזור החיים, ההרחבה והשדרוגים שלהם. הסוכן של צומת Kubernetes ‏ (kubelet), שלא מוצג בתרשים, מתקשר עם מישור הבקרה. הסוכן kubelet אחראי להפעלה ולהרצה של קונטיינרים שמתוזמנים בצמתי GKE. מידע נוסף על מתזמן המשימות זמין במאמר בנושא תזמור של AI/ML ב-GKE.
  • רשת ענן וירטואלי פרטי (VPC): כל המשאבים ב- Google Cloudמשתמשים ברשת VPC אחת. בהתאם לדרישות שלכם, אתם יכולים לבנות ארכיטקטורה שמשתמשת בכמה רשתות. מידע נוסף על הגדרת רשת VPC ל-Cloud Storage FUSE זמין במאמר האם כדאי ליצור כמה רשתות VPC.
  • ‫Cloud Load Balancing: בארכיטקטורה הזו, Cloud Load Balancing מחלק ביעילות את בקשות ההסקה הנכנסות ממשתמשי האפליקציה למאגרי ההגשה באשכול GKE. מידע נוסף זמין במאמר הסבר על איזון עומסים ב-GKE.
  • ‫יחידות לעיבוד גרפי (GPU) או ‫Tensor Processing Units (TPUs): מעבדי GPU ו-TPU הם מאיצי מכונה ייעודיים שמשפרים את הביצועים של עומסי העבודה של AI ו-ML. מידע על בחירת סוג מעבד מתאים מופיע בהמשך המאמר בקטע אפשרויות של מאיצים.
  • ‫Cloud Storage: שירות Cloud Storage מספק אחסון מתמשך, ניתן להרחבה וחסכוני לעומסי העבודה שלכם ב-AI וב-ML. ‫Cloud Storage משמש כמאגר מרכזי של מערכי נתונים לא מעובדים לאימון, נקודות ביקורת של מודלים ומודלים סופיים שעברו אימון.
  • ‫Cloud Storage FUSE עם מטמון קבצים מופעל: Cloud Storage FUSE מאפשר לטעון קטגוריה של Cloud Storage כמערכת קבצים מקומית. מטמון הקבצים ב-Cloud Storage FUSE הוא ספרייה במכונה המקומית שבה מאוחסנים קבצים שמתבצעת אליהם גישה לעיתים קרובות מהקטגוריות של Cloud Storage. מנהל התקן ה-CSI של Cloud Storage FUSE מנהל את השילוב בין Cloud Storage FUSE ל-Kubernetes API כדי לצרוך קטגוריות של Cloud Storage כנפחי אחסון.

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

במספר אזורים

בתרשים הבא מוצגת דוגמה לארכיטקטורה במספר אזורים שמשתמשת ב-Cloud Storage FUSE וב-Rapid Cache כדי לשפר את הביצועים של תהליכי העבודה של אימון המודל והצגת המודל:

ארכיטקטורה רב-אזורית שמשתמשת ב-Cloud Storage FUSE כדי לבצע אופטימיזציה של עומסי עבודה של AI ולמידת מכונה.

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

  • אשכול GKE: ‫GKE מנהל את צמתי החישוב שבהם מורצים תהליכי האימון וההצגה של מודלים של AI ו-ML. ‫GKE מנהל את התשתית הבסיסית של אשכולות Kubernetes, כולל רמת הבקרה, הצמתים וכל רכיבי המערכת.
  • מתזמן Kubernetes: מישור הבקרה של GKE מתזמן עומסי עבודה ומנהל את מחזור החיים, ההרחבה והשדרוגים שלהם. הסוכן של צומת Kubernetes ‏ (kubelet), שלא מוצג בתרשים, מתקשר עם מישור הבקרה. הסוכן kubelet אחראי להפעלה ולהרצה של קונטיינרים שמתוזמנים בצמתי GKE. מידע נוסף על מתזמן המשימות זמין במאמר בנושא תזמור של AI/ML ב-GKE.
  • רשת ענן וירטואלי פרטי (VPC): כל המשאבים ב- Google Cloudמשתמשים ברשת VPC אחת. בהתאם לדרישות שלכם, אתם יכולים לבנות ארכיטקטורה שמשתמשת בכמה רשתות. מידע נוסף על הגדרת רשת VPC ל-Cloud Storage FUSE זמין במאמר האם כדאי ליצור כמה רשתות VPC.
  • ‫Cloud DNS: בארכיטקטורות רב-אזוריות, שירות Cloud DNS מפנה תנועה למאזני העומסים כדי להבטיח ביצועים וזמינות אופטימליים באמצעות ניתוב anycast. הבקשות מנותבות אוטומטית למיקום הקרוב ביותר, מה שמקצר את זמן האחזור ומשפר את הביצועים של בדיקת שמות סמכותית עבור המשתמשים. למידע על עקרונות כלליים ושיטות מומלצות, אפשר לעיין במאמר בנושא שיטות מומלצות לשימוש ב-Cloud DNS.
  • ‫Cloud Load Balancing: בארכיטקטורה הזו, Cloud Load Balancing מפזר ביעילות בקשות הסקה נכנסות ממשתמשי האפליקציה למאגרי ההגשה באשכול GKE. מידע נוסף זמין במאמר הסבר על איזון עומסים ב-GKE.
  • ‫יחידות לעיבוד גרפי (GPU) או ‫Tensor Processing Units (TPUs): מעבדי GPU ו-TPU הם מאיצי מכונה ייעודיים שמשפרים את הביצועים של עומסי העבודה של AI ו-ML. מידע על בחירת סוג מעבד מתאים מופיע בהמשך המאמר בקטע אפשרויות של מאיצים.
  • ‫Cloud Storage: שירות Cloud Storage מספק אחסון מתמשך, ניתן להרחבה וחסכוני לעומסי העבודה שלכם ב-AI וב-ML. ‫Cloud Storage משמש כמאגר מרכזי של מערכי נתונים לא מעובדים לאימון, נקודות ביקורת של מודלים ומודלים סופיים שעברו אימון.
  • ‫Cloud Storage FUSE: ‏Cloud Storage FUSE מאפשר לטעון קטגוריה של Cloud Storage כמערכת קבצים מקומית. מנהל התקן ה-CSI של Cloud Storage FUSE, שלא מוצג בתרשים, מנהל את השילוב בין Cloud Storage FUSE ל-Kubernetes API כדי לצרוך קטגוריות של Cloud Storage כנפחי אחסון.
  • ‫Rapid Cache: ‫Rapid Cache היא תכונה של Cloud Storage שמספקת עד 1PiB של מטמון לקריאה בלבד באזורים שנתמכים על ידי SSD לקטגוריות של Cloud Storage. במהלך האימון וההצגה, Rapid Cache עוזר לצמצם את זמן האחזור של הקריאה ולהשיג תפוקה שעולה על 2TB/s על ידי שינוי גודל המטמון ורוחב הפס. כשמשלבים את Rapid Cache עם קטגוריות שפועלות במספר אזורים, אפשר להשתמש בו בכמה אזורים ובכמה אזורים גיאוגרפיים. מידע על אזורים ותחומים נתמכים זמין במאמר שמירת נתונים במטמון בתחומים.

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

עומס עבודה של אימון

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

  1. טעינת נתוני אימון ל-Cloud Storage: נתוני האימון מועלים לקטגוריה ב-Cloud Storage עם מרחבי שמות היררכיים. ‫Cloud Storage משמש כמאגר מרכזי ניתן להרחבה.
  2. טעינת נתוני אימון והפעלת משימות אימון ב-GKE: קטגוריית Cloud Storage שמותקנת ב-Pods של GKE מאפשרת לאפליקציות האימון לטעון את נתוני האימון ולגשת אליהם ביעילות באמצעות ממשק FUSE. הצמתים של GKE מריצים את תהליך אימון המודל באמצעות מטמון הקבצים שנטען כמקור הנתונים. אפליקציות האימון שלכם מספקות נתוני אימון למאיצי המכונה באופן רציף, כדי לבצע את החישובים המורכבים שנדרשים לאימון המודל. בהתאם לדרישות של עומס העבודה, אפשר להשתמש במעבדי GPU או TPU. מידע על בחירת סוג מעבד מתאים מופיע בהמשך המאמר בקטע אפשרויות של מאיצים.

  3. שמירה ושחזור של נקודות ביקורת ומודלים:

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

עומס עבודה של שרת

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

  1. טעינת המודל: אחרי שהאימון מסתיים, ה-Pods טוענים את המודל שאומן באמצעות Cloud Storage FUSE עם הפעלת הורדות מקבילות. הורדות מקבילות מאיצות את טעינת המודל על ידי אחזור החלקים של המודל במקביל מ-Cloud Storage. כדי לקצר באופן משמעותי את זמני הטעינה של המודל, התהליך משתמש בספריית המטמון כמאגר לשליפה מראש.
  2. בקשת הסקה: משתמשי האפליקציה שולחים בקשות הסקה מאפליקציית ה-AI וה-ML דרך שירות Cloud Load Balancing. ‫Cloud Load Balancing מחלק את הבקשות הנכנסות בין קונטיינרים שממלאים בקשות באשכול GKE. החלוקה הזו מבטיחה שאף קונטיינר לא יהיה עמוס מדי, ושהבקשות יעובדו ביעילות.
  3. העברת התשובה: הצמתים מעבדים את הבקשה ומפיקים תחזית. הקונטיינרים של הצגת המודעות שולחים את התגובות בחזרה דרך Cloud Load Balancing ואז למשתמשי האפליקציה.

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

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

  • ‫ Google Kubernetes Engine‏ (GKE): שירות Kubernetes שמאפשר לפרוס ולהפעיל אפליקציות בקונטיינרים בהיקף גדול באמצעות התשתית של Google.
  • ‫ Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ להם, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
  • ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . ‫VPC כולל קישור בין רשתות VPC שכנות (peering),‏ Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
  • ‫ Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים בעלי ביצועים גבוהים וניתנים להתאמה.
  • ‫ Cloud DNS: שירות שמספק DNS אמין עם זמן אחזור קצר שממלא בקשות מהרשת העולמית של Google.

תרחיש שימוש

לעומסי עבודה (workloads) של AI ו-ML שדורשים קיבולת אחסון גדולה וגישה לקבצים עם ביצועים גבוהים, מומלץ להשתמש בארכיטקטורה שמבוססת על Cloud Storage FUSE. עם תכנון נכון, אפשר להשיג תפוקה של יותר מ-‎1 TB/s באמצעות הארכיטקטורות האלה. בנוסף, Cloud Storage FUSE מאפשר לכם ליהנות ממאגר אחסון מרכזי שמשמש כמקור אמת יחיד לכל השלבים בתהליך העבודה של AI ו-ML. אפשר להשתמש בגישה הזו לכל עומסי העבודה, בלי קשר להיקף או לגודל שלהם.

לעומסי העבודה האלה, Cloud Storage FUSE מספק את היתרונות הבאים:

  • גישה פשוטה לנתונים: גישה לנתוני אימון ולנקודות ביקורת באמצעות מסגרות AI ו-ML כמו Connector for PyTorch,‏ JAX ו-TensorFlow. גישה לנתונים באמצעות מסגרות AI ו-ML מבטלת את הצורך בשינוי מבנה הקוד.
  • הפעלה מהירה: אפשר להימנע מהורדה של מערכי נתונים גדולים למשאבי מחשוב באמצעות Cloud Storage FUSE, כדי לגשת ישירות לנתונים ב-Cloud Storage. הגישה הישירה הזו לנתונים מאפשרת להפעיל את העבודות מהר יותר.
  • יעילות כלכלית: אפשר לבצע אופטימיזציה של העלויות באמצעות יכולות ההתאמה לשינויים בנפח וחיסכון בעלויות שקיימות ב-Cloud Storage.

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

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

חלופות עיצוב

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

פלטפורמה חלופית

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

ב-Compute Engine, אתם מקצים ומנהלים את המכונות הווירטואליות (VM), מה שמאפשר לכם שליטה מדויקת בסוגי המכונות, באחסון וברשת. אתם יכולים להתאים את התשתית לצרכים המדויקים שלכם, כולל בחירה של סוגים ספציפיים של מכונות וירטואליות. במאמרים gcsfuse CLI וקובץ ההגדרות של Cloud Storage FUSE מוסבר איך להשתמש באפשרויות של שורת הפקודה Cloud Storage FUSE ב-Compute Engine. אתם יכולים גם להשתמש במשפחת המכונות שעברה אופטימיזציה להאצה כדי לשפר את הביצועים של עומסי העבודה של ה-AI ולמידת המכונה. מידע נוסף על משפחות סוגי המכונות שזמינות ב-Compute Engine זמין במאמר השוואה בין משפחות של מכונות ומשאבים.

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

אפשרויות של מאיץ

מאיצי מכונה הם מעבדים ייעודיים שנועדו להאיץ את החישובים שנדרשים לעומסי עבודה של AI ו-ML. אפשר לבחור בין יחידות GPU לבין יחידות TPU.

  • מאיצי GPU מספקים ביצועים מצוינים למגוון רחב של משימות, כולל עיבוד גרפי, הדרכה של למידה עמוקה ומחשוב מדעי. Google Cloud יש מבחר רחב של מעבדי GPU שמתאימים למגוון רחב של ביצועים ונקודות מחיר. בדרך כלל, כרטיסי GPU כוללים כונני SSD מקומיים בכל הגדרת מכונה, ואפשר להשתמש בהם ב-Cloud Storage FUSE כספריית מטמון. למידע על מודלים של GPU ותמחור, אפשר לעיין במאמר בנושא תמחור של GPU.
  • יחידות TPU הן מאיצי AI שתוכננו בהתאמה אישית, והן מותאמות לאימון ולהסקת מסקנות של מודלים גדולים של AI. הם מתאימים למגוון תרחישי שימוש, כמו צ'אטבוטים, יצירת קוד, יצירת תוכן מדיה, דיבור סינתטי, שירותי ראייה, מנועי המלצות ומודלים להתאמה אישית. מידע נוסף על מודלים של TPU ותמחור זמין במאמר תמחור TPU.

חלופות לאחסון

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

  • ‫Google Cloud Managed Lustre: מערכת קבצים מקבילה (PFS) מתמשכת ומנוהלת במלואה Google Cloudשמבוססת על DDN's EXAScaler Lustre. ‫Managed Lustre הוא הפתרון העיקרי המומלץ לאימון ולשמירת נקודות ביקורת של עומסי עבודה של AI. הוא יעיל במיוחד להעברת עומסי עבודה קיימים מ-Lustre או מפתרונות PFS אחרים. כדי לשפר את הביצועים במהלך יצירת נקודות ביקורת, כדאי להשתמש ב-Managed Lustre כדי להוסיף ל-Cloud Storage FUSE מטמון מהיר. מידע נוסף זמין במאמר אופטימיזציה של עומסי עבודה של AI ו-ML באמצעות Google Cloud Managed Lustre.
  • ‫Connector for PyTorch: מוצר בקוד פתוח ב-Cloud Storage שמתאים במיוחד לעומסי עבודה שמשתמשים ב-PyTorch. המחבר ל-PyTorch מייעל את עומס העבודה של האימון על ידי סטרימינג של נתונים ישירות מהקטגוריות של Cloud Storage, ומבטל את הצורך באחסון ביניים. הגישה הישירה והאופטימיזציה האלה מספקות ביצועים טובים משמעותית בהשוואה לקריאות ישירות ל-API של Cloud Storage לצורך טעינת נתונים, אימון וסימון נקודות ביקורת.

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

השוואה מקיפה של אפשרויות אחסון לעומסי עבודה של AI ו-ML זמינה במאמר סקירה כללית של שירותי אחסון לעומסי עבודה של AI ו-ML ב-AI Hypercomputer.

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

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

ההמלצות הבאות לעיצוב מדגישות הגדרות שיעזרו לכם לשפר את הפריסה של Cloud Storage FUSE ב-GKE. רוב האפשרויות של Cloud Storage FUSE מוגדרות באמצעות אפשרויות טעינה. מידע נוסף על אפשרויות שורת הפקודה של Cloud Storage FUSE ועל אופן השימוש בהן זמין במאמרים gcsfuse CLI ואופטימיזציה של Cloud Storage FUSE CSI driver לביצועים ב-GKE.

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

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

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

שיקולים לגבי GKE

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

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

כברירת מחדל, הנתונים ב-GKE מוצפנים במצב מנוחה ובזמן ההעברה באמצעות Google-owned and Google-managed encryption keys. כדי להוסיף שכבת אבטחה למידע רגיש, אתם יכולים להצפין נתונים בשכבת האפליקציה באמצעות מפתח שבבעלותכם ושמנוהל על ידי Cloud Key Management Service‏ (Cloud KMS). מידע נוסף זמין במאמר בנושא הצפנת סודות בשכבת האפליקציה.

אם אתם משתמשים באשכול GKE רגיל, אתם יכולים להשתמש ביכולות הנוספות הבאות להצפנת נתונים:

שיקולים לגבי Cloud Storage

כברירת מחדל, הנתונים שמאוחסנים ב-Cloud Storage מוצפנים באמצעות Google-owned and Google-managed encryption keys. אם נדרש, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) או במפתחות משלכם שאתם מנהלים באמצעות שיטת ניהול חיצונית, כמו מפתחות הצפנה באספקת הלקוח (CSEK). מידע נוסף מופיע במאמר בנושא אפשרויות להצפנת נתונים.

‫Cloud Storage תומך בשתי שיטות להענקת גישה למשתמשים לקטגוריות ולאובייקטים: IAM ורשימות של בקרת גישה (ACL). ברוב המקרים מומלץ להשתמש ב-IAM, שמאפשר להעניק הרשאות ברמת הקטגוריה והפרויקט. מידע נוסף מופיע במאמר סקירה כללית על בקרת גישה.

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

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

שיקולים לגבי Cloud Storage FUSE

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

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

כברירת מחדל, כל צמתי ה-inode במערכת קבצים של Cloud Storage FUSE הם בבעלות המשתמש שטען את מערכת הקבצים. למרות שערכי ברירת המחדל האלה מתאימים למקרים רבים, אתם יכולים להתאים אישית את הקשר האבטחתי של ה-Pod. מידע על התאמה אישית של הקשר אבטחה זמין במאמר אבטחה והרשאות.

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

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

אמינות

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

למרות שיש הרבה יתרונות לשימוש ב-Cloud Storage FUSE, כדאי לשים לב לנקודות הבאות:

  • פעולות כתיבה בו-זמניות: כשכמה משתמשים מנסים לשנות קובץ, הפעולה last write wins מקבלת עדיפות וכל פעולות הכתיבה הקודמות נמחקות. כדי לשמור על תקינות הנתונים, מומלץ שרק מקור אחד ישנה אובייקט מסוים בכל רגע נתון.
  • שמירת מטמון: כשמבטלים את ההתקנה של הקטגוריה או מפעילים אותה מחדש, המטמון לא נשמר. כדי למנוע בעיות אבטחה פוטנציאליות, אחרי שמבטלים את הטעינה של דלי או מפעילים אותו מחדש, חשוב למחוק ידנית את ספריית מטמון הקבצים.
  • תהליכים עם מטמונים ייעודיים: למרות ש-Cloud Storage FUSE תומך בגישה בו-זמנית לעיבוד מקביל יעיל, חשוב לזכור שהמטמונים ספציפיים לכל תהליך של Cloud Storage FUSE. לכן, אסור להשתמש באותה ספריית מטמון בתהליכים שונים של Cloud Storage FUSE שפועלים באותן מכונות או במכונות שונות.

שיקולים נוספים לגבי מהימנות

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

הוזלת עלויות

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

שיקולים לגבי GKE

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

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

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

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

שיקולים לגבי Cloud Storage

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

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

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

שיקולים לגבי Cloud Storage FUSE

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

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

מידע נוסף על חיובים זמין במאמר תמחור של Cloud Storage.

שיקולי עלות נוספים

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

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

‫Cloud Storage FUSE נועד לספק גישה יעילה לנתונים ב-Cloud Storage עבור עומסי העבודה של AI ו-ML. עם זאת, בקשות תכופות למטא-נתונים עלולות להפחית את הביצועים, במיוחד באשכולות גדולים. מידע נוסף על שיפור הביצועים זמין במאמרים אופטימיזציה של מנהל התקן Cloud Storage FUSE CSI לביצועים ב-GKE ושיטות מומלצות לשיפור הביצועים.

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

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

  • הפעלת שמירת קבצים במטמון: שמירת קבצים במטמון מאיצה את הגישה החוזרת לנתוני אימון באמצעות ספריית צמתים מקומית לשמירת קבצים שנקראים לעיתים קרובות. מילוי בקשות חוזרות לקריאה ממדיה במטמון מקצר את זמן האחזור ומצמצם את מספר הפעולות שמתבצעות ב-Cloud Storage. בסוגי מכונות GPU עם SSD מקומי, נעשה שימוש אוטומטי בספריית ה-SSD המקומי. בסוגי מכונות שלא כוללים כונן SSD מקומי, כמו TPU, אפשר להשתמש בספריית דיסק RAM, כמו /tmpfs.

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

    • כדי להגדיר את הערך של מטמון הקבצים שניתן לשימוש כמגבלת קיבולת המטמון, מגדירים את file-cache:max-size-mb: כ--1.
    • כדי להגדיר את אורך החיים (TTL) של מטמון המטא-נתונים לזמן בלתי מוגבל ולסילוק על סמך האלגוריתם של הפריט שהיה בשימוש הכי פחות זמן (LRU) אחרי שהקיבולת המקסימלית מושגת, מגדירים את metadata-cache:ttl-secs: ל--1.

  • הגדלת ערכי מטמון המטא-נתונים: ל-Cloud Storage FUSE יש שני סוגים של מטמון מטא-נתונים שמשפרים את הביצועים של פעולות שקשורות לחיפושי מטא-נתונים: stat cache ו-type cache.

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

    • כדי להגדיר את ערך המטמון של הנתונים הסטטיסטיים שניתן להשתמש בהם כמגבלת קיבולת המטמון, מגדירים את metadata-cache:stat-cache-max-size-mb: ל--1.
    • כדי להגדיר את ערך המטמון של הסוג שניתן לשימוש למגבלת הקיבולת, מגדירים את metadata-cache:type-cache-max-size-mb: ל--1.
    • כדי למנוע את פקיעת התוקף של פריטי מטא-נתונים במטמון, עם ערך ברירת מחדל של 60 שניות, מגדירים את metadata-cache:ttl-secs: לערך -1. ערכים אינסופיים צריכים לשמש רק לנפחים וצמתים לקריאה בלבד עם תצורות זיכרון גדולות.

  • אכלוס מראש של מטמון המטא-נתונים: התכונה 'אחזור מראש של מטא-נתונים' מאפשרת למנהל התקן ה-CSI של Cloud Storage FUSE לטעון באופן יזום מטא-נתונים רלוונטיים לגבי האובייקטים בקטגוריה של Cloud Storage במטמונים של Cloud Storage FUSE. הגישה הזו מצמצמת את הקריאות ל-Cloud Storage, והיא מועילה במיוחד לאפליקציות שמשתמשות במערכי נתונים גדולים עם הרבה קבצים, כמו עומסי עבודה של אימון AI ולמידת מכונה.

    כדי לאכלס מראש את מטמון המטא-נתונים, מפעילים את אחזור המטא-נתונים מראש עבור אמצעי האחסון הנתון. מגדירים את מאפיין עוצמת הקול gcsfuseMetadataPrefetchOnMount לערך true. כדי למנוע שיבושים בעומסי העבודה, כדאי להגדיל את מגבלת הזיכרון של gke-gcsfuse-metadata-prefetch sidecar על ידי הגדרת משאבי ה-sidecar.

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

    כדי להפעיל שמירת מטמון של רשימות ולמנוע את התפוגה של פריטים במטמון של רשימות ליבה, מגדירים את אפשרות ההרכבה file-system:kernel-list-cache-ttl-secs: לערך -1.

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

    כדי להפעיל הורדות מקבילות, מפעילים את מטמון הקבצים ומגדירים את אפשרות ההרכבה file-cache:enable-parallel-downloads: לערך true.

  • הגדלת המגבלות של GKE sidecar: כדי למנוע ממגבלות על משאבים לפגוע בביצועים, צריך להגדיר מגבלות על משאבי קונטיינר sidecar, כמו צריכת מעבד (CPU) וזיכרון. אם אתם משתמשים במטמון SSD מקומי, כדאי להגדיר את ephemeral-storage-limit ללא הגבלה. ההגדרה הזו מאפשרת ל-Cloud Storage FUSE להשתמש באופן מלא בנפח האחסון הזמין בכונן ה-SSD המקומי כדי לשפר את השמירה במטמון.

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

שיקולים נוספים לגבי ביצועים

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

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

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

מחבר: סמנתה הי | כותבת טכנית

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