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

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

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

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

הכלי להתאמה אוטומטית לעומס ב-Cloud Run מעריך את המדדים הבאים באופן תקופתי כדי לקבוע את מספר המכונות שדרוש לטיפול בתעבורה:

  • ניצול המעבד (CPU) והמקביליות: Cloud Run משנה את מספר המופעים כדי לשמור על המעבד הממוצע ועל המקביליות בתוך ערכי הסף.

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

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

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

שינוי גודל על סמך מדדים

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

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

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

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

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

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

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

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

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

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

הרחבת הפעילות

מערכת Cloud Run מגדילה את מספר המכונות בהתאם למה שנדרש לשינוי הגודל.

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

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

הקטנה

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

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

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

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

שינוי גודל לפי דרישה

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

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

התאמה דינמית של בו-זמניות (ACT)

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

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

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

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

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

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

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

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

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

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

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

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

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

חריגה ממספר המופעים המקסימלי

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

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

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

התחייבויות להרחבת היקף הפעילות

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

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

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

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

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

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

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

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

חלוקת תנועה

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

פריסות

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

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

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

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

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

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

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

ההשפעה של שינוי גודל אוטומטי על שירותי גיבוי

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

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

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

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

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

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

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