बड़े पैमाने पर FCM मैसेज भेजने के सबसे सही तरीके

अगर आपको नया ऐप्लिकेशन लॉन्च करना है या आपकी सेवा पर पहले से ही बहुत ज़्यादा ट्रैफ़िक है, तो इस गाइड में दी गई अहम जानकारी और सुझावों से आपको फ़ायदा मिल सकता है. इसमें बताया गया है कि FCM का इस्तेमाल करके, अपने कारोबार को आसानी से कैसे बढ़ाया जा सकता है. इन कॉन्सेप्ट और तरीकों से, आपको एक साथ कई मैसेज भेजने पर होने वाले बुरे असर से बचने में मदद मिल सकती है.

मुख्य शब्द और कॉन्सेप्ट

मैसेज का अनुरोध: यह FCM मैसेज का अनुरोध होता है. इसका इस्तेमाल "अनुरोध", "मैसेज" या "क्वेरी" के तौर पर किया जाता है.

अनुरोध प्रति सेकंड (आरपीएस): यह एक मेट्रिक है. इससे FCM को मिलने वाले अनुरोधों की दर के बारे में पता चलता है. इसका इस्तेमाल, क्वेरी प्रति सेकंड (क्यूपीएस) के साथ किया जाता है.

कोटा टोकन, टोकन बकेट, और रीफ़िल: FCM HTTP v1 API के ज़रिए मैसेज भेजते समय, हर अनुरोध के लिए तय किए गए कोटा टोकन का इस्तेमाल किया जाता है. ऐसा एक तय समयसीमा के अंदर होता है. इस विंडो को "टोकन बकेट" कहा जाता है. यह समयसीमा खत्म होने पर, पूरी तरह से रीफ़िल हो जाती है. उदाहरण के लिए: HTTP v1 API, हर एक मिनट के टोकन बकेट के लिए 6,00,000 कोटा टोकन देता है. ये टोकन, हर एक मिनट के विंडो के आखिर में पूरी तरह से रीफ़िल हो जाते हैं.

सर्वर-साइड थ्रॉटलिंग: जब ट्रैफ़िक का वॉल्यूम, FCM सेवा की क्षमता से ज़्यादा हो जाता है, तो सेवा देने की क्षमता से ज़्यादा के अनुरोधों को अस्वीकार कर दिया जाता है, ताकि इनग्रेस फ़्लो की दर को सीमित किया जा सके. retry-after हेडर के साथ 429 गड़बड़ी वाले जवाब दिखाए जा सकते हैं. इससे यह पता चलता है कि आपको अनुरोध फिर से करने से पहले, तय समयावधि तक इंतज़ार करना चाहिए.

क्लाइंट-साइड थ्रॉटलिंग: जब क्लाइंट को अनुरोध पूरे न होने, ज़्यादा इंतज़ार के समय या 429 गड़बड़ियों का पता चलता है, तो उन्हें अपने-आप डेटा ट्रांसफ़र करने की दर को सीमित करना चाहिए, ताकि नेटवर्क पर ज़्यादा लोड न पड़े.

एक्सपोनेंशियल बैकऑफ़: गड़बड़ियों को ठीक करने के लिए फिर से कोशिश करते समय, समय के अंतर को तेज़ी से बढ़ाएं. उदाहरण के लिए: 1s, 2s, 4s, 8s, 16s, 32s वगैरह.

जिटरिंग: अनुरोधों को तय समय पर फिर से भेजने से बचना. जिटरिंग की मदद से, फिर से कोशिश करने के बीच लगने वाले समय को रैंडम प्रोसेस के ज़रिए बदला जाता है, ताकि उन्हें समय के साथ एक जैसा डिस्ट्रिब्यूट किया जा सके. उदाहरण के लिए: 0.9 सेकंड, 2.3 सेकंड, 4.1 सेकंड, 8.5 सेकंड, 17.9 सेकंड, 34.7 सेकंड.

अनुरोध को बार-बार भेजना: जब अनुरोध पूरे नहीं होते हैं, तो उन्हें बार-बार भेजा जाता है. हालांकि, ऐसा एक्सपोनेंशियल बैकऑफ़/जिटरिंग के बिना किया जाता है. इससे अनुरोधों की संख्या बढ़ जाती है और ट्रैफ़िक का लोड बढ़ जाता है. इससे ट्रैफ़िक की भीड़ की समस्याएं "बढ़" सकती हैं और गंभीर हो सकती हैं.

समस्या: ट्रैफ़िक में अचानक बढ़ोतरी

FCM, हर सेकंड लाखों अनुरोधों (आरपीएस) को प्रोसेस करता है. सिस्टम में रुकावट, डेटा ट्रांसफ़र में देरी, और सेवा बंद होने की सबसे बड़ी वजह ट्रैफ़िक में अचानक बढ़ोतरी है.

स्पाइकी ट्रैफ़िक क्या होता है?

ट्रैफ़िक में अचानक बढ़ोतरी कई तरह की होती है.

हर घंटे की शुरुआत में ट्रैफ़िक में अचानक बढ़ोतरी: FCM को हर घंटे की शुरुआत के 30 सेकंड से लेकर दो मिनट तक, सामान्य से दोगुना ट्रैफ़िक मिलता है. इसी तरह, आधे घंटे और 15 मिनट के अंतराल पर भी, हालांकि कम, स्पाइक देखे जाते हैं. उदाहरण के लिए: 00:15, 00:30, 00:45

अनुरोध को बार-बार भेजना: अनुरोध पूरा न होने या समयसीमा खत्म होने पर, एक्सपोनेंशियल बैकऑफ़ के बिना अनुरोध को बार-बार भेजने से, मौजूदा ट्रैफ़िक के साथ-साथ ट्रैफ़िक की बार-बार बढ़ती हुई लहरें आ सकती हैं.

ट्रैफ़िक पैटर्न में अचानक बदलाव होना: नए ट्रैफ़िक को सीधे तौर पर FCM पर भेजना या धीरे-धीरे ट्रैफ़िक को बढ़ाए बिना, सभी क्षेत्रों में FCM पर ट्रैफ़िक को माइग्रेट करने से स्पाइक आ सकती हैं.

कोटा टोकन का इस्तेमाल शुरुआत में ही कर लेना: कोटा विंडो की शुरुआत में ही सभी कोटा टोकन का इस्तेमाल कर लेने से, अनुरोधों को कोटा विंडो में एक जैसा नहीं रखा जा सकेगा. इससे, अनुरोधों की संख्या में उतार-चढ़ाव होगा. साथ ही, लोड बैलेंस करना मुश्किल और महंगा हो जाएगा.

खास इवेंट: छुट्टियों (नए साल की पूर्व संध्या) या खेल-कूद से जुड़े इवेंट (FIFA विश्व कप) के दौरान ट्रैफ़िक में अचानक बढ़ोतरी होती है.

"फ़्लैटनिंग द कर्व" की मदद से, ट्रैफ़िक में अचानक होने वाली बढ़ोतरी को कम करना

इस सेक्शन में, ट्रैफ़िक में अचानक होने वाली बढ़ोतरी को कम करने की रणनीतियों के बारे में बताया गया है. इन रणनीतियों को "फ़्लैट द कर्व" भी कहा जाता है.

FCM का इस्तेमाल सिर्फ़ सही मामलों में करें

कुछ ऐसे मामले होते हैं जिनमें सूचना देने के लिए, FCM का इस्तेमाल करना ज़रूरी या सही नहीं होता.

उदाहरण के लिए, कैलेंडर इवेंट की सूचनाओं के लिए, अपने ऐप्लिकेशन में कोई लोकल टास्क शेड्यूल किया जा सकता है. इससे सूचनाएं, ऐप्लिकेशन सर्वर से भेजने के बजाय सही समय पर दिखेंगी. FCM मैसेज को कैलेंडर सिंक करने तक सीमित करें.

स्पाइक से बचना

स्केलिंग से जुड़ी एक एंटी-पैटर्न यह है कि सर्वर-साइड थ्रॉटलिंग लागू करने के बजाय, सिस्टम जितनी जल्दी हो सके उतनी जल्दी FCM सूचनाएँ भेजी जाएँ. इन बातों का ध्यान रखें:

• क्या आपके सभी खरीदारों को एक ही सूचना, एक मिनट के अंदर मिलनी चाहिए? क्या डिलीवरी के लिए पांच मिनट का समय, आपके कारोबार की ज़रूरतों को पूरा कर पाएगा?
• क्या आपके ग्राहकों को प्राथमिकता के आधार पर सेगमेंट में बांटा जा सकता है, ताकि मांग में अचानक होने वाली बढ़ोतरी को मैनेज किया जा सके?
• क्या सूचनाओं को पहले से शेड्यूल किया जा सकता है?

जहां तक हो सके: ऐसी रणनीतियों से बचें जिनकी वजह से, FCM के मैसेज भेजने का कोटा तुरंत खत्म हो जाता है. ऐसा इसलिए, ताकि टोकन बकेट के फिर से भरने के बाद, पैटर्न को दोहराया न जा सके. इस तरह के ऐक्सेस पैटर्न से, FCM और उस पर निर्भर सिस्टम के लिए लोड बैलेंसिंग से जुड़ी समस्याएं पैदा होती हैं. ट्रैफ़िक को धीरे-धीरे बढ़ाएं. कम से कम 60 सेकंड की समयावधि में, 0 से लेकर ज़्यादा से ज़्यादा आरपीएस तक रैंप करें. ज़्यादा आरपीएस के लिए, लंबी विंडो को प्राथमिकता दें.

हर घंटे के हिसाब से ट्रैफ़िक की जानकारी देने वाली सुविधा से बचना

जहां तक हो सके: :00, :15, :30, और :45 मिनट के मार्क के दो मिनट के अंदर मैसेज न भेजें.

सर्वर-साइड थ्रॉटलिंग लागू करना

FCM पर ट्रैफ़िक के फ़्लो को मॉनिटर और मैनेज करने के लिए, सर्वर-साइड थ्रॉटलिंग लागू करें.

फिर से कोशिश करने की सुविधा को मैनेज करना

FCM हमेशा उपलब्ध रहने की कोशिश करता है. हालांकि, कभी-कभी कुछ अनुरोधों का समय खत्म हो जाता है या वे पूरे नहीं हो पाते. इसकी कई वजहें हो सकती हैं. हालांकि, यहां दिए गए सबसे सही तरीकों से, फिर से कोशिश करने की सुविधा को ऑप्टिमाइज़ किया जा सकता है. इससे मैसेज जल्द से जल्द डिलीवर किए जा सकते हैं. साथ ही, ट्रैफ़िक की भीड़ पर पड़ने वाले असर को कम किया जा सकता है.

टाइम आउट

फिर से कोशिश करने से पहले, भेजने के अनुरोधों पर कम से कम 10 सेकंड का टाइमआउट सेट करें. FCM के ज़्यादातर इंटरनल रिमोट प्रोसीजर कॉल, 10 सेकंड के टाइमआउट का इस्तेमाल करते हैं.

गड़बड़ियां

• 400, 401, 403, 404 गड़बड़ियों के लिए: अनुरोध को रद्द करें और फिर से कोशिश न करें.
• 429 गड़बड़ियों के लिए: retry-after हेडर में सेट की गई अवधि के बाद फिर से कोशिश करें. अगर retry-after हेडर सेट नहीं किया गया है, तो डिफ़ॉल्ट रूप से 60 सेकंड पर सेट हो जाएगा.
• 500 गड़बड़ियों के लिए: एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करें.

एक्स्पोनेंशियल बैकऑफ़

अनुरोधों को फिर से भेजने की संख्या को कम करने के लिए, एक्स्पोनेंशियल बैक-ऑफ़ को लागू करें. साथ ही, अनुरोधों को फिर से भेजने के लिए, जिटरिंग का इस्तेमाल करें. उदाहरण के लिए, Firebase Admin SDK, एक्सपोनेंशियल बैकऑफ़ लागू करता है.

यहां कुछ और सेटिंग के सुझाव दिए गए हैं:

• कम से कम इंटरवल: अगर FCM के ज़रिए भेजा गया अनुरोध पूरा नहीं होता है, तो तुरंत फिर से अनुरोध न भेजें. अनुरोध पूरा न होने पर, फिर से कोशिश करने से पहले कम से कम 10 सेकंड इंतज़ार करें.
• ज़्यादा से ज़्यादा इंटरवल: ऐसे अनुरोधों को छोड़ने के लिए ज़्यादा से ज़्यादा इंटरवल सेट करें जो अब समय पर नहीं किए गए हैं. ऐसा अनिश्चित काल तक फिर से कोशिश करने के बजाय किया जाता है.

अगर किसी अनुरोध को एक्स्पोनेंशियल बैकऑफ़ के साथ लगातार फिर से भेजा जा रहा है और 60 मिनट बाद भी वह पूरा नहीं हो रहा है, तो हो सकता है कि उसे फिर से भेजे जा सकने वाली गड़बड़ी के तौर पर गलत तरीके से कैटगरी में रखा गया हो. इसके अलावा, यह भी हो सकता है कि FCM में कोई समस्या आ रही हो. ऐसे में, अनुरोध को फिर से भेजने से समस्या और बढ़ सकती है.

लॉन्च और रोलबैक करने के प्लान बनाना और धीरे-धीरे बदलाव करना

बड़े पैमाने पर ट्रैफ़िक में बदलाव करते समय, जैसे कि FCM पर ट्रैफ़िक बढ़ाना या अलग-अलग क्षेत्रों या नेटवर्क पर ट्रैफ़िक को ट्रांसफ़र करना, रोलआउट/रोलबैक प्लान बनाना और धीरे-धीरे बदलाव लागू करना, आपके उपयोगकर्ताओं, आपकी सेवा, और FCM को सुरक्षित रखेगा.

• लॉन्च करने का प्लान, स्टेकहोल्डर की उम्मीदों के मुताबिक होता है. कुछ मामलों में (इनके बारे में नीचे बताया गया है), आपको रोलआउट प्लान को FCM टीम के साथ पहले से शेयर करना पड़ सकता है, ताकि आपको कोई परेशानी न हो.
• रोलबैक प्लान की मदद से, अचानक होने वाली समस्याओं का पता लगाया जा सकता है. साथ ही, अनचाहे बदलावों को तुरंत और सुरक्षित तरीके से वापस लाने के लिए, सिस्टम तैयार किए जा सकते हैं.
• धीरे-धीरे बदलाव करने के दो पहलू हैं:
  • "चरण-दर-चरण" रैंप-अप: चरण 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% या इससे ज़्यादा होने चाहिए. हर चरण के लिए, एक दिन से लेकर एक हफ़्ते तक "सोक" करें. इसका मतलब है कि सिस्टम पर लोड के दौरान उसके व्यवहार पर नज़र रखें. इससे आपको "स्टेप-अप" से पहले ही संभावित समस्याओं का पता लगाने में मदद मिलती है
  • ट्रैफ़िक को धीरे-धीरे बढ़ाना: ट्रैफ़िक को बढ़ाने के लिए हर "चरण" में, कम से कम एक घंटे के दौरान ट्रैफ़िक को धीरे-धीरे बढ़ाएं. इससे, लोड-बैलेंसिंग की सुविधा देने वाले FCM के इन्फ़्रास्ट्रक्चर को, आपके नए ट्रैफ़िक को सही तरीके से स्केल करने में मदद मिलती है. साथ ही, इससे हॉटस्पॉट और कंजेशन की संभावना कम हो जाती है.

यहां दुनिया भर में, FCM Legacy HTTP API से FCM HTTP v1 API पर 5,00,000 आरपीएस माइग्रेट करने का एक काल्पनिक उदाहरण दिया गया है:

हफ़्ता	चरण	धीरे-धीरे रैंप-अप करने की रणनीति
0	1% रैंप-अप	एक घंटे में, FCM HTTP v1 के लिए 0 से 5,000 आरपीएस तक धीरे-धीरे बढ़ाएं.
1	5% रैंप-अप	दो घंटे में, 5,000 से 25,000 आरपीएस तक धीरे-धीरे बढ़ाएं.
2	10% रैंप-अप	दो घंटे में, 25,000 से 50,000 आरपीएस तक धीरे-धीरे बढ़ाएं
3	25% रैंप-अप	तीन घंटे में, 50,000 से 1,25,000 आरपीएस तक बढ़ाना
4	50% रैंप-अप	छह घंटे में, 1,25,000 से 2,50,000 आरपीएस तक बढ़ाएं
5	75% रैंप-अप	छह घंटे में, 2,50,000 से 3,75,000 आरपीएस तक बढ़ाना
6	100% रैंप-अप	छह घंटे में, 3,75,000 से 5,00,000 आरपीएस तक बढ़ाना

रोलबैक करने का काल्पनिक प्लान:

• अगर किसी भी चरण में, 95वें पर्सेंटाइल की लेटेन्सी 500 मि॰से॰ से ज़्यादा हो जाती है या गड़बड़ी का अनुपात एक घंटे से ज़्यादा समय तक 1% से ज़्यादा रहता है, तो डाइनैमिक कॉन्फ़िगरेशन का इस्तेमाल करके, तुरंत पिछले चरण पर रोल बैक करें.
• जब तक लेटेन्सी और गड़बड़ी का अनुपात सामान्य स्तर पर न आ जाए, तब तक पिछले चरणों पर वापस जाएं.

FCM से कब संपर्क करना चाहिए

अगर इनमें से कोई भी समस्या होती है, तो Firebase की सहायता टीम के ज़रिए FCM से संपर्क करें:

• डिफ़ॉल्ट कोटा अब आपके इस्तेमाल के उदाहरण के मुताबिक नहीं है
• आपने तीन महीने की अवधि में, दुनिया भर में 1,00,000 आरपीएस या महाद्वीप के हिसाब से 30,000 आरपीएस के हिसाब से ईमेल भेजने के पैटर्न में बदलाव किया हो.