אופטימיזציה של שירותי Cloud Run מפחיתה את ההוצאות על ידי התאמה של הקצאת המשאבים לביקוש בפועל. הטמעה של הגדרות חסכוניות מאפשרת למנוע הקצאת יתר של משאבים, תוך שמירה על מהימנות וביצועים של השירות. אין פתרון אחד שמתאים לכולם לאופטימיזציה של העלויות. חשוב לעקוב אחר הצרכים, התקציב והמשאבים שלכם כדי להבין מה הכי מתאים לכם.
השיטות המומלצות שמתוארות במסמך הזה רלוונטיות ל-Cloud Run. הם לא כוללים מוצרים אחרים Google Cloud .
הגדרות משאבים
כדי לבצע אופטימיזציה של השירותים מבחינת עלות, צריך לקחת בחשבון הרבה הגדרות שונות. כדאי להתאים את ההגדרות האלה לצרכים שלכם כדי ליצור שירותים אמינים וחסכוניים.
בוחרים את האזור המתאים
המיקום שבו אתם פורסים את השירות משפיע על העלות הכוללת. ב-Cloud Run יש מודל תמחור אזורי בשתי רמות. העלות לכל vCPU ולכל זיכרון באזורים ברמה 1 נמוכה יותר בהשוואה לאזורים ברמה 2, ולכן כדאי לשקול פריסה באזור ברמה 1.
נדרש אימות
כשמגדירים שירות Cloud Run, אפשר לבחור אחת משתי אפשרויות האימות:
- אפשר גישה ציבורית: לא נדרשים בדיקות אימות.
- נדרש אימות: רק משתמשים מאומתים יכולים לגשת לשירות Cloud Run.
מומלץ לדרוש אימות, אלא אם יש לכם צורך ספציפי לאפשר גישה ציבורית. כך נמנעות בקשות לא רצויות שעלולות לגרום לחיובים.
אם אתם מנהלים משתמשים באמצעות שרת proxy לאימות זהויות (IAP), יכול להיות שיהיו ל-IAP עלויות משלו.
השוואה בין חיוב לפי מופע לבין חיוב לפי בקשה
בשירותי Cloud Run יש שתי הגדרות חיוב:
- חיוב לפי בקשה (ברירת מחדל): אתם מחויבים לפי בקשה, בנוסף לתעריף גבוה יותר לשנייה על vCPU וזיכרון שנצרכו במהלך עיבוד הבקשה.
- Instance-based billing: אתם מחויבים על כל תקופת החיים של מופע. אין עמלה לכל בקשה, והתעריפים לשנייה עבור vCPU וזיכרון נמוכים יותר.
בשירותים עם תעבורה יציבה שמשתנה לאט, כדאי להשתמש בחיוב לפי מופע. החיסכון משיעורי מחשוב נמוכים ומביטול העמלה לכל בקשה גדול יותר מהעלות של תשלום על זמן בלי פעילות בין בקשות. בשירותים עם תנועת נתונים לא סדירה, עם פרצי תנועה או עם תנועת נתונים חדה, כדאי להשתמש בחיוב לפי בקשה. אם אתם עדיין לא בטוחים באיזו הגדרת חיוב כדאי להשתמש, אפשר להיעזר בשירות ההמלצות. שירות ההמלצות בודק את התנועה שהתקבלה בשירות Cloud Run בחודש האחרון, ומספק המלצות למעבר מחיוב לפי בקשה לחיוב לפי מופע, אם המעבר הזה יוזיל את העלויות.
הגדרת שינוי גודל השירות ברמת השירות
כדי ליצור בסיס להשוואה של בטיחות העלויות, מגדירים מספר מקסימלי של מופעים לשירות. הגדרה של מספר מקסימלי גבוה יותר נותנת עדיפות לזמינות, אבל עלולה להוביל לסיכונים בחיוב כתוצאה מעליות חדות לא צפויות בנפח התנועה או מהגדרות שגויות. מומלץ להגדיר את ההגדרה הזו ברמת השירות כשמפעילים את השירות בפעם הראשונה, כדי ליצור בסיס להשוואת עלויות. כדי לקבל מידע על כלים נוספים לשליטה בעלויות, אפשר לעיין במאמרים בנושא מכסות הקצאת משאבים או תקציבים והתראות לחיוב.
אופטימיזציה של ניצול המעבד (CPU) והזיכרון
העלות של שירות Cloud Run מושפעת, בין היתר, מהגדרות ה-CPU והזיכרון שלו ומהמשך הפעילות של השירות. הקצאת יתר של משאבים עלולה להגדיל את העלויות. כדי לקבוע איזו הגדרה הכי מתאימה לשירות שלכם:
- הגדרת תצורת בסיס.
- כדאי לעקוב אחרי המדדים בזמן בדיקת מדדי השימוש במעבד ובזיכרון ב-Cloud Monitoring.
- משנים את ההגדרות לפי הצורך.
אם ניצול ה-CPU נמוך באופן עקבי בעומס שיא, כדאי לצמצם את הקצאת ה-vCPU. אם זמן האחזור גבוה, כדאי להגדיל את הקצאת ה-vCPU.
אם השימוש בזיכרון נמוך באופן עקבי, כדאי להקטין את הזיכרון שהוקצה. אם זמן האחזור גבוה וניצול הזיכרון קרוב ל-100%, כדאי להגדיל את הזיכרון שהוקצה. אם אתם נתקלים בשגיאות של חריגה מזיכרון (OOM), כדאי להגדיל את הזיכרון שהוקצה או לשנות את האפליקציה כדי למנוע דליפות זיכרון או להשתמש בפחות זיכרון. כדי להבין טוב יותר את השימוש בזיכרון, אפשר לעיין בלוח הבקרה של Cloud Monitoring.
הגדרת GPU
בכל שירותי Cloud Run שמשתמשים ביחידות GPU צריך להגדיר חיוב לפי מופע. כלומר, החיוב על מכונות Cloud Run מתבצע לאורך כל מחזור החיים של המכונות, גם כשאין בקשות נכנסות. הגדרות המינימום של המעבד והזיכרון שנדרשות ליחידות GPU משפיעות גם על העלות של שירות Cloud Run. כברירת מחדל, יתירות אזורית של GPU מופעלת. השבתת יתירות אזורית של GPU מובילה לעלות נמוכה יותר לשנייה של GPU, אבל לא מבטיחה קיבולת שמורה לתרחישי יתירות כשל.
אופטימיזציה של עלויות הרשת
כשמגדירים את אפשרויות הרשת לשירות, כדאי לקחת בחשבון את הנקודות הבאות:
- מיקום משותף של המשאבים: כדאי לנסות לפרוס את שירותי Cloud Run באותו אזור שבו נמצאים מסדי הנתונים בקצה העורפי (כמו Cloud SQL או Firestore) וקטגוריות Cloud Storage. העברת נתונים בין משאבים באותו אזור היא בחינם. Google Cloud
- מעבר ל-Direct VPC egress: אם אתם מעבירים תעבורת נתונים בצורה מאובטחת למשאבי רשת VPC פנימיים, כדאי לעבור ל-Direct VPC egress ממחברי חיבור לרשת (VPC) מאפליקציית serverless. יציאה ישירה מ-VPC מתרחבת לאפס, וכך מבטלת את תקורת המחשוב הבסיסית ואת עלויות חוסר הפעילות שמשויכות למופעי מחבר.
- שימוש ב-Cloud CDN: העברת נכסים סטטיים ותוכן שניתן לשמירה במטמון בקלות על ידי הצבת Cloud CDN לפני שירותי Cloud Run. מילוי בקשות לנתונים מהקצה זול משמעותית מתשלום על תעבורת נתונים יוצאת (egress) רגילה מהאינטרנט ישירות מ-Cloud Run.
- מעקב אחרי תעבורת נתונים יוצאת (egress) באינטרנט: תעבורת נתונים נכנסת (ingress) היא תמיד בחינם, ומקבלים 1GiB של העברת נתונים יוצאת בחינם באינטרנט לחודש בצפון אמריקה. כדאי להתמקד במעקב אחר תנועה יוצאת שחוצה גבולות אזוריים או חורגת מהתוכנית בחינם.
קביעת הגדרות של פעולות בו-זמניות
כשמספר גדול יותר של מופעים מעבד בקשות, מערכת Cloud Run מקצה יותר מעבד וזיכרון בעלויות גבוהות יותר. הגדרה של מספר גבוה יותר של בקשות מקבילות מאפשרת למספר קטן יותר של מופעים לטפל באותו נפח של בקשות, וכך אפשר להפחית את העלויות. עם זאת, קוד האפליקציה צריך להיות מסוגל לטפל ביעילות בבקשות מקבילות. מידע נוסף זמין במאמר התאמת מספר התהליכים המקבילים לצורך שינוי גודל אוטומטי וניצול משאבים.
הנחות תמורת התחייבות לשימוש
בהנחות תמורת התחייבות לשימוש (CUD), אתם מקבלים הנחה בתמורה להתחייבות להשתמש ב-Cloud Run באופן רציף למשך תקופה מסוימת. הנחות CUD חלות ברמת החשבון לחיוב ב-Cloud. אפשר לרכוש הנחות תמורת התחייבות גמישה לשימוש ב-Compute עבור משאבי Cloud Run. הנחות גמישות על התחייבות לשימוש ב-Compute לא חלות על מעבדי GPU או על רשתות. פרטים נוספים מופיעים במאמר בנושא הנחה גמישה תמורת התחייבות לשימוש ב-Compute.
כלים שימושיים
אתם יכולים להשתמש בכלים הבאים כדי להבין טוב יותר את העלויות ולמנוע חריגות בתקציב.
סקירה כללית על Cloud Run: חלונית החיוב
בדף Cloud Run overview מוצגות העלויות לפי שם משאב בחלונית Billing. המספרים משקפים את העלויות ברוטו של כל משאב בטווח התאריכים שנבחר. הכלי הזה עוזר לכם להבין טוב יותר כמה עולים לכם המשאבים.
התראות לגבי תקציב
כדי לעקוב אחרי העלויות בפועל בהשוואה לעלויות המתוכננות, אפשר ליצור התראות על חריגה מהתקציב בחיוב ב-Cloud. התראה לגבי תקציב היא מנגנון התראה שמופעל כשעוברים את ספי ההוצאות, ולא מגבלת הוצאות קשיחה. יש עיכוב בנתוני החיוב, שיכול להשפיע על מועד קבלת ההתראות.
מגבלות על ניצול התקציב
אם מגדירים מגבלות הוצאה בתקציב של החיוב ב-Cloud במסוף החיוב ב-Cloud, המגבלות האלה יחולו באופן אוטומטי על כל סוגי המשאבים של Cloud Run בפרויקט.
אפשר לעקוב אחרי ההתקדמות של הגבלת ההוצאות ישירות מדף הסקירה הכללית של מסוף Cloud Run. כשמגיעים לתקרת ההוצאות, Google Cloud כל עומסי העבודה ב-Cloud Run מושהים כדי למנוע עלויות נוספות על המשאבים הבאים ב-Cloud Run:
- שירותים: כל שירות קיים לא יצליח להעביר תנועה ויחזיר שגיאות
5xx. - משימות: משימות חדשות לא מתחילות, ומשימות בתהליך לא מסתיימות.
- מאגרי עובדים: כל המופעים הקיימים מפסיקים לעבד משימות.
אם תחרגו מהגבלת ההוצאות, תקבלו התראה ויוצג באנר אכיפה במסוף Cloud Run. כדי להמשיך בפעולות, צריך להגדיל את המכסה או לשנות אותה בדף הסקירה הכללית במסוף Cloud Run.
חיוב ב-Cloud
חיוב ב-Cloud הוא אוסף של כלים שעוזרים לכם לעקוב אחרי ההוצאות ב- Google Cloud ולהבין אותן. הכלים האלה מאפשרים לעקוב אחרי עלויות השימוש, לחזות את ההוצאות ולזהות הזדמנויות לחיסכון בעלויות.
Cost Explorer
בעזרת Cost Explorer תוכלו להבין את העלות והניצול של המשאבים שלכם. אפשר להשתמש בכלי לבדיקת עלויות כדי:
- כדי לראות אילו משאבים הם הכי יקרים, מסננים את המשאבים לפי עלות.
- להבין איזה חלק מהעלויות נובע מהגדרות כמו vCPU, GPU, רשת ועוד.
- אפשר לעקוב אחרי ההשפעות של שינויים בתצורת המשאבים על החיוב החודשי.
Google Cloud מחשבון תמחור
Google Cloud בסקירת התמחור מוסבר על מודל התמחור של Google Cloud . כאן אפשר גם למצוא את רשימת המחירים המפורטת. כדי להעריך את העלויות, אתם יכולים להוסיף מוצרים ולהגדיר אותם באמצעות מחשבון התמחור.
שירות המלצות
Recommender הוא כלי שמספק המלצות ותובנות לגבי השימוש במוצרים בענן.
הכלי Recommender בודק אוטומטית את התנועה שהתקבלה בשירות Cloud Run בחודש האחרון, וימליץ לעבור מחיוב לפי בקשה לחיוב לפי מופע אם זה יהיה זול יותר.אופטימיזציה של Cloud Hub
בדף Optimization ב-Cloud Hub אפשר לראות סיכום של נתוני העלויות, נתוני השימוש והמלצות לאופטימיזציה של העלויות של שירותי Google Cloud .