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

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

סדר הביצוע

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

עיכוב בביצוע

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

הרצה כפולה

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

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

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

שגיאות השהיה ושיעורי אכיפה

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

המערכת מגבילה את קצב הבקשות במקרים הבאים:

• ‫Cloud Tasks מבצע השהיה בכל השגיאות. בדרך כלל, Cloud Tasks משתמש בהשהיה שצוינה ב-retry_config. עם זאת, אם ה-worker מחזיר תגובות שגיאה מסוג HTTP 429 Too Many Requests,‏ 503 Service Unavailable או 5xx, או אם שיעור השגיאות גבוה, Cloud Tasks אוכף קצב שליחה נמוך יותר ומביא בחשבון את העיכוב בניסיון החוזר שצוין בכותרת התגובה של HTTP Retry-After. אחרי שהשגיאות נפסקות ו-target handlers מחזירים תגובות HTTP 2xx, התור מגביר בהדרגה את קצב השליחה שנאכף.

• כדי למנוע עליות חדות בתנועה ולמתן עליות פתאומיות בעומס, Cloud Tasks מגדיל בהדרגה את מספר השליחות כשיוצרים תור חדש, כשמחדשים תור אחרי השהיה או כשהתור לא פעיל אפילו כמה דקות בלי שליחות פעילות. ההגדלה ההדרגתית הזו מתרחשת גם כשמספר גדול של משימות הופך פתאום לזמין לשליחה, למשל במהלך עלייה חדה ביצירת משימות או כשמשימות רבות מתוזמנות לאותו זמן. ממצב התחלתי או ממצב של חוסר פעילות, Cloud Tasks מתחיל לשלוח בקצב בסיסי נמוך, ומגביר בהדרגה את קצב השליחה שנאכף במרווחי הערכה תקופתיים. הקצב ימשיך לעלות עד שיגיע לקצב max_dispatches_per_second שהגדרתם, כל עוד הביקוש בתור נשאר רווי ו-target handlers מחזירים תגובות HTTP 2xx. למידע נוסף על הגדלת נפח החשיפה במצב התחלתי או במצב של חוסר פעילות, ועל ניהול תורים שהופעלו מחדש, קראו את המאמרים הגדלת נפח החשיפה הראשוני בתור ועומס יתר ביעד.

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

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

בעיות בהגדלת נפח הפעילות במשימות לטווח ארוך

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

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

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

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

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

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

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

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

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

במהלך חלון הזמן הזה של עד 3 ימים, יכול להיות שבקשה ליצירת תור תיראה כאילו היא הצליחה בלי ליצור מחדש את התור, ויכול להיות שהעלאה של קובץ queue.yaml שכולל את שם התור שנמחק תיכשל. כדי לוודא שהתור נוצר מחדש עם אותו שם, מאחזרים את התור באמצעות הפקודה gcloud tasks queues describe או השיטה projects.locations.queues.get. תגובה מוצלחת (200 OK) מאשרת שהתור נוצר מחדש.

כדי לנקות משימות או לשנות תור בלי לאבד את התור או להפעיל את תקופת ההמתנה של 3 ימים, מנקים את כל המשימות מהתור, מעדכנים את התור במקום או משהים את התור במקום למחוק וליצור אותו מחדש. אם אתם מנהלים תורים באמצעות Terraform, הגדירו את prevent_destroy = true בבלוק lifecycle כדי למנוע מחיקה של תורים בטעות.

יעד לא נתמך כשמשתמשים בפרימטר מאובטח

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

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

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

• us-central1
• us-central2 (אזור פרטי Google Cloud )

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