הסבר פשוט על מושגי התאמה אוטומטית לעומס (autoscaling) לעומסי עבודה של AI/ML ב-GKE

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

המסמך הזה מיועד למהנדסי למידת מכונה (ML) שחדשים ב-GKE. כדי להקל על השימוש ב-GKE לעומסי עבודה של AI/ML, מומלץ לקרוא את המסמכים הבאים בסדרה:

  1. למה כדאי להשתמש ב-GKE להסקת מסקנות מ-AI/ML
  2. מידע על הסקת מסקנות של מודלים של AI/ML ב-GKE
  3. הסבר פשוט על מושגי התאמה אוטומטית לעומס (autoscaling) לעומסי עבודה של AI/ML ב-GKE (המסמך הזה)

לפני שמתחילים

כדאי להכיר את המושגים הבסיסיים הבאים:

האתגר: מענה לביקושי שיא

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

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

הפתרון: התאמה אוטומטית לעומס על פי דרישה

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

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

היתרונות העסקיים של התאמה אוטומטית לעומס (auto-scaling) ב-GKE

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

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

התאמה אוטומטית לעומס (autoscaling) של עומסי עבודה

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

‫Horizontal Pod Autoscaler ‏ (HPA): הוספת משאבים נוספים

הכלי Horizontal Pod Autoscaler‏ (HPA) עוקב אחרי ניצול המשאבים של ה-Pods באפליקציה. באנלוגיה שלנו, ה-Pods הם 'נציגי המכירות', וה-HPA הוא 'מנהל הצוות' שבודק כמה נציגי המכירות עסוקים.

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

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

‫Vertical Pod Autoscaler‏ (VPA): שיפור עוצמת המשאבים

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

הגישה הזו של שינוי גודל אנכי ברמת ה-Pod מנוהלת על ידי Vertical Pod Autoscaler‏ (VPA). ה-VPA מנתח את צריכת המשאבים של האפליקציה ומשנה את בקשות המעבד והזיכרון של ה-Pod בהתאם לשימוש בפועל.

ה-VPA יכול לשנות את בקשות המשאבים והמגבלות של Pod, למשל, על ידי הקצאה מחדש של Pod כדי לשנות את גודל המשאבים מ-CPU אחד ו-16GB ל-4 מעבדי CPU ו-64GB. התהליך הזה כולל הפעלה מחדש של ה-Pod עם ההגדרה החדשה והיעילה יותר שלו, כדי לטפל טוב יותר בעומס העבודה.

מידע נוסף זמין במקורות המידע הבאים:

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

התאמה אוטומטית לעומס (autoscaling) של התשתית

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

התאמה אוטומטית של גודל האשכול: מנהל הבניין

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

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

מידע נוסף זמין במאמר בנושא שינוי אוטומטי של גודל האשכול.

יצירה אוטומטית של מאגר צמתים: מומחה האוטומציה

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

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

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

למידע על המאיצים שזמינים ב-GKE, אפשר לעיין במאמרים הבאים:

‫ComputeClasses: הטריגר ליצירה אוטומטית של מאגר צמתים

אף על פי שאפשר להפעיל יצירה אוטומטית של מאגר צמתים באמצעות בקשה של Pod לסוג חומרה ספציפי (כמו nvidia-l4-vws), שימוש ב-ComputeClass היא השיטה העמידה והמודרנית יותר. ‫ComputeClass הוא משאב GKE שאתם מגדירים, שפועל לפי קבוצה של כללים כדי לשלוט בהרחבת הקיבולת האוטומטית של החומרה ולהתאים אותה אישית. הוא לא מידרוג אוטומטי בעצמו, אבל הוא פועל עם המידרוג האוטומטי של האשכול.

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

במקום שעובד מכירות (ה-Pod שלכם) ידרוש פריט חומרה ספציפי וקשיח (לדוגמה, "אני צריך קופה רושמת מדגם 500 של מותג X"), הוא מבקש יכולת באמצעות טופס הבקשה (לדוגמה, "אני צריך עמדת תשלום מהירה"). הטופס – ComputeClass – מכיל קבוצה של כללים לצוות הרכישה (GKE) לגבי אופן ביצוע ההזמנה.

ה-ComputeClasses מפרידים בין הבקשה של ה-Pod לחומרה לבין הפעולה של GKE להקצאת החומרה. במקום שה-Pod יבקש מכונה ספציפית (כמו a3-highgpu-8g), הוא יכול לבקש ComputeClass. ה-ComputeClass עצמו מגדיר את הלוגיקה ה "חכמה", רשימה של כללים עם עדיפות שמסבירה ל-GKE איך למלא את הבקשה.

מידע נוסף זמין במאמר מידע על ComputeClasses ב-GKE.

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

מדדים מרכזיים וטריגרים להתאמה אוטומטית לעומס

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

רכיב תגובות ל: מקור האות תהליך החשיבה הפעולה של GKE
HPA העומס הנוכחי צריכה בזמן אמת, לדוגמה, המעבד נמצא כרגע ב-90%. "התקנים הנוכחיים של Pods עמוסים מדי. אנחנו צריכים להפיץ את התנועה הזו באופן מיידי". הגדלה או הקטנה של הקיבולת: שינוי מספר העותקים של ה-Pod כדי לעמוד בביקוש.
VPA יעילות ההתאמה צריכה היסטורית, למשל, שימוש ממוצע ב-RAM ב-24 השעות האחרונות. "הדרישות של הפוד הזה השתנו, או שההערכות הראשוניות שלנו היו שגויות. אנחנו צריכים להתאים את הקצאת המשאבים שלה לשימוש בפועל" הגדלה או הקטנה: שינוי הגודל (מגבלות CPU או RAM) של ה-Pod כדי להתאים אותו לגודל הנכון.
יצירה אוטומטית של מאגר צמתים זמינות החומרה בקשות שלא מולאו, לדוגמה, ה-Pod נמצא במצב 'בהמתנה' כי לא קיימים צמתי GPU. "אי אפשר להפעיל את ה-Pod הזה כי חסר רכיב חומרה פיזי שהוא ביקש". הקצאת תשתית: יצירת מאגרי צמתים חדשים עם החומרה הספציפית.

טריגרים של Horizontal Pod Autoscaler ‏ (HPA): תגובה לעומס

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

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

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

טריגרים של Vertical Pod Autoscaler‏ (VPA): תגובה לצרכים של משאבים

ה-VPA משנה את גודל ה-Pod (הגדלה או הקטנה) על סמך נתוני צריכת המשאבים ההיסטוריים שלו:

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

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

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

  • בקשה להקצאת משאבים שלא ניתנת לתזמון: טריגר מרכזי. כשיוצרים Pod, הוא מבקש חומרה ספציפית. אם אי אפשר למלא את הבקשה הזו כי אין צומת קיים עם החומרה הזו, המערכת יוצרת מאגר צמתים באופן אוטומטי.
  • בקשת ComputeClass: פוד מבקש ComputeClass, לדוגמה, cloud.google.com/compute-class: premium-gpu. אם אף צומת באשכול לא יכול לספק את היכולות של premium-gpu, יצירה אוטומטית של מאגר צמתים יוצרת באופן אוטומטי מאגר צמתים חדש שיכול לספק את היכולות האלה.

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

סיכום

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

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