במאמר הזה מוסבר איך להפעיל ניסיון חוזר של פונקציות Cloud Run מבוססות-אירועים. אי אפשר להגדיר ניסיון חוזר אוטומטי לפונקציות HTTP.
למה פונקציות מבוססות-אירועים לא מצליחות להסתיים
במקרים נדירים, יכול להיות שפונקציה תצא מוקדם מדי בגלל שגיאה פנימית, ובאופן כללי יכול להיות שהמערכת תנסה להפעיל אותה מחדש באופן אוטומטי או שלא.
בדרך כלל, פונקציה מבוססת-אירועים עלולה להיכשל בהשלמה בגלל שגיאות שמוחזרות בקוד הפונקציה עצמו. הסיבות האפשריות לכך:
- הפונקציה מכילה באג וזמן הריצה יוצר חריגה.
- הפונקציה לא מצליחה להגיע לנקודת קצה של שירות, או שהזמן הקצוב לתפוגה שלה מסתיים בזמן הניסיון לעשות זאת.
- הפונקציה יוצרת בכוונה חריגה (לדוגמה, כשפרמטר לא עובר אימות).
- פונקציית Node.js מחזירה הבטחה שנדחתה, או מעבירה ערך שאינו
nullלפונקציית קריאה חוזרת.
בכל אחד מהמקרים שלמעלה, הפונקציה תפסיק לפעול ותחזיר שגיאה. לגורמים להפעלת אירועים שיוצרים את ההודעות יש מדיניות ניסיון חוזר שאפשר להתאים אישית כדי לענות על הצרכים של הפונקציה.
סמנטיקה של ניסיון חוזר
פונקציות Cloud Run מספקות ביצוע של פונקציה מבוססת-אירועים לפחות פעם אחת לכל אירוע שמופק ממקור אירועים. אופן ההגדרה של ניסיונות חוזרים תלוי באופן שבו יצרתם את הפונקציה:
כשיוצרים פונקציות במסוףGoogle Cloud או באמצעות Cloud Run Admin API, צריך ליצור ולנהל בנפרד את טריגרים לאירועים. לפעולות שמפעילות פונקציות יש התנהגויות ברירת מחדל של ניסיון חוזר, שאפשר להתאים אותן לצרכים של הפונקציה.
ככלל, אי אפשר להשבית ניסיונות חוזרים לפונקציות (היוצא מן הכלל הוא פונקציות שיוצרים באמצעות Cloud Functions v2 API, שבהן ניסיונות חוזרים מושבתים כברירת מחדל). אי אפשר להשבית ניסיונות חוזרים לפונקציות שמבוססות על Cloud Run Admin API.
כשיוצרים פונקציות באמצעות Cloud Functions v2 API, הממשק יוצר באופן מרומז את טריגרי האירועים הנדרשים, למשל נושאי Pub/Sub או טריגרים של Eventarc. כברירת מחדל, ניסיונות חוזרים מושבתים עבור הטריגרים האלה, אבל אפשר להפעיל אותם באמצעות Cloud Functions v2 API.
לא משנה על איזה API מבוססת הפונקציה עם הטריגרים של Pub/Sub, אי אפשר להשתמש בתכונה של מסירת הודעות 'בדיוק פעם אחת'. ההגדרה הזו נתמכת רק במינויים מסוג pull, ולא במינויים מסוג push. הפונקציות משתמשות במינויים מסוג push.
פונקציות מבוססות-אירועים שנוצרו באמצעות Cloud Run
אם יוצרים פונקציות במסוף Google Cloud או באמצעות Cloud Run Admin API, צריך ליצור ולנהל בנפרד את טריגרים האירועים. מומלץ מאוד לבדוק את התנהגות ברירת המחדל של כל סוג טריגר:
- מדיניות הניסיון החוזר של Eventarc כוללת שמירת הודעות כברירת מחדל למשך 24 שעות עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff). אפשר לעיין בתיעוד של Eventarc בנושא ניסיון חוזר לשליחת אירועים.
- ברירת המחדל ב-Pub/Sub היא שימוש במדיניות מסירה חוזרת מיידית לכל המינויים. מידע נוסף מופיע במאמרי העזרה בנושא Pub/Sub בנושא טיפול בשגיאות בהודעות וניסיון חוזר לשליחת בקשות.
פונקציות מבוססות-אירועים שנוצרו באמצעות Cloud Functions v2 API
פונקציות שנוצרו באמצעות Cloud Functions v2 API, למשל באמצעות ה-CLI של gcloud של Cloud Functions, API בארכיטקטורת REST או Terraform, ייצרו וינהלו טריגרים לאירועים בשמכם. כברירת מחדל, אם הפעלה של פונקציה מסתיימת בשגיאה, הפונקציה לא מופעלת שוב והאירוע מושמט. כשמפעילים ניסיונות חוזרים בפונקציה מבוססת-אירועים, פונקציות Cloud Run מנסות שוב להפעיל פונקציה שנכשלה עד שהיא מסתיימת בהצלחה או עד שחלון הניסיונות החוזרים מסתיים.
כשניסיונות חוזרים לא מופעלים בפונקציה (זו ברירת המחדל), הפונקציה תמיד מדווחת שהיא בוצעה בהצלחה, וקוד התגובה 200 OK עשוי להופיע ביומנים שלה. הפעולה הזו מתרחשת גם אם הפונקציה נתקלה בשגיאה. כדי להבהיר מתי הפונקציה נתקלת בשגיאה, חשוב לדווח על שגיאות בצורה מתאימה.
הפעלה או השבתה של ניסיונות חוזרים
כדי להפעיל או להשבית ניסיונות חוזרים, אפשר להשתמש ב-Google Cloud CLI. כברירת מחדל, ניסיונות חוזרים מושבתים.
הגדרת ניסיונות חוזרים מ-Google Cloud CLI
כדי להפעיל ניסיונות חוזרים באמצעות Google Cloud CLI, צריך לכלול את הדגל --retry כשפורסים את הפונקציה:
gcloud functions deploy FUNCTION_NAME --retry FLAGS...
כדי להשבית את הניסיונות החוזרים, צריך לפרוס מחדש את הפונקציה בלי הדגל --retry:
gcloud functions deploy FUNCTION_NAME FLAGS...
חלון ניסיון חוזר
חלון הניסיון החוזר הזה יפוג אחרי 24 שעות. פונקציות Cloud Run מבצעות ניסיון חוזר של פונקציות חדשות מבוססות-אירועים באמצעות אסטרטגיית השהיה מעריכית לפני ניסיון חוזר, עם השהיה הולכת וגדלה של בין 10 ל-600 שניות.שיטות מומלצות
בקטע הזה מתוארות שיטות מומלצות לשימוש בניסיונות חוזרים.
שימוש בניסיון חוזר לתיקון שגיאות חולפות
מכיוון שהפונקציה מנסה לפעול שוב ושוב עד שהיא מצליחה, צריך לבצע בדיקות כדי לוודא שאין בקוד שגיאות קבועות כמו באגים, לפני שמפעילים ניסיונות חוזרים. השימוש בנסיונות חוזרים מומלץ לטיפול בכשלים לסירוגין או זמניים, שיש סיכוי גבוה שייפתרו בניסיון חוזר, כמו נקודת קצה של שירות לא יציב או פסק זמן.
הגדרת תנאי סיום כדי להימנע מלולאות אינסופיות של ניסיונות חוזרים
מומלץ להגן על הפונקציה מפני לולאה אינסופית כשמשתמשים בניסיונות חוזרים. כדי לעשות את זה, צריך לכלול תנאי סיום מוגדר היטב, לפני שהפונקציה מתחילה לעבד. שימו לב שהטכניקה הזו פועלת רק אם הפונקציה מתחילה לפעול בהצלחה ויכולה להעריך את תנאי הסיום.
גישה פשוטה ויעילה היא להשליך אירועים עם חותמות זמן ישנות יותר מזמן מסוים. כך אפשר למנוע ביצועים מוגזמים אם הכשלים נמשכים או ארוכים מהצפוי.
לדוגמה, קטע הקוד הזה מבטל את כל האירועים שהתרחשו לפני יותר מ-10 שניות:
Node.js
Python
Go
Java
C#
Ruby
PHP
הבחנה בין פונקציות שאפשר לנסות שוב לבין שגיאות קריטיות
אם הפעלתם ניסיונות חוזרים בפונקציה, כל שגיאה שלא טופלה תפעיל ניסיון חוזר. מוודאים שהקוד מתעד שגיאות שלא אמורות להוביל לניסיון חוזר.
Node.js
Python
Go
Java
C#
Ruby
PHP
יצירת פונקציות אידמפוטנטיות מבוססות-אירועים שאפשר לנסות להפעיל מחדש
פונקציות מבוססות-אירועים שאפשר לבצע ניסיון חוזר שלהן חייבות להיות אידמפוטנטיות. ריכזנו כאן כמה הנחיות כלליות ליצירת פונקציה אידמפוטנטית:
- הרבה ממשקי API חיצוניים (כמו Stripe) מאפשרים לספק מפתח אידמפוטנטיות כפרמטר. אם אתם משתמשים ב-API כזה, עליכם להשתמש במזהה האירוע כמפתח האידמפוטנטיות.
- אידמפוטנטיות פועלת היטב עם מסירה אחת לפחות, כי היא מאפשרת ניסיון חוזר בבטחה. לכן, שיטה מומלצת כללית לכתיבת קוד מהימן היא לשלב בין אידמפוטנטיות לבין ניסיונות חוזרים.
- חשוב לוודא שהקוד שלכם הוא אידמפוטנטי באופן פנימי. לדוגמה:
- מוודאים שהמוטציות יכולות לקרות יותר מפעם אחת בלי לשנות את התוצאה.
- שאילתת מצב מסד הנתונים בעסקה לפני שינוי המצב.
- חשוב לוודא שכל תופעות הלוואי הן אידמפוטנטיות.
- הטלת בדיקה טרנזקציונלית מחוץ לפונקציה, ללא תלות בקוד. לדוגמה, אפשר לשמור את הסטטוס במקום כלשהו שבו מתועד שמזהה אירוע מסוים כבר עבר עיבוד.
- טיפול בקריאות כפולות לפונקציות מחוץ לפס. לדוגמה, אפשר להגדיר תהליך ניקוי נפרד שמנקה אחרי קריאות כפולות לפונקציות.
הגדרת מדיניות הניסיון החוזר
בהתאם לצרכים של פונקציית Cloud Run, יכול להיות שתרצו להגדיר את מדיניות הניסיון החוזר ישירות. כך תוכלו להגדיר כל שילוב של האפשרויות הבאות:
- לקצר את חלון הניסיון החוזר מ-7 ימים ל-10 דקות בלבד.
- שינוי הזמן המינימלי והמקסימלי להשהיה באסטרטגיית הניסיון החוזר עם השהיה אקספוננציאלית.
- משנים את אסטרטגיית הניסיון החוזר לניסיון חוזר מיידי.
- מגדירים נושא להודעות ללא מוצא.
- הגדרת מספר מקסימלי ומינימלי של ניסיונות מסירה.
כדי להגדיר את מדיניות הניסיון החוזר:
- כתיבת פונקציית HTTP.
- משתמשים ב-Pub/Sub API כדי ליצור מינוי ל-Pub/Sub, ומציינים את כתובת ה-URL של הפונקציה כיעד.
במסמכי התיעוד של Pub/Sub בנושא טיפול בכשלים מופיע מידע נוסף על הגדרה ישירה של Pub/Sub.
השלבים הבאים
- פריסת פונקציות Cloud Run
- הפעלת פונקציות של טריגר Pub/Sub
- הפעלת פונקציות של טריגר Cloud Storage
- מדריך לשימוש בפונקציות Cloud Run עם Pub/Sub
- מדריך לשימוש בפונקציות Cloud Run עם Cloud Storage