बड़े पैमाने पर 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% रैंप-अप	एक घंटे के दौरान, 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 आरपीएस के स्केल पर, भेजने के पैटर्न में बदलाव कर रहे हैं.