שיטות מומלצות לאופטימיזציה של העלויות בשירותי Cloud Run

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

השיטות המומלצות שמתוארות במסמך הזה ספציפיות ל-Cloud Run. הם לא כוללים מוצרים אחרים Google Cloud .

הגדרות משאבים

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

בוחרים את האזור המתאים

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

נדרש אימות

כשמגדירים שירות Cloud Run, אפשר לבחור אחת משתי אפשרויות האימות:

  • אפשר גישה ציבורית: לא נדרשים בדיקות אימות.
  • נדרש אימות: רק משתמשים מאומתים יכולים לגשת לשירות Cloud Run.

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

אם אתם מנהלים משתמשים באמצעות שרת proxy לאימות זהויות (IAP), יכול להיות שיהיו ל-IAP עלויות משלו.

השוואה בין חיוב לפי מופע לבין חיוב לפי בקשה

בשירותי Cloud Run יש שתי הגדרות חיוב:

  • חיוב לפי בקשה (ברירת מחדל): אתם מחויבים לפי בקשה, בנוסף לתעריף גבוה יותר לשנייה על vCPU וזיכרון שנצרכו במהלך עיבוד הבקשה.
  • חיוב לפי מופע: אתם מחויבים על כל תקופת החיים של מופע. אין עמלה לכל בקשה, והתעריפים לשנייה עבור vCPU וזיכרון נמוכים יותר.

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

הגדרת שינוי גודל השירות ברמת השירות

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

אופטימיזציה של ניצול המעבד והזיכרון

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

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

אם ניצול ה-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
  • מעבר לתעבורת נתונים יוצאת (egress) ישירה של VPC: אם אתם מנתבים תנועה בצורה מאובטחת למשאבי רשת פנימיים של VPC, כדאי לשקול מעבר לתעבורת נתונים יוצאת (egress) ישירה של VPC ממחברי חיבור לרשת (VPC) מאפליקציית serverless. יציאה ישירה מ-VPC מתרחבת לאפס, וכך מבטלת את התקורה הבסיסית של המחשוב ואת העלויות של מצבי חוסר פעילות שמשויכות למופעי מחבר.
  • שימוש ב-Cloud CDN: הפחתת עומס של נכסים סטטיים ותוכן שניתן לשמירה במטמון בקלות על ידי הצבת Cloud CDN לפני שירותי Cloud Run. מילוי בקשות לנתונים מהקצה זול משמעותית מתשלום על יציאת נתונים רגילה מהאינטרנט ישירות מ-Cloud Run.
  • מעקב אחרי תעבורת נתונים יוצאת (egress) באינטרנט: תעבורת נתונים נכנסת (ingress) היא תמיד בחינם, ומקבלים 1GiB של העברת נתונים יוצאת בחינם באינטרנט לחודש בצפון אמריקה. כדאי להתמקד במאמצי המעקב אחר תנועה יוצאת שחוצה גבולות אזוריים או חורגת מהרמה החינמית.

קביעת הגדרות של פעולות בו-זמניות

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

הנחות תמורת התחייבות לשימוש

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

כלים שימושיים

אתם יכולים להשתמש בכלים הבאים כדי להבין טוב יותר את העלויות ולמנוע חריגות מהתקציב.

סקירה כללית על Cloud Run: חלונית החיוב

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

התראות לגבי תקציב

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

חיוב ב-Cloud

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

Cost Explorer

כלי ניתוח העלויות מאפשר לכם להבין את העלות והניצול של המשאבים שלכם. אפשר להשתמש ב-Cost Explorer כדי:

  • מסננים את המשאבים לפי עלות כדי לראות אילו משאבים הם הכי יקרים.
  • להבין איזה חלק מהעלויות נובע מהגדרות כמו vCPU,‏ GPU,‏ רשת ועוד.
  • אפשר לעקוב אחרי ההשפעות של שינויים בתצורת המשאבים על החיוב החודשי.

Google Cloud מחשבון תמחור

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

שירות המלצות

Recommender הוא כלי שמספק המלצות ותובנות לגבי השימוש במוצרי Cloud.

הכלי Recommender בודק אוטומטית את התנועה שהתקבלה בשירות Cloud Run בחודש האחרון, וימליץ לעבור מחיוב לפי בקשה לחיוב לפי מופע, אם זה יהיה זול יותר.

אופטימיזציה של Cloud Hub

בדף Optimization ב-Cloud Hub אפשר לראות נתוני עלות מסוכמים, נתוני שימוש והמלצות לאופטימיזציה של עלויות Google Cloud שירותים.