הסבר פשוט על מושגי התאמה אוטומטית לעומס (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: המערכת מתאימה באופן אוטומטי את המשאבים שהוקצו לאפליקציה (גם עומס העבודה וגם התשתית) על סמך הביקוש בזמן אמת.

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

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

  • אופטימיזציה של העלויות: אתם משלמים רק על משאבי המחשוב שבהם אתם משתמשים, וכך נמנעים מהוצאות מיותרות של הקצאת יתר. התאמה אוטומטית לעומס ב-GKE מונעת בזבוז משאבים על ידי התאמה אוטומטית של גודל האפליקציות לדרישות ה-CPU והזיכרון בפועל. הוא יכול גם להקצות חומרה יקרה ומיוחדת (כמו 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 כדי לשנות את הגודל מ-1 CPU ו-16 GB ל-4 CPUs ו-64 GB. התהליך הזה כולל הפעלה מחדש של ה-Pod עם התצורה החדשה והיעילה יותר שלו, כדי לטפל טוב יותר בעומס העבודה.

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

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

התאמה אוטומטית לעומס בתשתית

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

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

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

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

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

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

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

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

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

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

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

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

כדי להרחיב את האנלוגיה, אפשר לחשוב על 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%. ‫"The current Pods are overwhelmed. אנחנו צריכים להפיץ את התנועה הזו באופן מיידי". הגדלה או הקטנה של הקיבולת: שינוי מספר העותקים של ה-Pod כדי לעמוד בביקוש.
VPA יעילות ההתאמה לגודל נתוני צריכה היסטוריים, לדוגמה, שימוש ממוצע בזיכרון RAM ב-24 השעות האחרונות. "הדרישות של המשאבים של ה-Pod הזה השתנו, או שההערכות הראשוניות שלנו היו שגויות. אנחנו צריכים להתאים את הקצאת המשאבים שלה לשימוש בפועל" הגדלה או הקטנה: שינוי הגודל (מגבלות CPU או RAM) של ה-Pod כדי להתאים אותו לגודל הנכון.
יצירה אוטומטית של מאגר צמתים זמינות החומרה בקשות שלא מולאו, לדוגמה, ה-Pod נמצא בסטטוס 'בהמתנה' כי לא קיימים צמתי GPU. "אי אפשר להפעיל את ה-Pod הזה כי חסר רכיב חומרה פיזי שהוא ביקש". הקצאת תשתיות: יצירת מאגרי צמתים חדשים עם החומרה הספציפית.

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

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

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

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

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

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

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

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

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

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

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

סיכום

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

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