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

Last reviewed 2025-08-22 UTC

במאמר הזה מוצגות ארכיטקטורות לדוגמה שמראות איך אפשר להשתמש ב-Cloud Storage FUSE כדי לשפר את הביצועים של עומסי עבודה (workloads) של 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 הארכיטקטורה הרב-אזורית משתמשת ב-Anywhere Cache כדי להגדיל את רוחב הפס ברשת ולספק פגיעות במטמון אזורי עם חביון נמוך יותר בהשוואה לקטגוריה אזורית. בדרך כלל מומלץ להשתמש ב-Anywhere Cache לכל עומסי העבודה, והשימוש בו עם קטגוריות במספר אזורים מבטל את עמלות העברת הנתונים. כדי לבדוק אם Anywhere Cache מתאים לעומס העבודה שלכם, אתם יכולים להשתמש בשירות ההמלצות של Anywhere 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) או יחידות לעיבוד טנסורים (TPU): מעבדי 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 וב-Anywhere 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) או יחידות לעיבוד טנסורים (TPU): מעבדי 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.
  • ‫Anywhere Cache: תכונה של Cloud Storage שמספקת עד 1PiB של מטמון לקריאה בלבד, שמגובה על ידי SSD, לקטגוריות של Cloud Storage. במהלך האימון וההפעלה, Anywhere Cache עוזר לצמצם את זמן האחזור של קריאות ולהשיג תפוקה של יותר מ-2TB/s על ידי שינוי גודל המטמון ורוחב הפס. בשילוב עם קטגוריות של מספר אזורים, אפשר להשתמש ב-Anywhere Cache בכמה אזורים ובכמה אזורים גיאוגרפיים. מידע על אזורים ותחומים נתמכים זמין במאמר מיקומים נתמכים.

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

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

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

  1. טעינת נתוני אימון ל-Cloud Storage: נתוני האימון מועלים לקטגוריה של Cloud Storage עם מרחבי שמות היררכיים מופעלים. ‫Cloud Storage משמש כמאגר מרכזי ניתן להרחבה.
  2. טעינת נתוני אימון והרצת משימות אימון ב-GKE: קטגוריית Cloud Storage שמותקנת בתרמילי 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.

תרחיש לדוגמה

לעומסי עבודה של 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), וכך מקבלים שליטה מדויקת בסוגי המכונות, באחסון וברשת. אתם יכולים להתאים את התשתית לצרכים המדויקים שלכם, כולל בחירה של סוגים ספציפיים של מכונות וירטואליות. למידע על איך להשתמש באפשרויות של שורת הפקודה Cloud Storage FUSE ב-Compute Engine, ראו gcsfuse CLI וקובץ התצורה של Cloud Storage FUSE. אתם יכולים גם להשתמש במשפחת המכונות שעברה אופטימיזציה להאצה כדי לשפר את הביצועים של עומסי העבודה של AI ו-ML. מידע נוסף על משפחות סוגי המכונות שזמינות ב-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 את Anywhere Cache. מידע נוסף זמין במאמר אופטימיזציה של עומסי עבודה של AI ו-ML באמצעות Google Cloud Managed Lustre.
  • ‫Connector for PyTorch: מוצר בקוד פתוח ב-Cloud Storage שמתאים לעומסי עבודה שמשתמשים ב-PyTorch. Connector for PyTorch מייעל את עומס העבודה של האימון על ידי סטרימינג של נתונים ישירות מהקטגוריות של Cloud Storage, וכך מבטל את הצורך באחסון ביניים. הגישה הישירה והאופטימיזציה האלה מספקות ביצועים טובים משמעותית בהשוואה לקריאות API ישירות ל-Cloud Storage לצורך טעינת נתונים, אימון ויצירת נקודות ביקורת.

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

השוואה מקיפה של אפשרויות אחסון לעומסי עבודה של AI ו-ML ב- Google Cloud

שיקולים לגבי העיצוב

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

ההמלצות הבאות לעיצוב מדגישות הגדרות שיעזרו לכם לשפר את האופן שבו אתם פורסים את Cloud Storage FUSE ב-GKE. רוב האפשרויות של Cloud Storage FUSE מוגדרות באמצעות אפשרויות טעינה. מידע נוסף על אפשרויות שורת הפקודה של Cloud Storage FUSE ועל אופן השימוש בהן זמין במאמרים gcsfuse CLI ואופטימיזציה של מנהל התקן ה-CSI של Cloud Storage FUSE לביצועים ב-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 מגבילה את הגישה למערכת הקבצים למשתמש שהפעיל את המערכת. ההגבלה הזו מונעת גישה למשתמשים אחרים, כולל משתמש Root, גם אם הרשאות ה-inode מקלות יותר.

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

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

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

עקרונות והמלצות אבטחה שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Security ב-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 מבצע אופטימיזציה של יעילות התשתית של האשכול על סמך דרישות עומס העבודה. כדי לשלוט בעלויות, לא צריך לעקוב כל הזמן אחרי ניצול המשאבים או לנהל את הקיבולת.

אם אתם יכולים לחזות את השימוש במעבד (CPU), בזיכרון ובנפח אחסון נדרש של אשכול Autopilot, תוכלו לקבל הנחות תמורת התחייבות לשימוש. כדי להקטין את העלות של הפעלת האפליקציה, אפשר להשתמש במכונות Spot לצמתים של GKE. המחיר של מכונות Spot VM נמוך יותר מזה של מכונות 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. עם זאת, בקשות תכופות למטא-נתונים עלולות להפחית את הביצועים, במיוחד באשכולות גדולים. מידע נוסף על שיפור הביצועים מופיע במאמרים אופטימיזציה של מנהל התקן ה-CSI של Cloud Storage FUSE לביצועים ב-GKE ושיטות מומלצות לשיפור הביצועים.

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

  • הפעלת מרחבי שמות היררכיים: כדי לשפר את הגישה לנתונים ואת הארגון שלהם, צריך ליצור קטגוריות של Cloud Storage עם מרחבי שמות היררכיים. מרחבי שמות היררכיים מאפשרים לארגן נתונים במבנה של מערכת קבצים, וכך לשפר את הביצועים, להבטיח עקביות ולפשט את הניהול של עומסי עבודה של 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 ומטמון type.

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

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

  • אכלוס מראש של מטמון המטא-נתונים: התכונה 'אחזור מראש של מטא-נתונים' מאפשרת לדרייבר Cloud Storage FUSE CSI לטעון באופן יזום מטא-נתונים רלוונטיים לגבי האובייקטים בקטגוריה של 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 ו-ML מפורטים במאמר AI and ML perspective: Performance optimization ב-Well-Architected Framework.

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

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

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

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