מידע על התאמה אוטומטית של מספר המכונות (autoscaling) בשירותי Cloud Run

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

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

התנהגות של התאמה אופקית לעומס (autoscaling) של שירותים

ב-Cloud Run יש שני מנגנונים להתאמה לעומס (autoscaling) שקובעים את מספר המכונות שצריך כדי לטפל בתנועה: התאמה לעומס על סמך מדדים והתאמה לעומס על פי דרישה.

שינוי קנה מידה מבוסס-מדדים

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

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

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

\[ \text{Instances} = \left\lceil \dfrac{\left( \frac{\text{Average CPU usage per second over the past minute}}{\text{Number of CPUs per instance}} \right)}{\text{CPU target}} \right\rceil \]

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

\[ \text{Instances} = \left\lceil \dfrac{\left( \frac{\max(\text{average concurrent requests over 1 minute, 10 minutes})}{\text{Maximum concurrency}} \right)}{\text{Concurrency target}} \right\rceil \]

  • כוונון בו-זמניות דינמי (ACT): מחשב את מספר המכונות המומלץ לממוצע של דקה אחת של בקשות בו-זמניות. בשיטה הזו, ערך ה-ACT של כל מכונה משמש כקיבולת של בקשות מקבילות במכונה, במקום המספר המקסימלי שהוגדר לבקשות מקבילות. כשהניצול של המעבד (CPU) עולה על 90%, ACT מפחית באופן דינמי את מספר הבקשות בו-זמנית ב-1, במרווחים של שנייה אחת. מידע נוסף זמין במאמר כוונון בו-זמניות דינמי (ACT).

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

ב-Cloud Run אין תמיכה בהתאמה לעומס על סמך ניצול הזיכרון.

כברירת מחדל, בהתאמה לעומס שמבוססת על מדדים, הסף לניצול המעבד (CPU) ולבקשות בו-זמניות הוא 60%. אתם יכולים להשתמש באמצעי בקרה להתאמה לעומס כדי לציין יעדים מותאמים אישית של מעבד (CPU) או של בו-זמניות.

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

הגדלה

‫Cloud Run מגדיל את מספר המכונות בהתאם למנהל ההתקן של ההתאמה לעומס שדורש יותר מכונות. במספרים נמוכים של מכונות, ההתאמה לעומס (scaling) שמבוססת על מדדים מגיבה באופן הדוק ליעדי הניצול.

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

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

צמצום אנכי בהתאם לעומס (scale down)

ההתאמה לעומס (autoscaling) ב-Cloud Run מפחיתה את מספר המכונות הפועלות כשאין יותר צורך בהן כדי לטפל בתעבורת הנתונים הנכנסת. התאמה לעומס שמבוססת על מדדים משנה באופן רציף את מספר המכונות המומלץ בהתאם לניצול. ‫Cloud Run מפחית את מספר המכונות המומלץ רק כששיעור הניצול יורד ביותר מ-10% מתחת ליעד, ואז משתמש באותו חישוב מעוגל כלפי מעלה כדי לקבוע את המספר החדש.

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

  1. ‫Cloud Run משבית קבוצה של מכונות כשהניצול שלהן בחלון של דקה אחת הוא פחות מ-10%.
  2. קבוצה שנייה של מכונות ממשיכה לפעול עד שמתרחש זמן קצוב לתפוגה של 15 דקות, כדי להבטיח שהקיבולת תהיה זמינה במקרה של עלייה פתאומית בתנועה.

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

שינוי קנה מידה לפי דרישה

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

מכיוון שהתאמה לעומס על פי דרישה מגיבה בזמן אמת לשינויים פתאומיים בתנועה, Cloud Run מנהל את הפשרה בין זמן האחזור של התחלה קרה (הזמן להפעלת מכונה חדשה) לבין זמן האחזור של התור בהמתנה (הזמן שבו בקשה ממתינה לפתיחת משבצת במכונה קיימת). בכל בקשה, המערכת בודקת אם הוספה לתור של מכונה קרובה או של מכונה קיימת תהיה מהירה יותר (בסדר הזה) לפני שהיא מנסה להפעיל מכונה חדשה זמינה בהתאם לעומס. בקשה נשארת בתור ההמתנה למשך 10 שניות לכל היותר, או למשך פי 3.5 מזמן ההפעלה הראשונית החזוי (הגבוה מביניהם), לפני שהמערכת מפעילה מכונה חדשה זמינה בהתאם לעומס.

כוונון בו-זמניות דינמי (ACT)

כדי למנוע מצב שבו ויסות הנתונים של המעבד (CPU) גורם לזמן אחזור ארוך של בקשות, Cloud Run משתמש בכוונון בו-זמניות דינמי (ACT). בגישה הזו, המערכת מודדת את ניצול המעבד (CPU) בכל מכונה במספר נתון של בקשות, ומשנה באופן דינמי את הערך של מספר הבקשות המקסימלי בו-זמנית של המכונה כדי לשמור על ניצול מעבד (CPU) נמוך מ-90%. ACT מכוונן את בו-זמניות בהתאם לתרחישים הבאים:

  • בכל פעם שניצול המעבד (CPU) בשנייה האחרונה חורג מ-90%, ACT מפחית ב-1 את מספר הבקשות המקסימלי בו-זמנית של המכונה.

  • אם המכונה מגיעה למגבלה המקסימלית של בקשות בו-זמניות, וניצול המעבד נשאר מתחת ל-70% למשך שנייה אחת, ACT מגדילה את מספר הבקשות המקסימלי בו-זמנית למכונה ב-1.

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

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

כדי לבדוק מתי ACT מפעיל את ההתאמה האוטומטית לעומס, אפשר להציג את השדה scaling_driver במסוף Google Cloud . במאמר הגדרת אמצעי בקרה להתאמה אישית של שירותים מוסבר איך להציג את המדד הזה.

חיוב לפי מכונה והתאמה לעומס (autoscaling)

אם אתם מגדירים חיוב מבוסס-מכונה לשירות Cloud Run, חשוב שתבינו את ההתנהגות של התאמה לעומס (scaling) לאפס ומאפס.

התאמה לעומס (scaling) מאפס. אפשר להפעיל התאמה לאפס רק באמצעות בקשה, כך ששירות שלא מעבד בקשות לא יכול להתאים לאפס. בעומסי העבודה האלה, אתם יכולים להגדיר מספר מינימלי של מכונות > 0, או לכלול "בקשת התעוררות" בעיצוב כדי להפעיל מחדש את העיבוד אחרי צמצום הפעולה לאפס.

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

מידע על המספר המקסימלי של מכונות לשירותים

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

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

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

חריגה ממספר המכונות המקסימלי

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

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

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

התחייבויות לגבי הרחבה

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

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

חריגה ממספר המכונות המקסימלי בגלל עלייה חדה בתנועה

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

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

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

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

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

חלוקת התנועה

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

פריסות

כשפורסים גרסה חדשה כדי לטפל ב-100% מהתנועה, Cloud Run מפעיל מספיק מכונות של הגרסה החדשה לפני שהוא מפנה אליה את התנועה. כך מצמצמים את ההשפעה של פריסת גרסאות חדשות על זמני האחזור של הבקשות, במיוחד כשמטפלים ברמות גבוהות של תנועה. מכיוון שהמגבלה על מספר המופעים המקסימלי היא מגבלה לכל גרסה, במהלך פריסה, המספר הכולל של המופעים של השירות יכול לחרוג ממספר המופעים המקסימלי לכל גרסה. אפשר לראות את זה במדדים של Instance Count.

מכונות במצב חוסר פעילות וצמצום הפעלות במצב התחלתי (cold start)

כדי לצמצם את ההפעלות במצב התחלתי, יכול להיות ש-Cloud Run ישאיר מכונות במצב של חוסר פעילות למשך זמן מסוים אחרי שהן יסיימו לטפל בבקשות (עד 15 דקות, או 10 דקות ל-GPU).

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

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

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

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

ההשפעה של התאמה אוטומטית לעומס (autoscaling) על שירותים תומכים

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

התאמה אוטומטית לעומס ו-Pub/Sub

‫Google ממליצה להשתמש במינויי דחיפה כדי לצרוך הודעות מנושא Pub/Sub ב-Cloud Run. הודעות שנשלחות בדחיפה מתקבלות כמו בקשות HTTP על ידי הקונטיינר, וכך מפעילות את אותה התנהגות של התאמה אוטומטית לעומס.

התאמה אוטומטית לעומס (autoscaling) ומספר קונטיינרים (sidecars)

ב-Cloud Run, ההתאמה האוטומטית לעומס מתבצעת לפי ניצול המעבד (CPU) של המכונות, כאשר ניצול המעבד של מכונה הוא אחוז המעבד המוקצה שנמצא בשימוש.

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

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