ניסיון חוזר של בקשות שנכשלו

בדף הזה מופיע תיאור של שיטות מומלצות לניסיון חוזר של בקשות שנכשלו ל-API של ניהול זהויות והרשאות גישה (IAM).

לבקשות שאפשר לבצע להן ניסיון חוזר בבטחה, מומלץ להשתמש בהשהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff) עם תוספת של רעידות.

סקירה כללית של השהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff)

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

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

האלגוריתם של השהיה מעריכית לפני ניסיון חוזר (exponential backoff)

האלגוריתם הבא מיישם השהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff) עם רעידות:

  1. שליחת בקשה ל-IAM.
  2. אם הבקשה נכשלת, צריך להמתין ‎1 + random-fraction‎ שניות, ולאחר מכן לנסות שוב את הבקשה.
  3. אם הבקשה נכשלת, צריך להמתין ‎2 + random-fraction‎ שניות, ולאחר מכן לנסות שוב את הבקשה.
  4. אם הבקשה נכשלת, צריך להמתין ‎4 + random-fraction‎ שניות, ולאחר מכן לנסות שוב את הבקשה.
  5. צריך להמשיך בדפוס הזה ולהמתין ‎2n + random-fraction‎ שניות אחרי כל ניסיון חוזר, עד זמן של maximum-backoff.
  6. אחרי deadline שניות צריך להפסיק לנסות מחדש את הבקשה.

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

  • לפני כל ניסיון חוזר, זמן ההמתנה הוא min((2n + random-fraction), maximum-backoff), שבו n מתחיל ב-0 וגדל ב-1 בכל ניסיון חוזר.
  • מחליפים את random-fraction בערך עשרוני אקראי שקטן מ-1 או שווה לו. צריך להשתמש בערך שונה בכל ניסיון חוזר. הוספת ערך אקראי הזה מונעת סנכרון של לקוחות ושליחה של מספר גדול של ניסיונות חוזרים בו-זמנית.
  • מחליפים את maximum-backoff במספר השניות המקסימלי שצריך להמתין בין הניסיונות החוזרים. הערכים האופייניים הם 32 או 64 (‎25 או ‎26) שניות. צריך לבחור את הערך המתאים ביותר לתרחיש לדוגמה שלכם.
  • מחליפים את deadline במספר השניות המקסימלי לשליחת ניסיונות חוזרים. צריך לבחור ערך שמשקף את התרחיש לדוגמה שלכם. לדוגמה, בצינור עיבוד נתונים של CI/CD לאינטגרציה/פריסה רציפה שלא רגיש מאוד לזמן, כדאי להגדיר את deadline ל-300 שניות (5 דקות).

סוגי שגיאות לניסיונות חוזרים

צריך להשתמש באסטרטגיה הזו של ניסיונות חוזרים לכל הבקשות ל-API של IAM שמחזירות את קודי השגיאות 500, 502, 503 או 504.

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

בנוסף, צריך להשתמש בגרסה מתוקנת של האסטרטגיה הזו לניסיונות חוזרים לכל הבקשות ל-API של IAM שמחזירות את קוד השגיאה 409 ואת הסטטוס ABORTED. סוג השגיאה הזה מעיד על בעיה של בו-זמניות (concurrency). לדוגמה, ייתכן שאתם מנסים לעדכן מדיניות הרשאה שלקוח אחר כבר החליף. לטיפול בסוג השגיאה הזה, צריך תמיד לנסות שוב את כל סדרת הבקשות קריאה-שינוי-כתיבה, באמצעות השהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff) עם תוספת רעידות. אם תנסו שוב רק את פעולת הכתיבה, הבקשה תמשיך להיכשל.

המאמרים הבאים