בשירותי 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 להשתמש ביותר מופעים לאותו נפח בקשות, כי כל מופע מטפל בפחות בקשות. השיפור הזה יכול להועיל לאפליקציות שלא עברו אופטימיזציה לשימוש במקביל במספר גבוה של ליבות או לאפליקציות שרוצים להרחיב את השימוש בהן מהר יותר על סמך עומס הבקשות.
- יותר פעולות בו-זמניות: כל מופע יכול לטפל ביותר בקשות, מה שעשוי להוביל לפחות מופעים פעילים ולצמצום העלויות. האפשרות הזו מתאימה לאפליקציות שיעילות במשימות מקבילות שקשורות לקלט/פלט, או לאפליקציות שיכולות להשתמש בכמה מעבדים וירטואליים לעיבוד בקשות בו-זמנית.
מתחילים עם מספר ההפעלות המקבילות שמוגדר כברירת מחדל, עוקבים מקרוב אחרי הביצועים והניצול של האפליקציה ומשנים את ההגדרה לפי הצורך.
מקביליות עם מופעים של כמה ליבות וירטואליות
התאמת מספר התהליכים המקבילים חשובה במיוחד אם השירות שלכם משתמש בכמה מעבדים וירטואליים, אבל האפליקציה היא בעלת תהליך יחיד או בעלת תהליך יחיד בפועל (מוגבלת על ידי המעבד).
- vCPU hotspots: אפליקציה עם שרשור יחיד במופע עם כמה vCPU עשויה להגיע לניצול מקסימלי של vCPU אחד, בזמן שאחרים לא פעילים. הכלי להתאמה אוטומטית של מעבד ב-Cloud Run מודד את ממוצע השימוש במעבד בכל המעבדים הווירטואליים. במקרה כזה, ממוצע השימוש במעבד יכול להיות נמוך באופן מטעה, ולמנוע התאמת משאבים יעילה שמבוססת על המעבד.
- שימוש בהפעלה בו-זמנית כדי להגדיל את הקיבולת: אם התאמה אוטומטית לעומס על סמך מעבד לא יעילה בגלל נקודות חמות של vCPU, כדאי להקטין את ההפעלה המקסימלית בו-זמנית. נקודות חמות של vCPU מתרחשות לעיתים קרובות כשבוחרים ב-vCPU מרובה עבור אפליקציה עם שרשור יחיד בגלל צורכי זיכרון גבוהים. שימוש בבו-זמניות (concurrency) כדי להניע את ההתאמה לעומס (scaling) מוביל להתאמה לעומס שמבוססת על תפוקה של בקשות. כך מובטח שיותר מופעים יופעלו כדי לטפל בעומס, וזמן ההמתנה בתור וזמן האחזור לכל מופע יצטמצמו.
מתי כדאי להגביל את מספר הבקשות המקסימלי לביצוע בו-זמני לבקשה אחת בכל פעם.
אפשר להגביל את מספר הבקשות שמועברות בו-זמנית כך שרק בקשה אחת בכל פעם תישלח לכל מופע פעיל. כדאי לעשות את זה במקרים הבאים:
- כל בקשה משתמשת ברוב המעבד או הזיכרון שזמינים.
- קובץ אימג' של הקונטיינר לא מיועד לטיפול בכמה בקשות בו-זמנית. לדוגמה, אם הקונטיינר מסתמך על מצב גלובלי ששתי בקשות לא יכולות לשתף.
שימו לב: סביר להניח שערך מקביל של 1 ישפיע לרעה על ביצועי ההתאמה לגודל, כי הרבה מופעים יצטרכו להתחיל לפעול כדי לטפל בעלייה חדה במספר הבקשות הנכנסות. במאמר תפוקה לעומת זמן אחזור לעומת פשרות מפורטים שיקולים נוספים.
מקרה לדוגמה
המדדים הבאים מציגים תרחיש לדוגמה שבו 400 לקוחות שולחים 3 בקשות בשנייה לשירות Cloud Run שהוגדר למקסימום של בקשה אחת בו-זמנית לכל מכונה. הקו העליון הירוק מציג את הבקשות לאורך זמן, והקו התחתון הכחול מציג את מספר המופעים שהופעלו כדי לטפל בבקשות.
המדדים הבאים מראים 400 לקוחות ששולחים 3 בקשות לשנייה לשירות Cloud Run שהוגדר למקסימום של 80 בקשות בו-זמניות לכל מופע. הקו הירוק העליון מציג את הבקשות לאורך זמן, והקו הכחול התחתון מציג את מספר המופעים שהופעלו כדי לטפל בבקשות. שימו לב שנדרשים הרבה פחות מקרים כדי לטפל באותו נפח בקשות.
מקביליות לפריסות של קוד מקור
כשהבו-זמניות מופעלת, Cloud Run לא מספק בידוד בין בקשות בו-זמניות שעובדו על ידי אותו מופע. במקרים כאלה, צריך לוודא שהקוד בטוח להרצה בו-זמנית. אפשר לשנות את זה על ידי הגדרת ערך שונה של בו-זמניות (concurrency). מומלץ להתחיל עם רמת בו-זמניות (concurrency) נמוכה יותר, כמו 8, ואז להגדיל אותה. התחלה עם רמת מקביליות גבוהה מדי עלולה להוביל להתנהגות לא רצויה בגלל מגבלות משאבים (כמו זיכרון או מעבד).
גם סביבות זמן ריצה של שפות יכולות להשפיע על מקביליות. חלק מההשפעות הספציפיות לשפה מפורטות ברשימה הבאה:
Node.js הוא מטבעו single-threaded. כדי לנצל את היתרונות של בו-זמניות (concurrency), צריך להשתמש בסגנון קוד אסינכרוני של JavaScript, שהוא אידיומטי ב-Node.js. פרטים נוספים זמינים במאמר בנושא בקרה על זרימת נתונים אסינכרונית בתיעוד הרשמי של Node.js.
ב-Python 3.8 ואילך, כדי לתמוך בריבוי משימות בו-זמנית בכל מופע, צריך מספיק שרשורים כדי לטפל בריבוי המשימות בו-זמנית. מומלץ להגדיר משתנה סביבה של זמן ריצה כך שערך השרשורים יהיה שווה לערך המקבילות. לדוגמה:
THREADS=8.
המאמרים הבאים
כדי לנהל את המספר המקסימלי של בקשות בו-זמניות לכל מופע של שירותי Cloud Run, אפשר לעיין במאמר בנושא הגדרת מספר מקסימלי של בקשות בו-זמניות לכל מופע.
כדי לבצע אופטימיזציה של ההגדרה 'מספר הבקשות המקסימלי בו-זמנית לכל מכונה', אפשר לעיין בטיפים למפתחים בנושא התאמת מספר הבקשות בו-זמנית.