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

היתרונות העסקיים של התאמה אוטומטית לעומס (autoscaling) ב-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 לעומס.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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