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

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

ट्रैफ़िक स्पाइक कई तरह के होते हैं.

हर घंटे के शुरुआती 30 सेकंड से दो मिनट के दौरान, FCM को सामान्य से दोगुना ट्रैफ़िक मिलता है. इसी तरह के, हालांकि कम, स्पाइक हर घंटे के 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% रैंप-अप	एक घंटे के दौरान, 0 से 5,000 आरपीएस तक, FCM के एचटीटीपी v1 पर आसानी से रैंप-अप करें.
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 आरपीएस के स्केल पर, अपने भेजने के पैटर्न में बदलाव कर रहे हैं.