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

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

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

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

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

המידרוג האוטומטי ב-Cloud Run מעריך את הערכים האלה מעת לעת.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חלוקת תנועה

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

פריסות

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

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

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

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

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

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

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