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

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

अहम शब्द और कॉन्सेप्ट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इसका इस्तेमाल सिर्फ़ सही इस्तेमाल के उदाहरणों के लिए करना हैFCM

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

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

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

स्केलिंग का एक एंटी-पैटर्न यह है कि सर्वर-साइड थ्रॉटलिंग लागू करने के बजाय, 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 के लेगसी एचटीटीपी एपीआई से, FCM के एचटीटीपी v1 एपीआई पर दुनिया भर में 5,00,000 आरपीएस माइग्रेट करने का एक काल्पनिक उदाहरण दिया गया है:

हफ़्ता	स्टेप	रैंप-अप की धीरे-धीरे लागू की जाने वाली रणनीति
0	1% रैंप-अप	एक घंटे के दौरान, FCM के एचटीटीपी 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 आरपीएस के स्केल पर, मैसेज भेजने के पैटर्न में बदलाव कर रहे हैं.