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

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

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

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

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

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

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

ההשפעה של הקצאת משאבי CPU

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

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

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

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

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

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

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

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

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

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

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

שיקולי עלות

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

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

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

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

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

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

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

אם אתם משתמשים בהגדלת קיבולת ידנית במקום בתכונה של התאמה אוטומטית לעומס (automatic scaling) ב-Cloud Run, כדאי לעיין בשיקולים נוספים שמופיעים במאמר בנושא הגדלת קיבולת ידנית.

שיקולים לגבי חיוב על בסיס מופע

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

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

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

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

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

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

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

הגדרת חיוב ועדכון פרטי החיוב

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

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

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

המסוף

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

    כניסה ל-Cloud Run

  2. לוחצים על Deploy container (פריסת מאגר) כדי להגדיר שירות חדש. אם אתם מגדירים שירות קיים, לוחצים על השירות ואז על עריכה ופריסה של גרסה חדשה.

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

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

  5. לוחצים על יצירה או על פריסה.

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

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. במסוף Google Cloud , נכנסים לדף Services של Cloud Run:

    כניסה ל-Cloud Run

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

  3. לוחצים על הכרטיסייה עדכונים.

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

gcloud

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

    gcloud run services describe SERVICE --format=yaml

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