בעיות ומגבלות

בדף הזה מתוארות חלק מהבעיות והמגבלות שאתם עלולים להיתקל בהן במהלך השימוש ב-Cloud Tasks.

סדר הביצוע

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

השהיה של הביצוע

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

הפעלה כפולה

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

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

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

שגיאות של השהיה חוזרת ושיעורים שנאכפים

שרתים שעמוסים מדי עשויים להתחיל להחזיר שגיאות של השהיה לפני ניסיון חוזר (backoff): HTTP 503 (ליעדים של App Engine), או HTTP 429 או 5xx (ליעדים חיצוניים). שירות Cloud Tasks מגיב לשגיאות האלה בהאטת הביצוע עד שהשגיאות מפסיקות. ההגבלה הזו מונעת עומס יתר על העובד. הערה הגדרות שצוינו על ידי המשתמש לא משתנות.

המערכת מבצעת ויסות במקרים הבאים:

• ב-Cloud Tasks, כל השגיאות גורמות להשהיה של התור. בדרך כלל נעשה שימוש בנסיגה שמצוינת ב-rate limits. אבל אם העובד מחזיר HTTP 429 Too Many Requests, 503 Service Unavailable, או אם שיעור השגיאות גבוה, Cloud Tasks משתמש בשיעור השהיה לפני ניסיון חוזר (backoff) גבוה יותר. הניסיון החוזר שצוין בכותרת התגובה של Retry-After HTTP נלקח בחשבון.

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

עליות פתאומיות בזמן האחזור ומספר מקסימלי של חיבורים בו-זמניים

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

בעיות בהדרגה עם משימות ממושכות

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

הצגת יותר מ-5,000 משימות

אם יש לכם יותר מ-5,000 משימות, חלק מהמשימות לא יוצגו במסוףGoogle Cloud . משתמשים ב-ה-CLI של gcloud כדי לראות את כל המשימות.

יצירה מחדש של תור עם אותו שם

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

יעד לא נתמך כשמשתמשים בהיקף מאובטח

אם הגדרתם גבולות גזרה מאובטחים באמצעות VPC Service Controls, בקשות HTTP מהרצה של Cloud Tasks נחסמות ליעדים שלא נתמכים, והן ייכשלו עם קוד השגיאה TARGET_TYPE_NOT_PERMITTED_FOR_VPC. מידע נוסף זמין במאמר בנושא הגדרת גבולות גזרה לשירות באמצעות VPC Service Controls.