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