שירות Cloud Tasks מאפשר לכם להפריד בין חלקי עבודה שאפשר לבצע באופן עצמאי, מחוץ לזרימת האפליקציה הראשית, ולשלוח אותם לעיבוד אסינכרוני באמצעות פונקציות handler שאתם יוצרים. החלקים העצמאיים האלה של העבודה נקראים משימות. לדוגמה, אתם צריכים לעדכן מסד נתונים כחלק מעיבוד בקשת משתמש, אבל העדכונים יכולים להיות ארוכים. העברת הפרטים האלה למשימה מאפשרת לכם לחזור מהבקשה מהר יותר.
המשימה שהועברה מתווספת לתור, והיא נשמרת בו עד שהיא מבוצעת בהצלחה או עד שמגיעים למספר המקסימלי של ניסיונות חוזרים, ואז היא נמחקת. בהתאם להגדרה הראשונית, התור יכול לשמש גם ככלי לבקרה על זרימת נתונים של הקצאה. אתם יוצרים ומגדירים את התור, ומערכת Cloud Tasks מנהלת אותו. אחרי שמוסיפים משימות, התור שולח אותן ומוודא שהעובדים מעבדים אותן בצורה מהימנה. השירות מטפל במורכבויות שקשורות לתהליך הזה, כמו עלויות של זמן אחזור שמשפיע על המשתמשים, קריסות של שרתים, מגבלות על צריכת משאבים וניהול ניסיונות חוזרים.
Cloud Tasks מתוכנן לספק מסירה 'לפחות פעם אחת'. כלומר, אם משימה נוספת בהצלחה, התור יעביר אותה לפחות פעם אחת. במקרים נדירים, יכול להיות שיתבצעו כמה פעמים משימות, ולכן הקוד צריך לוודא שלא יהיו תופעות לוואי מזיקות כתוצאה מביצוע חוזר. הפונקציות לטיפול בבקשות צריכות להיות אידמפוטנטיות.
המשימות עצמן מורכבות משם ייחודי ומפרטי הגדרה, ובאופן אופציונלי, מנתונים כלשהם מהבקשה הראשונית, שנקראים מטען ייעודי (payload), שנדרשים לעיבוד הבקשה. מכיוון שהמטען הייעודי (payload) נשלח בגוף הבקשה, משימות שכוללות מטען ייעודי חייבות להשתמש ב-POST או ב-PUT כשיטת ה-HTTP שלהן.
כדי לגשת לשירות Cloud Tasks באמצעות Cloud Tasks API, צריך שיהיה לכם Google Cloud פרויקט.
תכונות
באמצעות Cloud Tasks, אתם יכולים לשלוח פריטי עבודה אסינכרוניים עם אמצעי הבקרה הבאים:
- תזמון של זמני אספקה ספציפיים
- ניהול תעריפי משלוח
- הגדרת אופן הפעולה של ניסיון חוזר
- גישה למשימות ספציפיות בתור וניהול שלהן
- הפעלת ביטול כפילויות של משימות
תהליך עבודה כללי
תהליך העבודה הכללי הוא כזה:
- יוצרים תהליך עבודה לעיבוד המשימות.
- יוצרים רשימת 'הבאים בתור'.
- אתם יוצרים משימות באופן פרוגרמטי ומוסיפים אותן לתור.
- שירות Cloud Tasks מחזיר OK לאפליקציה המקורית. המשמעות היא שהמשימה נכתבה בהצלחה לאחסון של Cloud Tasks, ולכן בקשת יצירת המשימה זמינה מאוד ועמידה.
- משימה מועברת לעובד.
- העובד מעבד את המשימה.
- כדי להשלים את הרצף, העובד מחזיר קוד סטטוס הצלחה מסוג 2xx לשירות Cloud Tasks.
אחרי שהמשימה מועברת לתור, לא מועברים נתונים לבקשה המקורית.
תרחישים לדוגמה
תרחישים נפוצים לדוגמה:
- קיצור זמני התגובה של המשתמשים על ידי הקצאת פעולות רקע איטיות כמו עדכוני מסד נתונים לעובד
- שמירת בקשות בהקשר של אירועי ייצור בלתי צפויים
- הסרת משימות שלא מוצגות למשתמשים מהזרימה הראשית של המשתמשים כדי למתן את העליות החדות בנפח התנועה
- ניהול שיעורי קריאות ל-API של צד שלישי
תורים ב-Cloud Tasks עם יעדי HTTP
במקרה של יעדי HTTP כלליים, שירות Cloud Tasks מעביר את בקשת המשימה אל העובד, שנמצא בכל נקודת קצה כללית של HTTP, בהתאם לאופן שבו המשימה מוגדרת. נקודת הקצה הזו יכולה להיות ב-Cloud Run functions, ב-Cloud Run, ב-GKE, ב-Compute Engine או אפילו בשרת אינטרנט מקומי, בהתאם להגדרת המשימה. התורים האלה שולחים בקשות בקצב אמין שניתן להגדרה. הם מבטיחים ביצוע אמין של משימות. אם הפעולה מצליחה, כל העובדים צריכים לשלוח קוד תגובה מסוג HTTP (200-299) לשירות Cloud Tasks לפני תפוגת הזמן הקצוב שמוגדר כברירת מחדל (10 דקות), עם מקסימום של 30 דקות. אם נשלחת תגובה אחרת או לא נשלחת תגובה, המשימה מנסה שוב.
מערכת היעד צריכה לנהל את שינוי הגודל של העובדים ולנקות את המשימות לאחר שהן הושלמו.
אם היעד שלכם דורש אימות, אתם צריכים להגדיר שני חשבונות שירות: אחד לאפליקציה וללקוח, ואחד לתור עצמו. לשני החשבונות צריכות להיות ההרשאות הנדרשות, ובבקשת המשימה צריך להיכלל מזהה של חשבון השירות של הלקוח. מידע נוסף זמין במאמר בנושא יצירת משימות HTTP Target.
תורי משימות ב-Cloud Tasks עם יעדים ב-App Engine
Cloud Tasks תואם לסביבות App Engine הבאות:
- סביבות זמן ריצה מהדור השני בסביבה הרגילה של App Engine
- סביבה גמישה של App Engine
משתמשים בסביבות ריצה מהדור הראשון של App Engine שמשתמשים ב-Task Queue API יכולים לעבור ל-Cloud Tasks. במאמר מעבר משירותים בחבילה מדור קודם מוסבר איך עושים זאת. משתמשים בסביבות זמן ריצה מהדור הראשון של App Engine שלא משתמשים בשירות המשימות בחבילה יכולים לשדרג לסביבות זמן ריצה מהדור השני כדי להשתמש ב-Cloud Tasks.
במקרה של יעדים ב-App Engine, שירות Cloud Tasks מעביר גם את בקשת המשימה ל-handler, אבל הוורקר הזה נמצא ב-App Engine. לכן, לכל התורים שמיועדים לטיפול ב-App Engine חייבת להיות אפליקציית App Engine. המטפלים חייבים לפעול באזור שבו אפליקציית App Engine פועלת. האזור הזה משמש גם כפרמטר LOCATION_ID לבקשות שלכם ב-Cloud Tasks.
המשימות מנותבות בהתאם לאופן שבו המשימה (או, לעיתים רחוקות יותר, התור עצמו) מוגדרת. התורים שולחים בקשות בקצב אמין שניתן להגדרה. הם מבטיחים ביצוע מהימן של משימות – אם הפעולה מצליחה, כל העובדים צריכים לשלוח קוד תגובת HTTP (200-299) לשירות Cloud Tasks, במקרה הזה לפני תאריך היעד בהתאם לסוג התאמה לעומס (scaling) של המופע של השירות: 10 דקות להתאמה אוטומטית לעומס או עד 24 שעות להתאמה ידנית לעומס. אם נשלחת תשובה אחרת או לא נשלחת תשובה בכלל, המשימה מנסה שוב.
מכיוון שהמטפלים הם חלק מ-App Engine, שירות Cloud Tasks יכול לבצע חלק גדול מניהול התהליך של המשימה, להגדיל או להקטין את מספר העובדים בהתאם לתנועה ולמחוק משימות כשהן מסתיימות.
אזורים נתמכים לפי יעד
אם היעד הוא נקודת קצה של HTTP/S, Cloud Tasks זמין בכל האזורים הנתמכים Google Cloud של Cloud Tasks.
אם היעד הוא אפליקציית App Engine שנמצאת בפרויקט הנוכחי:
אפשר ליצור משימה שמטרגטת App Engine רק באזור של App Engine בפרויקט.
פרויקט יכול להכיל רק אפליקציית App Engine אחת, ואי אפשר לשנות את האזור שבו אפליקציית App Engine ממוקמת אחרי שהאפליקציה נוצרת. Google Cloud
App Engine הוא אזורי, כלומר התשתית שמריצה את האפליקציה שלכם ממוקמת באזור ספציפי. אם רוצים לפזר את העומס של החישובים והתורים בין כמה אזורים, צריך לטרגט נקודת קצה של HTTP/S.
אם אתם לא משתמשים ב-App Engine כיעד, אתם לא צריכים לפרוס אפליקציית App Engine, ואתם יכולים להשבית כל אפליקציית App Engine קיימת.
ביטול כפילויות של משימות
כדי לבטל כפילויות של משימות, צריך להקצות לכל משימה שם ייחודי. אם תנסו ליצור משימה עם שם שכבר קיים בתור, בקשת היצירה תיכשל. כך נמנעת הוספה של אותה משימה יותר מפעם אחת.
שמות המשימות נשמרים ב-Cloud Tasks עד 24 שעות אחרי שהמשימה נמחקה מהתור. ניסיון ליצור מחדש משימה עם אותו שם במהלך הזמן הזה יוביל גם הוא לבקשה שנכשלה.
אם לא מציינים שם כשיוצרים משימה, Cloud Tasks ייצור שם ייחודי בשבילה, ולא צריך לבצע ביטול כפילויות. שימו לב: אי אפשר להסתמך על הכותרות X-CloudTasks-TaskETA ו-X-AppEngine-TaskETA כדי לבצע ביטול כפילויות בצורה מהימנה.
מונחי מפתח
המונחים הבאים מתארים יכולות מרכזיות של Cloud Tasks.
| מונח | הגדרה |
|---|---|
| ניסיון | ניסיון להריץ משימה. |
| ניסיון שליחה | הרגע שבו Cloud Tasks שלח את המשימה ליעד שלה. |
| ניסיון תגובה | תגובה מעובד שמציינת שהעבודה שמשויכת למשימה הושלמה בהצלחה או נכשלה. |
| handler | קוד האפליקציה (שנקרא גם worker) שאחראי על עיבוד המשימות. כש-Cloud Tasks שולח משימה מהתור, הוא שולח בקשה לשירות יעד, והקוד בנקודת הקצה שמקבל ומבצע את המשימה הוא ה-handler. |
| תור | קבוצת משימות עם אותו סוג יעד שמנוהלת על ידי הגדרה אחת. |
| הגבלות קצב | קובעת את הקצב שבו התור יכול לשלוח משימות, בלי קשר לשאלה אם השליחה היא ניסיון ראשון או ניסיון חוזר. |
| ניסיון נוסף | כמה ניסיונות להפעלת משימה. מספר הניסיונות החוזרים מוגדר באמצעות פרמטרים של ניסיונות חוזרים. |
| סוג היעד | איפה ואיך המשימה מעובדת. אפשר לטרגט נקודת קצה של HTTP או אפליקציית App Engine. |
| משימה | יחידת העבודה הבסיסית שרוצים להפעיל באופן אסינכרוני. הוא מייצג יחידת עבודה עצמאית שמוסיפים לתור כדי ש-Cloud Tasks יעבד אותה מחוץ לתהליך הראשי של האפליקציה. |
| worker | שירות שמבצע משימות. מידע נוסף זמין בהגדרה של handler. |
ניראות (observability)
אתם יכולים לעקוב אחרי הפעילות והצמיחה של Cloud Tasks ולנתח אותן באמצעות כלים לניטור, לרישום ביומן ולאבחון שזמינים ב-Google Cloud Observability. מידע נוסף זמין במאמר בנושא יכולת צפייה ב-Cloud Tasks.