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

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

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

בקשת הודעה: בקשת הודעה ב-FCM. המונח משמש גם לתיאור "בקשה", "הודעה" או "שאילתה".

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

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

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

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

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

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

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

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

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

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

יש כמה סוגים שונים של עליות פתאומיות בתנועה.

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

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

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

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

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

איך לטפל בעליות חדות בתנועה באמצעות "השטחת העקומה"

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

צריך להשתמש ב-FCM רק בתרחישים המתאימים

יש כמה תרחישי שימוש שבהם אין צורך או שאין זה מתאים להשתמש ב-FCM כדי להעביר התראה.

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

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

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

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

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

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

במידת האפשר: מומלץ להימנע משליחת הודעות בטווח של 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) עם תנודות (jittering) לניסיון חוזר של בקשות. לדוגמה, ב-SDK של Firebase לאדמינים מיושמת השהיה מעריכית לפני ניסיון חוזר.

הנה עוד כמה הגדרות מומלצות:

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

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

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

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

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

לפניכם תרחיש היפותטי להעברת 500,000 בקשות לשנייה ברחבי העולם מ-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 בקשות לשנייה (RPS) במשך שעתיים
3	הגדלת נפח ב-25%	הגדלה מ-50,000 ל-125,000 בקשות לשנייה במשך 3 שעות
4	הגדלת נפח החשיפה ב-50%	הגדלת נפח התנועה מ-125,000 ל-250,000 בקשות לשנייה (RPS) במהלך 6 שעות
5	75% ramp-up	הגדלה הדרגתית מ-250,000 ל-375,000 בקשות לשנייה (RPS) במשך 6 שעות
6	הגדלת הנפח ל-100%	הגדלה מ-375,000 ל-500,000 בקשות לשנייה במשך 6 שעות

תוכנית היפותטית לחזרה לגרסה קודמת:

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

מתי לפנות ל-FCM

אתם יכולים לפנות ל-FCM דרך התמיכה של Firebase במקרים הבאים:

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