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

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

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

מקביליות עם מכונות וירטואליות עם כמה ליבות CPU וירטואליות

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

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

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

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

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

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

מקרה לדוגמה

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

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

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

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

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

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

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

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

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

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