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

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

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

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

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

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

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

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

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