הגדרת אמצעי בקרה מותאמים אישית לשינוי גודל של שירותים

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

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

  • יעד הניצול להתאמת גודל לפי מעבד
  • ניצול יעד עבור קנה מידה מבוסס מקביליות

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

מגבלות על הגדרות אישיות

המגבלות הבאות חלות על יעדי התאמה אישית של קנה המידה:

מנהל התקן קנה מידה אחוז ברירת מחדל אחוז מינימלי שניתן להגדרה האחוז המקסימלי שניתן להגדרה
CPU target utilization 60% ‫10% ‪95%
Concurrency target utilization 60% ‫10% ‪95%

הבעת הסכמה להתנהגות משופרת של התאמה להיקף

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

כדי להצטרף, אפשר להשתמש ב-CLI של gcloud או ב-YAML כשפורסים גרסה חדשה.

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

gcloud

הגדר את ערכי ניצולת המעבד היעד ואת ערכי ניצולת המקביליות היעד של גרסה נתונה על ידי הפעלת הפקודה gcloud beta run services update הבאה:

gcloud beta run services update SERVICE --scaling-cpu-target=0.6 \
--scaling-concurrency-target=0.6

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

YAML

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

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

  2. מוסיפים את המאפיינים run.googleapis.com/scaling-cpu-target ו-run.googleapis.com/scaling-concurrency-target.

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/scaling-cpu-target: '0.6'
        run.googleapis.com/scaling-concurrency-target: '0.6'

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

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

    gcloud run services replace service.yaml

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

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

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

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

אפשר להגדיר את אמצעי הבקרה של שינוי קנה המידה באמצעות ה-CLI של gcloud או YAML כשפורסים גרסה חדשה.

gcloud

כדי לעדכן את הערכים של ניצול היעד של CPU ושל ניצול היעד של מקביליות בגרסה נתונה, מריצים את הפקודה gcloud beta run services update.

  • כדי לעדכן את יעד ניצול המעבד, מריצים את הפקודה הבאה:

    gcloud beta run services update SERVICE --scaling-cpu-target=CPU_TARGET

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

    • ‫SERVICE: השם של השירות.

    • ‫CPU_TARGET: יעד ניצול המעבד. מציינים ערך בין 0.1 ל-0.95. אפשר להגדיר עד שתי ספרות אחרי הנקודה העשרונית.

  • כדי לעדכן את יעד הניצול של הפעלה מקבילה, מריצים את הפקודה הבאה:

    gcloud beta run services update SERVICE --scaling-concurrency-target=CONCURRENCY_TARGET

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

    • ‫SERVICE: השם של השירות.

    • ‫CONCURRENCY_TARGET: היעד לניצול של מקביליות. מציינים ערך בין 0.1 ל-0.95. אפשר להגדיר עד שתי ספרות אחרי הנקודה העשרונית.

  • כדי לעדכן גם את יעד השימוש במעבד וגם את יעד השימוש במקביליות, מריצים את הפקודה הבאה:

    gcloud beta run services update SERVICE --scaling-cpu-target=CPU_TARGET \
--scaling-concurrency-target=CONCURRENCY_TARGET

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

    • ‫SERVICE: השם של השירות.
    • ‫CPU_TARGET: יעד ניצול המעבד. מציינים ערך בין 0.1 ל-0.95. אפשר להגדיר עד שתי ספרות אחרי הנקודה העשרונית.
    • ‫CONCURRENCY_TARGET: היעד לניצול של מקביליות. מציינים ערך בין 0.1 ל-0.95. אפשר להגדיר עד שתי ספרות אחרי הנקודה העשרונית.

YAML

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

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

  2. כדי לעדכן את יעד השימוש במעבד ואת רמת הניצול של פעולות מקבילות, מוסיפים את המאפיינים run.googleapis.com/scaling-cpu-target ו-run.googleapis.com/scaling-concurrency-target:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/scaling-cpu-target: 'CPU_TARGET'
        run.googleapis.com/scaling-concurrency-target: 'CONCURRENCY_TARGET'

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

    • ‫SERVICE: השם של השירות.
    • ‫CPU_TARGET: יעד ניצול המעבד. מציינים ערך בין 0.1 ל-0.95. אפשר להגדיר עד שתי ספרות אחרי הנקודה העשרונית.
    • ‫CONCURRENCY_TARGET: היעד לניצול של מקביליות. מציינים ערך בין 0.1 ל-0.95. אפשר להגדיר עד שתי ספרות אחרי הנקודה העשרונית.

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

    gcloud run services replace service.yaml

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

השבתת אמצעי הבקרה של שינוי הגודל

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

אפשר להשבית את אמצעי הבקרה של התאמה לעומס (scaling) באמצעות ה-CLI של gcloud או YAML כשפורסים גרסה חדשה.

gcloud

ניתן להשבית את ניצול המעבד היעד (CPU use) או את ניצול המקביל היעד (concurrency utilization) על ידי הפעלת הפקודה gcloud beta run services update.

  • כדי להגדיל את הקיבולת רק לפי CPU, משביתים את יעד המקבילות על ידי הרצת הפקודה הבאה:

    gcloud beta run services update SERVICE --scaling-concurrency-target=disabled

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

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

    gcloud beta run services update SERVICE --scaling-cpu-target=disabled

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

YAML

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

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

  2. כדי להגדיל את מספר התהליכים רק לפי מעבד, משביתים את יעד המקבילות על ידי הגדרת המאפיין run.googleapis.com/scaling-concurrency-target לערך disabled:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/scaling-concurrency-target: disabled

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

  3. כדי להגדיל את הגודל רק לפי בו-זמניות, יש להשבית את יעד המעבד על ידי הגדרת המאפיין run.googleapis.com/scaling-cpu-target ל-disabled:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/scaling-cpu-target: disabled

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

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

    gcloud run services replace service.yaml

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

שחזור לערכי ברירת המחדל

כשמשחזרים את ערכי היעד של ה-CPU או של ניצול המקביליות לערכי ברירת המחדל, יוצאים מהשימוש בתכונה 'אמצעי בקרה לשינוי קנה מידה'. אפשר לשחזר את אמצעי הבקרה של התאמה לעומס לערכי ברירת המחדל באמצעות ה-CLI של gcloud או YAML כשפורסים גרסה חדשה.

gcloud

כדי לשחזר את ניצול היעד של CPU ואת ניצול היעד של פעולות בו-זמניות לערכי ברירת המחדל שלהם, מריצים את הפקודה gcloud beta run services update.

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

    gcloud beta run services update SERVICE --scaling-cpu-target=default

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

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

    gcloud beta run services update SERVICE --scaling-concurrency-target=default

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

  • כדי לשחזר את יעד ניצול המעבד ואת יעד הפעולות המקבילות לערכי ברירת המחדל שלהם, מריצים את הפקודה הבאה:

    gcloud beta run services update SERVICE --scaling-cpu-target=default \
--scaling-concurrency-target=default

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

YAML

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

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

  2. כדי לשחזר את ניצול המעבד והניצול בבו-זמניות ליעדי ברירת המחדל שלהם, הסר את המאפיינים run.googleapis.com/scaling-cpu-target ו-run.googleapis.com/scaling-concurrency-target מקובץ ה-YAML שלך:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA
  name: SERVICE
spec:
  template:
    metadata:
      # Remove the scaling target annotations to restore defaults
    ...

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

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

    gcloud run services replace service.yaml

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

צפייה בהגדרות של שינוי הגודל

אפשר לראות את הגדרות ההתאמה לעומס באמצעות ה-CLI של gcloud או YAML.

המסוף

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

    כניסה ל-Cloud Run

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

  3. לחץ על הכרטיסייה קנה מידה כדי להציג את הגדרות קנה המידה.

gcloud

  1. משתמשים בפקודה הבאה:

    gcloud run services describe SERVICE

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

  2. מחפשים את הערך של ההגדרות Target CPU utilization:‎ (ניצול יעד של CPU) ו-Target concurrency utilization:‎ (ניצול יעד של פעולות בו-זמניות) בתצורה שהוחזרה.

שיטות מומלצות

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

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

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

    2. מחפשים את המדד run.googleapis.com/scaling/recommended_instances ובוחרים אותו, ומגדירים את Aggregation (צבירת נתונים) לערך Unaggregated (לא מצטבר) כדי לראות את המדד מקובץ לפי הגורם המניע את ההתאמה.

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

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

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

מידע על יעדים של ניצול נמוך

הורדת יעד הניצול למינימום של 0.1 (10%) משנה באופן משמעותי את האופן שבו השירות שלכם מתרחב.

היתרונות של הגדרת יעד ניצול נמוך כוללים:

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

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

חסרונות בהגדרת יעדים נמוכים של ניצול:

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

המאמרים הבאים