מספר מקסימלי של בקשות בו-זמנית לשירותים

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

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

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

מספר מקסימלי של בקשות בו-זמנית לכל מכונה

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

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

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

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

שיקולי עלות

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

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

כוונון של מספר הבקשות המקבילות להתאמה אוטומטית לעומס ולניצול משאבים

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

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

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

בו-זמניות (concurrency) עם מכונות וירטואליות עם כמה vCPU

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

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

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

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

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

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

מקרה לדוגמה

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

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

בו-זמניות לפריסות של קוד מקור

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

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

• ‫Node.js הוא מטבעו single-threaded. כדי לנצל את היתרונות של בו-זמניות (concurrency), צריך להשתמש בסגנון הקוד האסינכרוני של JavaScript, שהוא אידיומטי ב-Node.js. פרטים נוספים זמינים במאמר בנושא שליטה אסינכרונית בזרימה בתיעוד הרשמי של Node.js.

• ב-Python 3.8 ואילך, כדי לתמוך בריבוי משימות בו-זמנית בכל מופע, צריך מספיק שרשורים כדי לטפל בריבוי המשימות בו-זמנית. מומלץ להגדיר משתנה סביבה של זמן ריצה כך שערך השרשורים יהיה שווה לערך הבו-זמניות. לדוגמה: THREADS=8.

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

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

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