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

כברירת מחדל, 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

כדי להגדיר את הערכים של target CPU utilization ו-target concurrency utilization של עדכון נתון, מריצים את הפקודה הבאה של 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 משתמשת בו כברירת מחדל.

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

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

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

אפשר להגדיר את אמצעי הבקרה של שינוי קנה המידה באמצעות ה-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

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

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

    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. לוחצים על הכרטיסייה עדכונים.

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

gcloud

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

    gcloud run services describe SERVICE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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