בין אם אתם מפתחים אפליקציה חדשה או מפעילים שירות עם נפח תנועה גבוה, תוכלו להיעזר בתובנות ובהמלצות שבמדריך הזה כדי להרחיב את השימוש ב-FCM בצורה חלקה. המושגים והשיטות האלה יכולים לעזור לכם להימנע מהשפעות שליליות כשאתם צריכים לשלוח נפחים גדולים של הודעות.
מושגים והגדרות חשובים
בקשת הודעה: בקשת הודעה ב-FCM. המונח משמש לסירוגין עם 'בקשה', 'הודעה' או 'שאילתה'.
בקשות לשנייה (RPS): מדד שמתאר את קצב הבקשות הנכנסות ל-FCM. משתמשים בו לסירוגין עם שאילתות לשנייה (QPS).
טוקנים של מכסת נפח, מאגרי טוקנים ומילויים: כששולחים הודעות באמצעות FCM HTTP v1 API, כל בקשה צורכת טוקן של מכסת נפח שהוקצה לה בפרק זמן מסוים. פרק הזמן הזה נקרא מאגר טוקנים, ובסוף פרק הזמן הוא מתמלא. לדוגמה: HTTP v1 API מקצה 600,000 טוקנים של מכסת נפח לכל מאגר טוקנים של דקה אחת, ובסוף כל חלון של דקה אחת המאגר מתמלא.
ויסות בצד השרת: כשנפח התנועה חורג מהקיבולת של שירות FCM, בקשות שחורגות מקיבולת השירות נדחות כדי להגביל את קצב הזרימה של התנועה הנכנסת. יכול להיות שיוחזרו תגובות שגיאה מסוג 429 עם כותרות מסוג retry-after כדי לציין שצריך להמתין פרק זמן מסוים לפני שמנסים לשלוח את הבקשה שוב.
ויסות נתונים בצד הלקוח: אם הלקוחות מזהים כשלים בבקשות, חביון גבוה או שגיאות 429, הם צריכים להגביל את קצב היציאה כדי למנוע החמרה של העומס.
השהיה מעריכית לפני ניסיון חוזר (exponential backoff): כשמנסים שוב לתקן שגיאות, מוסיפים השהיות שהולכות וגדלות באופן אקספוננציאלי. לדוגמה: 1s, 2s, 4s, 8s, 16s, 32s וכן הלאה.
שינוי קל של מרווחי הזמן: הימנעות מניסיון חוזר לשלוח בקשות במרווחי זמן מדויקים. בשיטת ה-jittering, משנים את ההשהיות בין הניסיונות באמצעות תהליך אקראי כדי לפזר אותן באופן אחיד לאורך זמן (לדוגמה: 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 שניות. מומלץ להשתמש בחלונות ארוכים יותר כדי להשיג ערך גבוה יותר של RPS.
הימנעות מפקקים בשעות עגולות
אם אפשר: מומלץ להימנע משליחת הודעות בטווח של 2 דקות לפני או אחרי כל אחת מהנקודות הבאות: 00:00, 00:15, 00:30 ו-00:45.
הטמעה של ויסות נתונים בצד השרת
כדאי להטמיע הגבלת קצב בצד השרת כדי לעקוב אחרי זרימת התנועה אל FCM ולנהל אותה.
טיפול בניסיונות חוזרים
מערכת FCM שואפת להיות זמינה מאוד, אבל לפעמים חלק מהבקשות יגיעו לזמן קצוב לתפוגה או ייכשלו. הסיבות לכך משתנות, אבל השיטות המומלצות הבאות מאפשרות לבצע אופטימיזציה של התנהגות הניסיון החוזר כדי להעביר הודעות בהקדם האפשרי, תוך מזעור ההשפעה על עומסי התנועה.
חסימות זמניות
מומלץ להגדיר לפחות 10 שניות של זמן קצוב לתפוגה בבקשות השליחה לפני שמנסים שוב. רוב הקריאות הפנימיות של FCM לשירות מרוחק (RPC) משתמשות בזמן קצוב לתפוגה של 10 שניות.
שגיאות
- בשגיאות 400, 401, 403 ו-404: מבטלים את הפעולה ולא מנסים שוב.
- לגבי שגיאות 429: צריך לנסות שוב אחרי שממתינים למשך הזמן שמוגדר בכותרת retry-after. אם לא מוגדר כותר retry-after, ברירת המחדל היא 60 שניות.
- שגיאות 500: צריך לנסות שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).
השהיה מעריכית לפני ניסיון חוזר (exponential backoff)
כדי להימנע מהגברה של ניסיונות חוזרים, צריך להטמיע השהיה מעריכית לפני ניסיון חוזר עם רעידות כדי לנסות שוב בקשות. לדוגמה, ב-SDK של Firebase לאדמינים מוטמעת השהיה מעריכית לפני ניסיון חוזר.
הנה עוד כמה הגדרות מומלצות:
- מרווח מינימלי: אל תנסו לשלוח שוב בקשה שנכשלה ב-FCM באופן מיידי. צריך להמתין לפחות 10 שניות לפני שמנסים לשלוח שוב בקשה שנכשלה.
- מרווח מקסימלי: הגדרת מרווח מקסימלי להפסקת בקשות שכבר לא רלוונטיות, במקום לנסות שוב ללא הגבלה.
אם בקשה נשלחת שוב ושוב עם השהיה מעריכית לפני ניסיון חוזר, והיא עדיין נכשלת 60 דקות לאחר מכן, יכול להיות שהיא סווגה באופן שגוי כשגיאה שאפשר לנסות לשלוח שוב, או ש-FCM חווה הפסקה בשירות שבה ניסיונות חוזרים עלולים להחמיר את המצב שלא במכוון.
יצירת תוכניות להשקה ולביטול השינויים, וביצוע שינויים הדרגתיים
כשמבצעים שינויים בתנועת הגולשים בקנה מידה גדול, כמו הגדלת תנועת הגולשים ל-FCM או העברת תנועת הגולשים בין אזורים או רשתות, תכנון של תוכנית השקה או חזרה לגרסה קודמת ויישום שינויים הדרגתיים יגנו על המשתמשים, על השירות ועל FCM.
- תוכנית השקה עוזרת לתאם את הציפיות של בעלי העניין. במצבים מסוימים (שמפורטים בהמשך), מומלץ לשתף את תוכנית ההשקה מראש עם צוות FCM כדי למנוע הפתעות.
- תוכנית חזרה למצב הקודם מאפשרת לכם להתכונן למקרי חירום וליצור מנגנונים לשחזור מהיר ובטוח של נתונים במקרה של כשלים בלתי צפויים.
- לשינויים הדרגתיים יש שני היבטים:
- השקות הדרגתיות: השלבים צריכים להיות 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% או יותר. Soak (התבוננות בהתנהגות המערכת בעומס) כל שלב למשך יום אחד עד שבוע. כך תוכלו לזהות בעיות פוטנציאליות לפני השלב הבא
- הגדלה הדרגתית של נפח התנועה: כשמבצעים כל 'שלב' בהגדלת נפח התנועה, צריך להחליק את התנועה על פני שעה לפחות. כך, תשתית איזון העומסים של 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 בקשות לשנייה (RPS) במשך 3 שעות |
| 4 | הגדלת נפח החשיפה ב-50% | הגדלת נפח התנועה מ-125,000 ל-250,000 בקשות לשנייה (RPS) במהלך 6 שעות |
| 5 | הגדלת נפח החשיפה ב-75% | הגדלה הדרגתית מ-250,000 ל-375,000 בקשות לשנייה (RPS) במשך 6 שעות |
| 6 | עלייה הדרגתית של 100% | הגדלת קצב הבקשות מ-375,000 ל-500,000 בקשות לשנייה במהלך 6 שעות |
תוכנית היפותטית לביטול השינויים:
- אם זמן האחזור של אחוזון 95 עולה על 500 אלפיות השנייה או אם יחס השגיאות עולה על 1% למשך יותר משעה בכל שלב, צריך להשתמש בהגדרה דינמית כדי לחזור לשלב הקודם באופן מיידי.
- ממשיכים להחזיר את השינויים לשלבים קודמים עד שזמן האחזור ויחס השגיאות חוזרים לרמות הרגילות.
באילו מקרים צריך לפנות לתמיכה של FCM
אם אחד מהמקרים הבאים מתרחש, אפשר לפנות ל-FCM דרך התמיכה של Firebase:
- המכסות שמוגדרות כברירת מחדל כבר לא מתאימות לתרחיש השימוש שלכם
- אתם משנים את דפוסי השליחה שלכם במסגרת חלון של 3 חודשים בקנה מידה של 100,000 בקשות לשנייה ברחבי העולם או 30,000 בקשות לשנייה ביבשת.