הגדרת ניתוב, הגבלות וניסיונות חוזרים בתור

באמצעות Cloud Tasks אפשר לנהל את ביצוע המשימות על ידי הגדרת ניתוב, מגבלות על קצב השליחה והתנהגות ניסיון חוזר ברמת התור. אפשר להגדיר את ההגדרות האלה כשיוצרים תור או כשמעדכנים תור קיים. דגלי ההגדרה שבהם משתמשים gcloud tasks queues create או gcloud tasks queues update זהים.

הגדרת אימות ברמת התור מבטלת את האימות ברמת המשימה. למידע נוסף, ראו שימוש במשימות של HTTP Target עם אסימוני אימות.

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

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

ניתוב ברמת התור חל על:

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

מגבלות

ניתוב ברמת התור לא תואם למפתחות הצפנה בניהול הלקוח (CMEK) של Cloud Key Management Service ‏ (Cloud KMS). אם CMEK מופעל, אי אפשר לבצע את הפעולות הבאות:

• יצירת משימות ברשימת 'הבאים בתור' עם ניתוב ברמת הרשימה
• החלת ניתוב ברמת התור

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

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

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

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

     gcloud tasks queues pause QUEUE_ID
     

   מחליפים את QUEUE_ID במזהה התור.

2. עדכון או הסרה של ניתוב ברמת התור.

   • כדי לעדכן את הניתוב ברמת התור, מגדירים את הפרמטר uriOverride למסלול המעודכן.

   • כדי להסיר ניתוב ברמת התור באמצעות API ל-REST או API ל-RPC:

     • ‫API בארכיטקטורת REST: שולחים בקשת patch לתור עם מטען ייעודי (payload) ריק והפרמטר updateMask מוגדר לערך httpTarget.

     • ‫RPC API: שולחים updateQueueRequest לתור עם מטען ייעודי ריק והפרמטר update_mask מוגדר לערך http_target.

   בדוגמה הבאה נעשה שימוש ב-API בארכיטקטורת REST כדי לעדכן את המארח שאליו מנותבות המשימות:

   curl -X PATCH -d @- -i \
     -H "Authorization: Bearer ACCESS_TOKEN" \
     -H "Content-Type: application/json" \
     "https://cloudtasks.googleapis.com/v2/projects/PROJECT_ID/locations/LOCATION/queues/QUEUE_ID?updateMask=httpTarget.uriOverride" << EOF
   {
     "httpTarget": {"uriOverride":{"host":"NEW_HOST"}}
   }
   EOF
   

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

   • ‫ACCESS_TOKEN: אסימון הגישה. אפשר לקבל את זה על ידי הרצת הפקודה הבאה במסוף:

     gcloud auth application-default login
     gcloud auth application-default print-access-token

   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud . כדי לקבל את המידע הזה, מריצים את הפקודה הבאה בטרמינל:

     gcloud config get-value project

   • ‫LOCATION: המיקום של התור.

   • ‫NEW_HOST: המארח החדש שאליו רוצים להפנות את התור.

3. מחכים דקה.

   יכול להיות שיחלפו עד דקה עד שההגדרה החדשה תיכנס לתוקף. המתנה לפני חידוש התור עוזרת למנוע שליחה של משימות עם ההגדרה הישנה.

4. כדי להמשיך את התור, מריצים את הפקודה הבאה:

   gcloud tasks queues resume QUEUE_ID

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

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

1. הגדרה של ניתוב ברמת התור וביטול של ניתוב ברמת המשימה:

   gcloud tasks queues update QUEUE_ID \
       --routing-override=service:SERVICE,version:VERSION

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

   • ‫QUEUE_ID: מזהה התור (השם הקצר שלו).
   • ‫SERVICE: שירות העובדים של App Engine שאחראי לטיפול במשימות.
   • ‫VERSION: גרסת האפליקציה.

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

   gcloud tasks queues update QUEUE_ID \
       --routing-override=service:SERVICE

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

   gcloud tasks queues describe QUEUE_ID --location=LOCATION

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

   הפלט אמור להיראות כך:

   appEngineRoutingOverride:
     host: SERVICE.PROJECT_ID.appspot.com
     service: SERVICE
   name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
   rateLimits:
     maxBurstSize: 100
     maxConcurrentDispatches: 1000
     maxDispatchesPerSecond: 500.0
   retryConfig:
     maxAttempts: 100
     maxBackoff: 3600s
     maxDoublings: 16
     minBackoff: 0.100s
   state: RUNNING

3. כדי להסיר ניתוב ברמת התור, מריצים את הפקודה הבאה:

   gcloud tasks queues update QUEUE_ID \
       --clear-routing-override

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

הגדרת מגבלות קצב

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

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

   gcloud tasks queues update QUEUE_ID \
       --max-dispatches-per-second=DISPATCH_RATE \
       --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES

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

   • ‫QUEUE_ID: מזהה התור (השם הקצר שלו).
   • ‫DISPATCH_RATE: תעריף המשלוח. זהו שיעור הרענון של האסימונים בדלי. בתנאים שבהם יש זרימה יציבה יחסית של משימות, זה שווה לקצב שבו המשימות נשלחות.
   • ‫MAX_CONCURRENT_DISPATCHES: המספר המקסימלי של משימות בתור שיכולות לפעול בו-זמנית.

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

   gcloud tasks queues update QUEUE_ID \
       --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES

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

   gcloud tasks queues describe QUEUE_ID --location=LOCATION

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

   הפלט אמור להיראות כך:

   name: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID
   rateLimits:
     maxBurstSize: 100
     maxConcurrentDispatches: MAX_CONCURRENT_DISPATCHES
     maxDispatchesPerSecond: 500.0
   retryConfig:
     maxAttempts: 100
     maxBackoff: 3600s
     maxDoublings: 16
     minBackoff: 0.100s
   state: RUNNING

שיטות להגדרת קצב העיבוד של התור

אפשר להגדיר את קצב העיבוד של התור באמצעות Cloud Tasks API או באמצעות העלאה של קובץ queue.yaml. שתי השיטות יוצרות תורים שמשתמשים באותו מנגנון בסיסי.

חשוב לדעת: אפשר להשתמש בכל אחת מהשיטות כדי ליצור תורים, אבל מומלץ מאוד להשתמש בקובץ queue.yaml או ב-Cloud Tasks API כדי להגדיר את התורים, ולא בשניהם. מידע נוסף זמין במאמר שימוש בניהול תורים או בקובץ queue.yaml.

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

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

עומס לא אחיד יכול לגרום למספר האסימונים בדלי לגדול באופן משמעותי, מה שעלול להוביל לעיבוד מהיר של בקשות כשמגיעה כמות גדולה של בקשות. במקרה כזה, יכול להיות שקצב השליחה בפועל של התור יהיה גבוה מקצב max_dispatches_per_second, מה שיגרום לצריכת משאבי מערכת ולהתחרות עם בקשות להצגת מודעות למשתמשים. במקרים שבהם משתמשים בתורים כדי לנהל את שיעורי השליחה על סמך הסכמי רמת שירות (SLA) איטיים יחסית לשירותים במורד הזרם, זה עלול להוביל לשגיאות כמו HTTP 429 (יותר מדי בקשות) או HTTP 503 (השירות לא זמין).

• כשמשתמשים ב-method כלשהי של Cloud Tasks API, יש שני שדות שבהם אפשר להגדיר את קצב השליחה של התור:

  • max_dispatches_per_second
  • max_concurrent_dispatches

  השדה השלישי, max_burst_size, מחושב על ידי המערכת על סמך הערך שהגדרתם בשדה max_dispatches_per_second. מידע נוסף זמין במאמר בנושא הודעות RateLimits.

• כשמשתמשים בqueue.yaml method, אפשר להגדיר את כל שלושת הרכיבים:

  • ‫max_concurrent_requests, ששווה ל-max_concurrent_dispatches
  • ‫rate, ששווה ל-max_dispatches_per_second
  • ‫bucket_size, ששווה ל-max_burst_size

ברוב המקרים, שימוש בשיטת Cloud Tasks API והגדרה של max_burst_size על ידי המערכת יוצרים קצב יעיל מאוד לניהול של פרצי בקשות. עם זאת, במקרים מסוימים, במיוחד כשנדרש קצב איטי יחסית, אפשר לקבל יותר שליטה באמצעות שימוש בשיטה queue.yaml כדי להגדיר ידנית את bucket_size לערך קטן, או באמצעות הגדרת max_concurrent_dispatches לערך קטן באמצעות Cloud Tasks API.

הגדרת פרמטרים של ניסיון חוזר

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

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

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

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

   gcloud tasks queues update QUEUE_ID \
       --max-attempts=MAX_ATTEMPTS \
       --max-retry-duration=MAX_RETRY_DURATION \
       --min-backoff=MIN_INTERVAL \
       --max-backoff=MAX_INTERVAL \
       --max-doublings=MAX_DOUBLINGS

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

   • ‫QUEUE_ID: מזהה התור (השם הקצר שלו).
   • ‫MAX_ATTEMPTS: המספר המקסימלי של הניסיונות לביצוע משימה, כולל הניסיון הראשון. כדי לאפשר ניסיונות חוזרים ללא הגבלה, מגדירים את הערך -1. MAX_RETRY_DURATION עדיין חל גם אם מגיעים לMAX_ATTEMPTS או אם הוא מוגדר ל-1.
   • ‫MAX_RETRY_DURATION: משך הזמן המקסימלי לניסיון חוזר של משימה שנכשלה, שנמדד מהניסיון הראשון לבצע את המשימה. הערך חייב להיות מחרוזת שמסתיימת ב-s, כמו 5s. כדי לציין משך זמן בלתי מוגבל, מגדירים את הערך 0s. MAX_ATTEMPTS עדיין חל גם אם מגיעים ל-MAX_RETRY_DURATION או אם הוא מוגדר ל-0s.
   הערה: אם מציינים מספר בלתי מוגבל של ניסיונות (MAX_ATTEMPTS הוא -1) ומשך זמן בלתי מוגבל (MAX_RETRY_DURATION הוא 0s), המערכת תנסה לבצע את המשימה שוב ושוב עד שתגיע למגבלת הזמן המקסימלי לשמירת המשימה. אחרת, Cloud Tasks יפסיק את הניסיונות החוזרים רק אחרי ששני התנאים יתקיימו או שהמשימה תצליח. אחרי MAX_ATTEMPTS ניסיונות לבצע את המשימה, אם חלף הזמן שנקבע MAX_RETRY_DURATION, המערכת לא תנסה לבצע אותה יותר והיא תימחק.
   • ‫MIN_INTERVAL: משך הזמן המינימלי להמתנה בין ניסיונות חוזרים. הערך חייב להיות מחרוזת שמסתיימת ב-s, למשל 5s.
   • ‫MAX_INTERVAL: משך הזמן המקסימלי להמתנה בין ניסיונות חוזרים. הערך חייב להיות מחרוזת שמסתיימת ב-s, למשל 5s.

   • ‫MAX_DOUBLINGS: המספר המקסימלי של הפעמים שבהן המרווח בין ניסיונות חוזרים של משימה שנכשלה יוכפל לפני שההגדלה תהפוך לקבועה. מרווח הזמן בין ניסיונות חוזרים של משימה מתחיל ב-MIN_INTERVAL, מוכפל MAX_DOUBLINGS פעמים, ואז גדל באופן ליניארי. לבסוף, המערכת מנסה שוב במרווחים של MAX_INTERVAL עד MAX_ATTEMPTS פעמים.

     לדוגמה, אם MIN_INTERVAL הוא 10s,‏ MAX_INTERVAL הוא 300s ו-MAX_DOUBLINGS הוא 3, מרווח הניסיון החוזר יוכפל 3 פעמים, יגדל באופן ליניארי ב-‎2^3 * 10s, ואז יתבצע ניסיון חוזר במרווחים של MAX_INTERVAL עד שהמשימה תנסה MAX_ATTEMPTS פעמים: 10 שניות, 20 שניות, 40 שניות, 80 שניות, 160 שניות, 240 שניות, 300 שניות וכן הלאה.

פרטים נוספים על הפרמטרים זמינים בהגדרות של RetryConfig עבור המשאב Queue.

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

   gcloud tasks queues describe QUEUE_ID --location=LOCATION

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

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

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

• מידע על יצירת משימות של HTTP Target
• מידע על יצירת משימות ב-App Engine
• מידע נוסף על ניהול תורים זמין בהפניה ל-RPC API.
• מידע נוסף על ניהול תורים מופיע במאמרי העזרה של ה-API בארכיטקטורת REST.