בדף הזה מוסבר על התנהגות ברירת המחדל של התאמה אוטומטית לעומס ב-Cloud Run. אפשרות חלופית לשינוי גודל היא הגדרה של מספר מכונות ספציפי. למידע נוסף, ראו שינוי גודל ידני.
כברירת מחדל, כל גרסה של Cloud Run מותאמת באופן אוטומטי למספר המכונות שנדרשות לטיפול בבקשות נכנסות, באירועים או בניצול המעבד. אפשר גם לכוונן את התנהגות ההתאמה הזו על ידי הגדרת יעדים מותאמים אישית לניצול מעבד (CPU) וניצול בו-זמניות (concurrency).
אם אין תנועה לגרסה, כברירת מחדל, המערכת מצמצמת את מספר המופעים שלה לאפס. אפשר לשנות את ברירת המחדל הזו כדי לציין מכונה שתישאר במצב בלי פעילות או במצב 'חם' באמצעות ההגדרה minimum instances (מופעים מינימליים). אם השירות שלכם משתמש במעבד גם כשהוא לא מעבד בקשות, צריך להגדיר את מספר המופעים המינימלי ל-1.
הכלי להתאמה אוטומטית לעומס ב-Cloud Run מעריך את המדדים הבאים באופן תקופתי כדי לקבוע את מספר המכונות שנדרשות לטיפול בתעבורה:
ניצול המעבד (CPU) והמקביליות: Cloud Run משנה את מספר המופעים כדי לשמור על המעבד הממוצע והמקביליות בתוך ערכי הסף של היעד.
מגבלות על מספר המכונות: ב-Cloud Run, מספר המכונות מוגבל בין המגבלות המקסימלית והמינימלית שאתם מגדירים.
התנהגות של התאמה אופקית של שירותים לעומס
ב-Cloud Run יש שני מנגנונים להתאמה אוטומטית לעומס: התאמה לעומס שמבוססת על מדדים והתאמה לעומס לפי דרישה. המנגנונים האלה קובעים את מספר המכונות שנדרש כדי לטפל בתעבורת הנתונים.
שינוי גודל מבוסס-מדדים
התאמה אוטומטית לעומס שמבוססת על מדדים משנה אוטומטית את מספר המופעים בהתאם לניצול הממוצע של ה-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 של כל מופע משמש כקיבולת המקבילות של הבקשות של המופע, במקום המספר המקסימלי של בקשות מקבילות שהוגדר. התכונה ACT מפחיתה באופן דינמי את מספר הבקשות המקבילות ב-1, במרווחי זמן של שנייה אחת, כשהניצול של המעבד (CPU) עולה על 90%. מידע נוסף זמין במאמר בנושא התאמה דינמית של בו-זמניות (ACT).
לכל עדכון של שירות אפשר להגדיר את מספר המעבדים לכל מופע ואת רמת המקביליות המקסימלית.
Cloud Run לא תומך בהתאמת קנה מידה על סמך ניצול הזיכרון.
כברירת מחדל, בהרחבה מבוססת-מדדים מוגדר סף של 60% לניצול המעבד (CPU) וליעדים של בקשות מקבילות. אתם יכולים להשתמש באמצעי בקרה על התאמה לעומס כדי לציין יעדים מותאמים אישית של מעבד (CPU) או של בו-זמניות (concurrency).
כש-Cloud Run מבצע התאמת עומס על סמך ניצול המעבד, הוא מתחשב בניצול המעבד הממוצע בכל המעבדים שהוקצו למופע. אם האפליקציה שלכם היא בעלת תהליך יחיד אבל היא נפרסת על מכונה עם כמה מעבדים, יכול להיות שרמת הניצול הממוצעת תהיה נמוכה, וזה עלול להשפיע על האופן שבו מתקבלות החלטות לגבי שינוי גודל על סמך המעבד. לפרטים נוספים על אופטימיזציה של הגדרת המעבד בהתאם לארכיטקטורה של האפליקציה, אפשר לעיין במאמרים בנושא הגדרת מגבלות על המעבד והגדרת מספר מקסימלי של בקשות מקבילות לכל מופע.
הרחבת המינוי
Cloud Run מגדיל את מספר המכונות בהתאם למה שנדרש לכל אחד ממנגנוני ההתאמה לעומס. במקרים שבהם יש מספר נמוך של מופעים, שינוי הגודל על סמך מדדים מגיב בצורה מדויקת ליעדי הניצול שלכם.
התאמת קנה מידה שמבוססת על מדדים שומרת על מספר המופעים הנוכחי, כל עוד רמת הניצול נשארת בטווח של 10% מהיעד, ביחס ליעד. לדוגמה, עם יעד ברירת המחדל של 60%, מספר המופעים לא משתנה, אבל רמת הניצול נשארת בין 54% ל-66%.
אם רמת הניצול חורגת מהטווח הזה, שינוי הגודל על סמך מדדים יחשב מחדש את מספר המופעים על סמך השימוש שנמדד והיעד שהגדרתם, ולא על סמך מספר המופעים הפעילים, ויעגל את התוצאה כלפי מעלה למופע השלם הבא. בגלל העיגול הזה, אפשר להגדיל את הקיבולת של השירות גם אם רמת הניצול עדיין נמוכה מהיעד. לדוגמה, שירות שצריך 4.1 מכונות כדי לעמוד ביעד מריץ 5 מכונות.
הקטנה
ההתאמה האוטומטית לעומס ב-Cloud Run מצמצמת את מספר המכונות הפועלות כשאין יותר צורך בהן כדי לטפל בתעבורת הנתונים הנכנסת. התאמה אוטומטית לעומס (scaling) שמבוססת על מדדים משנה באופן רציף את מספר המכונות המומלץ בהתאם לניצול. Cloud Run מקטין את מספר המופעים המומלץ רק אם רמת הניצול יורדת ביותר מ-10% מתחת ליעד, ואז משתמש באותו חישוב מעוגל כלפי מעלה כדי לקבוע את המספר החדש.
כשצריכת ה-CPU הממוצעת או מספר הבקשות הפעילות הממוצע יורדים, אלגוריתם ההתאמה של קנה המידה מקטין את מספר המופעים המומלץ. מאזן העומסים של בקשות Cloud Run מתחשב בהמלצות האלה, ומנתב את הבקשות הנכנסות קודם למופעים המומלצים. כך, המכונות המומלצות עמוסות יותר ומכונות אחרות לא פעילות. Cloud Run מפחית את מספר המקרים האלה שבהם נעשה שימוש במופעים שלא מומלצים על ידי כך שהוא נותן להם עדיפות נמוכה יותר, כך שהם יקבלו תנועה רק אם כל המופעים המומלצים יהיו עמוסים. כדי לשמור על יציבות, Cloud Run משבית את המופעים שהוגדרו להם עדיפות נמוכה בסדר הבא:
- מערכת Cloud Run משביתה קבוצה של מכונות וירטואליות כשהניצול שלהן בחלון של דקה אחת הוא פחות מ-10%.
- קבוצה שנייה של מופעים ממשיכה לפעול עד שמתרחש זמן קצוב לתפוגה של 15 דקות של חוסר פעילות, כדי להבטיח שהקיבולת תהיה זמינה במקרה של עלייה פתאומית בתעבורת נתונים.
אם השירות מבצע משימות אחרות גם כשהוא לא מעבד בקשות, כמו הפעלת שרשורים ברקע או עיבוד משימות אסינכרוניות, צריך להגדיר לפחות 1 כערך של minimum instances כדי לוודא שה-CPU ימשיך להיות מוקצה לעיבוד ברקע.
שינוי גודל לפי דרישה
מערכת Cloud Run משתמשת בהתאמה לעומס על פי דרישה אם היא לא מוצאת מופע זמין לטיפול בבקשה הנכנסת. שינוי גודל לפי דרישה מגיב בזמן אמת לשינויים בתנועה הנכנסת בגרסה של Cloud Run, או לשינויים בחביון של הגרסה. ההתאמה הזו מנסה להבטיח שכל בקשה נכנסת תנותב למופע תוך פרק זמן קצר. הגדלה על פי דרישה היא הגורם היחיד להגדלה מאפס. עם זאת, כשמבצעים שינוי גודל מ-N מופעים, שינוי הגודל על סמך מדדים או על פי דרישה מטפל בתנועה, בהתאם לטריגר הראשון.
מכיוון שהתאמת גודל לפי דרישה מגיבה בזמן אמת לשינויים פתאומיים בתעבורת נתונים, Cloud Run מנהל את האיזון בין זמן האחזור של הפעלה במצב התחלתי (cold start) (הזמן שנדרש להפעלת מופע חדש) לבין זמן האחזור של תור בהמתנה (הזמן שבו בקשה ממתינה לפתיחת משבצת במופע קיים). לפני שמנסים להפעיל מכונה חדשה לפי דרישה, המערכת בודקת לגבי כל בקשה אם התור של מופע עתידי או של מופע קיים מהיר יותר (בסדר הזה). בקשה נשארת בתור ההמתנה למקסימום של 10 שניות או פי 3.5 מזמן ההפעלה במצב התחלתי (cold start) הצפוי (התקופה הארוכה מביניהן) לפני שהמערכת מפעילה מופע חדש על פי דרישה.
התאמה דינמית של בו-זמניות (ACT)
Cloud Run משתמש בהתאמה דינמית של מספר הבקשות המקבילות (ACT) כדי למנוע מצב שבו ויסות הנתונים של המעבד (CPU) גורם לזמן אחזור גבוה של בקשות. בגישה הזו נמדד ניצול המעבד לכל מופע במספר נתון של בקשות, והערך המקסימלי של הבקשות המקבילות של המופע משתנה באופן דינמי כדי לשמור על ניצול המעבד מתחת ל-90%. ACT מתאים את מספר הבקשות בו-זמנית בהתאם לתרחישים הבאים:
בכל פעם ששימוש המעבד (CPU) במהלך השנייה האחרונה חורג מ-90%, הכלי ACT מקטין את מספר הבקשות המקסימלי בו-זמנית של המכונה ב-1.
אם המופע מגיע למגבלה המקסימלית של בקשות בו-זמניות, וניצול המעבד נשאר מתחת ל-70% למשך שנייה אחת, ACT מגדיל את המגבלה המקסימלית של בקשות בו-זמניות למופע ב-1.
אם מדדי ההתאמה לעומס מראים שהבו-זמניות אף פעם לא מגיעה למקסימום שהגדרתם, יכול להיות שהמערכת הורידה באופן דינמי את המקסימום בפועל כדי להגן על ביצועי המכונה.
Cloud Run מחשב את ערכי ה-ACT לכל פריסה. המדדים האלה לא נשמרים בין פריסות. אם ACT מקטין את מספר הבקשות המקבילות מתחת לרמה המועדפת, צריך להגדיל את המעבד שהוקצה לכל בקשה מקבילה מקסימלית. גם משימות ברקע שגורמות לעליות תקופתיות בשימוש במעבד יכולות להפריע לגישה הזו להתאמת גודל.
כדי לעקוב אחרי הפעילות של ACT בהגדלת הקיבולת באופן אוטומטי, אפשר להציג את השדה scaling_driver במסוף Cloud de Confiance . פרטים על הצגת המדד הזה מופיעים במאמר הגדרת אמצעי בקרה מותאמים אישית של שינוי גודל לשירותים.
חיוב לפי מופע והתאמה לעומס (autoscaling)
אם אתם מגדירים חיוב לפי מופע בשירות Cloud Run, חשוב שתכירו את התנהגות הסקיילינג ל ומ-0.
התאמה לגידול מאפס. אפשר להפעיל את ההרחבה מאפס רק באמצעות בקשה, ולכן שירות שלא מעבד בקשות לא יכול להתרחב מאפס. עבור עומסי העבודה האלה, אפשר להגדיר מספר מינימלי של מופעים > 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 ממליצה להשתמש במינויים מסוג Push כדי לצרוך הודעות מנושא Pub/Sub ב-Cloud Run. הודעות שנשלחות בדחיפה מתקבלות על ידי הקונטיינר כמו בקשות HTTP, ולכן מפעילות את אותו התנהגות של שינוי גודל אוטומטי.
התאמה אוטומטית לעומס (auto-scaling) וכמה קונטיינרים (sidecars)
ב-Cloud Run, שיעור ניצול המעבד של מופעים נלקח בחשבון לצורך התאמה אוטומטית לעומס. שיעור ניצול המעבד של מופע הוא אחוז המעבד שהוקצה לשימוש.
שימו לב: אתם מקצים מעבד כשאתם מגדירים מגבלות מעבד ברמת מאגר התגים. אם אתם משתמשים בכמה מאגרי תגים לכל מופע, הקצאת ה-CPU בפועל למופע הזה היא סכום מגבלות ה-CPU שהגדרתם בכל מאגר תגים.
המאמרים הבאים
- כדי להגדיר יעדי ניצול בהתאמה אישית או להשבית את הגורמים שמניעים את שינוי הגודל, אפשר לעיין במאמר הגדרת אמצעי בקרה בהתאמה אישית לשינוי גודל.
- אפשרויות נוספות לשינוי גודל מפורטות במאמר בנושא שינוי גודל ידני.
- כדי לנהל את המספר המקסימלי של מופעים של שירותי Cloud Run, אפשר לעיין במאמר בנושא הגדרת מספר מקסימלי של מופעים.
- כדי לנהל את המספר המקסימלי של בקשות בו-זמניות שמטופלות על ידי כל מופע, אפשר לעיין במאמר בנושא הגדרת מקביליות.
- כדי לבצע אופטימיזציה של הגדרת הבו-זמניות, אפשר לעיין בטיפים לפיתוח לצורך התאמה של בו-זמניות.
- כדי לציין מכונה בלי פעילות שתמשיך לפעול כדי לצמצם את זמן הטעינה או את ההפעלה במצב התחלתי (cold start) בבקשות הראשונות, אפשר לעיין במאמר בנושא שימוש ב-
min-instanceכדי להפעיל מכונות בלי פעילות.