הגדרות חיוב לשירותים

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

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

  • חיוב מבוסס-בקשה (ברירת המחדל): החיוב על מכונות של שירות Cloud Run מתבצע רק כשהן מעבדות בקשות, כשהן מתחילות לפעול וכשהן מושבתות. למידע נוסף, ראו מחזור החיים של מכונה. בעבר ההגדרה הזו נקראה CPU only allocated during request processing.

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

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

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

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

ההשפעה של הקצאת המעבד (CPU)

הגדרת החיוב שתבחרו משפיעה על אופן ההקצאה של המעבד (CPU).

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

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

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

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

  • שירותים: כל שירות קיים לא יצליח להעביר תנועה ויחזיר שגיאות 5xx.
  • משימות: הפעלות של משימות חדשות נכשלות, ומשימות שבתהליך לא מסתיימות.
  • מאגרי Worker: כל המכונות הקיימות מפסיקות לעבד משימות.
  • מכונות: כל המכונות הפועלות מושבתות, מכונות חדשות או הפעלות מחדש נכשלות, ובקשות לכתובות URL של מכונות מחזירות שגיאות 5xx.

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

איך בוחרים את הגדרת החיוב המתאימה

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

שיקולים שקשורים לדפוסי תנועה

  • חיוב מבוסס-בקשות מומלץ כשהתנועה הנכנסת היא ספורדית, מתפרצת או לא סדירה.
  • חיוב מבוסס-מכונה מומלץ כשהתנועה הנכנסת יציבה ומשתנה לאט.

שיקולים לגבי הרצה ברקע

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

  • שימוש בסוכני מעקב כמו OpenTelemetry, שעשויים להניח שהם יכולים לפעול ברקע.
  • שימוש ב-Goroutines של Go, ב-async של Node.js, ב-threads של Java וב-coroutines של Kotlin.
  • שימוש במסגרות של אפליקציות שמסתמכות על פונקציות מובנות של תזמון או של פעולה ברקע.

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

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

אם עומס העבודה שלכם דורש מכונה אחת עם משך חיים ארוך, שפועלת ברציפות במשך שעות או ימים בלי התאמה לעומס (scaling) אופקית, אתם צריכים לפרוס מכונה של Cloud Run במקום שירות. בניגוד למכונות של שירותים, שמצטמצמות אנכית בהתאם לעומס (scale down) אחרי 15 דקות לכל היותר של חוסר פעילות, מכונה של Cloud Run יכולה לפעול ללא הפרעה עד 7 ימים, והיא תומכת בכללי מדיניות להפעלה מחדש שאפשר להגדיר. לכן, מכונות Cloud Run מתאימות מאוד לסוכני AI אישיים, למנועים של תהליכי עבודה עם שמירת מצב ולסביבות פיתוח מרוחקות. לפרטים נוספים, קראו את המאמרים מתי להשתמש במכונות של Cloud Run ומחזור החיים של מכונות Cloud Run.

שיקולי עלות

אם אתם משתמשים בחיוב לפי בקשות, חיוב לפי מכונות יכול להיות חסכוני יותר אם:

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

אפשר להשתמש במחשבון עלויות כדי להעריך את ההבדלים בעלויות.

אם אתם צריכים רק מכונה אחת שפועלת באופן רציף בלי התאמה אוטומטית לעומס (automatic scaling) אופקית, מכונה של Cloud Run יכולה לעלות פחות משירות עם מספר מינימלי של מכונות וחיוב שמבוסס על מכונות. למכונות של Cloud Run יש מק"טים לתמחור משלהן, והן תומכות במודל מעבד (CPU) משותף עם קיבולת פרץ (מעבד וירטואלי בסיסי של 6.25% עם פרץ של עד 100%), מה שמוזיל את העלויות השוטפות של עומסי עבודה (workloads) מסוג סינגלטון שהם לרוב במצב של חוסר פעילות.

שיקולים לגבי התאמה אוטומטית לעומס (Autoscaling)

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

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

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

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

שיקולים לגבי חיוב לפי מכונה

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

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

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

  • עומסי עבודה ארוכי טווח במכונה אחת: אם אתם צריכים רק מכונה אחת עם שליטה ישירה במחזור החיים של ההפעלה, העצירה וההפעלה מחדש, וללא התאמה לעומס (autoscaling), השתמשו במכונה של Cloud Run.
  • עומסי עבודה מבוססי-משיכה שאינם HTTP: משתמשים במאגר של עובדי Cloud Run לצרכני רקע רציפים, כמו עובדי Pub/Sub או Kafka, שלא דורשים נקודת קצה של HTTP.

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

התפקידים הנדרשים

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

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

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

הגדרה ועדכון של החיוב

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

אם בוחרים בחיוב לפי מכונה, צריך לציין לפחות 512MiB של זיכרון.

אתם יכולים לשנות את הגדרת החיוב באמצעות מסוף Google Cloud , ה-CLI של gcloud או קובץ YAML כשאתם יוצרים שירות חדש או פורסים גרסה חדשה:

המסוף

  1. נכנסים ל-Cloud Run במסוף Google Cloud :

    כניסה ל-Cloud Run

  2. בתפריט הניווט של Cloud Run, בוחרים באפשרות Services ולוחצים על Deploy container כדי להגדיר שירות חדש. אם אתם מגדירים שירות קיים, לוחצים על השירות.

  3. אם אתם מגדירים שירות חדש, מלאו את דף ההגדרות הראשוניות של השירות.

  4. אם אתם מגדירים שירות קיים, לוחצים על הכרטיסייה Scaling.

  5. בקטע Billing, בוחרים באפשרות Request-based כדי שהמכונות יחויבו רק במהלך עיבוד הבקשה, או באפשרות Instance-based כדי שהמכונות יחויבו במשך כל משך החיים שלהן.

  6. כדי ליצור שירות חדש, לוחצים על יצירה. לוחצים על View diff & redeploy ואז על Deploy changes בשירות קיים.

gcloud

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

gcloud run services update SERVICE --no-cpu-throttling

מחליפים את SERVICE בשם השירות.

כדי להגדיר חיוב לפי בקשות:

gcloud run services update SERVICE --cpu-throttling

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

gcloud run deploy --image IMAGE_URL --no-cpu-throttling

כדי להגדיר חיוב לפי בקשות:

gcloud run deploy --image IMAGE_URL --cpu-throttling

מחליפים את IMAGE_URL בהפניה לקובץ האימג' של הקונטיינר, לדוגמה us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, המאגר REPO_NAME כבר צריך להיות קיים. הפורמט של כתובת ה-URL הוא LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.

YAML

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, הורידו את הגדרת ה-YAML שלו:

    gcloud run services describe SERVICE --format export > service.yaml

  2. מעדכנים את המאפיין cpu:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/cpu-throttling: 'BOOLEAN'
      name: REVISION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות Cloud Run
    • ‫BOOLEAN: הערך true כדי להגדיר חיוב לפי בקשה, או הערך false כדי להגדיר חיוב לפי מכונה.
    • ‫REVISION: שם גרסה חדש או מחיקה של השם (אם הוא קיים). אם אתם מספקים שם חדש לגרסה, הוא חייב לעמוד בקריטריונים הבאים:
      • מתחיל ב-SERVICE-
      • מכיל רק אותיות קטנות, מספרים ו--
      • לא מסתיים ב--
      • לא חורג מ-63 תווים

  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה:

    gcloud run services replace service.yaml

    כברירת מחדל, הפקודה gcloud run services replace משתמשת בקובץ service.yaml אם הוא קיים.

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

מוסיפים את הקוד הבא למשאב google_cloud_run_v2_service בתצורה של Terraform:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-cpu-allocation"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
      resources {
        # If true, garbage-collect CPU when once a request finishes
        cpu_idle = false
      }
    }
  }
}

צפייה בהגדרות החיוב

כדי לראות את הגדרות החיוב הנוכחיות של שירות Cloud Run:

המסוף

  1. נכנסים לדף Services של Cloud Run במסוף Google Cloud :

    כניסה ל-Cloud Run

  2. לוחצים על השירות כדי לפתוח את הדף Service details.

  3. לוחצים על הכרטיסייה התאמה לעומס כדי למצוא את ההגדרה חיוב.

gcloud

  1. מריצים את הפקודה הבאה כדי להציג את הגדרות החיוב:

    gcloud run services describe SERVICE --format=yaml

  2. בפלט ה-YAML, מחפשים את ההגדרה run.googleapis.com/cpu-throttling. הערך false מציין חיוב לפי מכונה, ואם ההגדרה הזו חסרה, החיוב הוא לפי בקשה.