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

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

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

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

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

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

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

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

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

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

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

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

‫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 שניות. כדאי להגדיר חלונות ארוכים יותר כדי להגדיל את ההכנסה לכל 1,000 שאילתות.

הימנעות מעומסי תנועה בשעות עגולות

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

אם בקשה נשלחת שוב ושוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff) ועדיין נכשלת אחרי 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 בקשות לשנייה במשך שעתיים
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 בקשות לשנייה ברחבי העולם או 30,000 בקשות לשנייה ביבשת.