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

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

סדר הביצוע

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

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

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

הפעלה כפולה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הערך המקסימלי של מדד עומק התור שדווח

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

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

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

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

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

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

אילוצים לגבי מיקומי משאבים

ב-Cloud Tasks יש תמיכה בהגבלת מיקומי משאבים, אבל יש מגבלות באזורים הבאים:

• us-central1
• ‫us-central2 (private Google Cloud region)

אם מציינים אחד מהאזורים במדיניות הארגון, צריך לכלול גם את us-central1 וגם את us-central2, גם אם לא יוצרים משאבי Cloud Tasks בשני האזורים. אפשר לכלול את האזור us-central2 במדיניות הארגון גם אם הארגון לא משתמש באזורים פרטיים.