बड़े पैमाने पर 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, हर सेकंड लाखों अनुरोध (आरपीएस) प्रोसेस करता है. सिस्टम में भीड़भाड़, इंतज़ार के समय की समस्याएं, और आउटेज की सबसे बड़ी वजह ट्रैफ़िक में बढ़ोतरी है.

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

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

हर घंटे की शुरुआत में ट्रैफ़िक में बढ़ोतरी: एफ़सीएम को हर घंटे के पहले 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 सेकंड का टाइम आउट सेट करें. एफ़सीएम के ज़्यादातर इंटरनल रिमोट प्रोसीजर कॉल, 10 सेकंड के टाइम आउट का इस्तेमाल करते हैं.

गड़बड़ियां

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

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

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

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

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

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

रोलआउट और रोलबैक प्लान बनाएं और धीरे-धीरे बदलाव करें

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

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

यहां FCM के लेगसी एचटीटीपी एपीआई से FCM के एचटीटीपी v1 एपीआई पर, दुनिया भर में 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 की सहायता टीम के ज़रिए एफ़सीएम से संपर्क करें:

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