שיטות מומלצות לשליחת הודעות FCM בקנה מידה נרחב

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

מונחים ומושגים מרכזיים

בקשת הודעה: בקשת הודעה ב-FCM. אפשר להשתמש ב'בקשה', 'הודעה' או 'שאילתה' במקום 'בקשת הודעה'.

בקשות לשנייה (RPS): מדד שמתאר את קצב הבקשות הנכנסות ל-FCM. אפשר להשתמש בו במקום 'שאילתות לשנייה (QPS)'.

אסימוני מכסה, קטגוריות של אסימונים ומילוי מחדש: כששולחים הודעות באמצעות FCM HTTP v1 API, כל בקשה צורכת אסימון מכסה שהוקצה לה בחלון זמן נתון. החלון הזה, שנקרא קטגוריית אסימונים, מתאפס בסוף חלון הזמן. לדוגמה: ה-API של HTTP v1 מקצה 600,000 אסימוני מכסה לכל קטגוריית אסימונים של דקה אחת, והיא מתמלאת מחדש עד לסף המקסימלי בסוף כל חלון של דקה אחת.

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

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

השהיה מעריכית לפני ניסיון חוזר (exponential backoff): כשמנסים שוב לבצע פעולה שהתקבלה עבורה שגיאה, מוסיפים עיכובים הולכים וגדלים. לדוגמה: 1s,‏ 2s,‏ 4s,‏ 8s,‏ 16s,‏ 32s וכן הלאה.

רעידות: הימנעות מניסיון חוזר לבקשות במרווחי זמן מדויקים. כשמשתמשים בתנודות, משנים את עיכובי הניסיון החוזר באמצעות תהליך אקראי כדי לחלק אותם באופן אחיד לאורך זמן (לדוגמה: 0.9 שניות, 2.3 שניות, 4.1 שניות, 8.5 שניות, 17.9 שניות, 34.7 שניות).

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

הבעיה: עליות חדות בנפח התנועה

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

מהי תנועה חדה (spikey)?

יש כמה סוגים שונים של עליות חדות בתנועה.

עליות חדות בשעה: FCM מקבלת יותר מכפולת התנועה במהלך 30 השניות הראשונות עד 2 הדקות הראשונות של כל שעה. עליות חדות דומות, אם כי קטנות יותר, נצפו גם בשעה וחצי ובשעה ורבע (לדוגמה: 00:15, ‏ 00:30, ‏ 00:45).

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

שינויים חדים בדפוסי התנועה: הפניה של תנועה חדשה ל-FCM או העברת תנועה ל-FCM באזורים שונים ללא גורמים להחלשה של העלייה, כמו עלייה הדרגתית, עלולה לגרום לעליות חדות בתנועה.

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

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

פתרון תנודות חדות בנפח התנועה באמצעות 'שיטת השטחת העקומה'

בקטע הזה מתוארות אסטרטגיות להחלשת תנודות חדות בנפח התנועה, ככל האפשר – אסטרטגיות ל'שיטוח העקומה'.

שימוש ב-FCM רק בתרחישים המתאימים

יש תרחישי שימוש מסוימים שבהם השימוש ב-FCM לשליחת התראה לא הכרחי או לא מתאים.

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

הימנעות מעליות חדות בנתונים

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

• האם כל הלקוחות צריכים לקבל את אותה ההודעה בחלון זמן של דקה אחת? לדוגמה, האם חלון זמן מסירה של 5 דקות עדיין יענה על הצרכים העסקיים שלך?
• האם אפשר לפלח את הלקוחות לפי תעדוף כדי לצמצם את העליות החדות בתנועה?
• האם אפשר לתזמן את ההתראות מראש?

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

הימנעות מפקקים בשעות השיא

ככל האפשר: הימנעו משליחת הודעות בחלון של 2 דקות מכל אחד מהסימנים של 00,‏ 15,‏ 30 ו-45 דקות.

הטמעת ויסות בצד השרת

הטמעת הגבלת קצב העברת נתונים בצד השרת כדי לעקוב אחרי תעבורת הנתונים ל-FCM ולנהל אותה.

טיפול בניסיונות חוזרים

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

זמנים קצובים לתפוגה

מגדירים זמן קצוב של 10 שניות לפחות לתפוגה של בקשות שליחה לפני ניסיון חוזר. ברוב הקריאות הפנימיות לפרוצדורות מרוחקות (RPC) של FCM נעשה שימוש בזמן קצוב לתפוגה של 10 שניות.

שגיאות

• בשגיאות 400,‏ 401,‏ 403 ו-404: מבטלים ולא מנסים שוב.
• בשגיאות מסוג 429: מנסים שוב אחרי שממתינים למשך הזמן שמוגדר בכותרת retry-after. אם לא מגדירים כותרת retry-after, ברירת המחדל היא 60 שניות.
• במקרה של שגיאות מסוג 500: מנסים שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).

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

כדי למנוע הגברה של ניסיונות חוזרים, מומלץ להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) עם רעידות (jitter) לבקשות לניסיון חוזר. לדוגמה, ב-Firebase Admin SDK מופעלת השהיה מעריכית.

ריכזנו כאן כמה הגדרות מומלצות נוספות:

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

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

ליצור תוכניות להשקה ולביטול השקה, ולבצע שינויים הדרגתיים

כשמבצעים שינויים בהיקף רחב בתנועה, כמו הגדלת התנועה ל-FCM או העברת תנועה בין אזורים או רשתות, תכנון תוכנית השקה או תוכנית ביטול השקה והטמעת שינויים הדרגתיים יעזרו להגן על המשתמשים, השירות ו-FCM.

• תוכנית ההשקה מאפשרת לבעלי העניין להתאים את הציפיות שלהם. במצבים מסוימים (שיפורטו בהמשך), מומלץ לשתף מראש את תוכנית ההשקה עם צוות FCM כדי למנוע הפתעות.
• תוכנית חזרה לאחור מאפשרת לכם להביא בחשבון תרחישים שונים ולהכין מנגנונים לשחזור מהיר ובטוח מכשלים בלתי צפויים.
• לשינויים הדרגתיים יש שני היבטים:
  • עלייה "מדורגת": השלבים צריכים להיות 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% או עדינים יותר. 'הטמעה לטווח ארוך' (מעקב אחר התנהגות המערכת בעומס) בכל שלב למשך יום עד שבוע. כך תוכלו לזהות בעיות פוטנציאליות לפני ה'שדרוג' הבא.
  • הגדלת עומס התנועה בהדרגה: בכל 'שלב' להגדלת עומס התנועה, כדאי להגדיל את עומס התנועה בהדרגה לאורך שעה לפחות. כך התשתית של FCM לאיזון עומסים יכולה להתאים את עצמה לתנועה החדשה תוך צמצום הסיכון לנקודות חמות ולעומסים.

לפניכם תרחיש היפותטי להעברה של 500,000 בקשות לשנייה (RPS) ברחבי העולם מ-FCM Legacy HTTP API ל-FCM HTTP v1 API:

שבוע	שלב	אסטרטגיה להגדלת הנפח בהדרגה
0	הגדלת נפח של 1%	הגדלה הדרגתית של הקצב מ-0 ל-5,000 בקשות לשעה ל-FCM HTTP v1 במהלך שעה.
1	הגדלת נפח החשיפה ב-5%	הגדלה הדרגתית של קצב הבקשות לשעה מ-5,000 ל-25,000 תוך שעתיים.
2	10% הגדלת הנפח	הגדלה הדרגתית מ-25,000 ל-50,000 בקשות לשעה במשך שעתיים
3	הגדלת הנפח ב-25%	עלייה מ-50,000 ל-125,000 בקשות לשעה במשך 3 שעות
4	הגדלת הנפח ב-50%	עלייה מ-125,000 ל-250,000 בקשות לשעה במשך 6 שעות
5	הגדלת נפח החשיפה ב-75%	עלייה מ-250,000 ל-375,000 בקשות לשעה במשך 6 שעות
6	הגדלת הנפח ב-100%	הגדלה הדרגתית מ-375,000 ל-500,000 בקשות לשעה במשך 6 שעות

תוכנית היפותטית לשחזור:

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

מתי צריך לפנות אל FCM

פנו אל FCM דרך התמיכה של Firebase אם אחד מהמצבים הבאים רלוונטי אליכם:

• מכסות ברירת המחדל כבר לא מתאימות לתרחיש השימוש שלכם
• אתם משנים את דפוסי השליחה בחלון זמן של 3 חודשים בקנה מידה של 100,000 בקשות לשנייה (RPS) ברמת העולם או 30,000 בקשות לשנייה ברמת היבשת.