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