चाहे आप एक नवोदित ऐप विकसित कर रहे हों या पहले से ही एक उच्च-ट्रैफ़िक सेवा चला रहे हों, आप एफसीएम के साथ आसानी से स्केल करने के तरीके पर इस गाइड की अंतर्दृष्टि और सिफारिशों से लाभ उठा सकते हैं। जब आपको बड़ी मात्रा में संदेश भेजने की आवश्यकता होती है तो ये अवधारणाएं और प्रथाएं आपको नकारात्मक प्रभावों से बचने में मदद कर सकती हैं।
मुख्य नियम और अवधारणाएँ
संदेश अनुरोध : एक एफसीएम संदेश अनुरोध; "अनुरोध", "संदेश", या "क्वेरी" के साथ परस्पर उपयोग किया जाता है।
अनुरोध-प्रति-सेकंड (आरपीएस) : एफसीएम को आने वाले अनुरोधों की दर का वर्णन करने के लिए एक मीट्रिक; क्वेरीज़-प्रति-सेकंड (QPS) के साथ परस्पर उपयोग किया जाता है।
कोटा टोकन, टोकन बकेट और रिफिल : एफसीएम HTTP v1 एपीआई के खिलाफ संदेश भेजते समय, प्रत्येक अनुरोध एक निश्चित समय विंडो में आवंटित कोटा टोकन का उपभोग करता है। यह विंडो, जिसे " टोकन बकेट " कहा जाता है, समय विंडो के अंत में पूरी तरह भर जाती है । उदाहरण के लिए: HTTP v1 API प्रत्येक 1-मिनट टोकन बकेट के लिए 600K कोटा टोकन आवंटित करता है, जो प्रत्येक 1-मिनट विंडो के अंत में पूर्ण रूप से भर जाता है।
सर्वर-साइड थ्रॉटलिंग : जब ट्रैफ़िक की मात्रा एफसीएम सेवा की क्षमता से अधिक हो जाती है, तो सेवा क्षमता से परे अनुरोधों को दर-सीमा प्रवेश प्रवाह के लिए अस्वीकार कर दिया जाता है। retry-after हेडर के साथ 429 त्रुटि प्रतिक्रियाएं यह इंगित करने के लिए लौटाई जा सकती हैं कि आपको अनुरोध को पुनः प्रयास करने से पहले एक निश्चित समय अवधि का इंतजार करना चाहिए।
क्लाइंट-साइड थ्रॉटलिंग : जब क्लाइंट अनुरोध विफलताओं, उच्च विलंबता, या 429 त्रुटियों को देखते हैं, तो उन्हें भीड़भाड़ से बचने के लिए स्वेच्छा से निकास प्रवाह को दर-सीमा में सीमित करना चाहिए।
घातीय बैकऑफ़ : त्रुटियों का पुन: प्रयास करते समय, तेजी से बढ़ते समय विलंब को जोड़ें। उदाहरण के लिए: 1s, 2s, 4s, 8s, 16s, 32s.
घबराहट : सटीक अंतराल पर अनुरोधों को पुनः प्रयास करने से बचना। घबराहट के साथ, आप समय के साथ उन्हें समान रूप से वितरित करने के लिए एक यादृच्छिक प्रक्रिया के माध्यम से पुनः प्रयास में देरी को बदलते हैं (उदाहरण के लिए: 0.9s, 2.3s, 4.1s, 8.5s, 17.9s, 34.7s)।
पुनः प्रयास प्रवर्धन : जब विफल अनुरोधों को घातीय बैकऑफ़/घबराहट के बिना पुनः प्रयास किया जाता है, तो वे अक्सर जमा हो जाते हैं और चल रहे ट्रैफ़िक लोड में जुड़ जाते हैं, संभावित रूप से "बढ़ते" हैं और ट्रैफ़िक भीड़ की समस्याओं को बढ़ा देते हैं।
समस्या: ट्रैफ़िक में बढ़ोतरी
एफसीएम प्रति सेकंड लाखों अनुरोधों को संसाधित करता है (आरपीएस)। प्रणालीगत भीड़भाड़, विलंबता समस्याओं और आउटेज में सबसे बड़ा योगदानकर्ता ट्रैफ़िक स्पाइक है।
स्पाइकी ट्रैफिक क्या है?
ट्रैफ़िक स्पाइक्स कई अलग-अलग प्रकार के होते हैं।
ऑन-द-घंटे स्पाइक्स: एफसीएम को प्रत्येक घंटे के पहले 30 सेकंड से 2 मिनट के दौरान दोगुने से अधिक ट्रैफ़िक प्राप्त होता है। इसी तरह, हालांकि कम, स्पाइक्स आधे घंटे और चौथाई घंटे के निशान पर भी देखे जाते हैं (उदाहरण: 00:15, 00:30, 00:45)
पुन: प्रयास प्रवर्धन : एक्सपोनेंशियल बैकऑफ़ के बिना विफल या टाइम-आउट अनुरोधों को पुनः प्रयास करने से मौजूदा ट्रैफ़िक शिखर के शीर्ष पर ट्रैफ़िक की दोहराई जाने वाली तरंगें जमा हो सकती हैं।
ट्रैफ़िक पैटर्न में अचानक बदलाव: नए ट्रैफ़िक को एफसीएम की ओर निर्देशित करना या धीरे-धीरे रैंप-अप जैसे कारकों को सुचारू किए बिना सभी क्षेत्रों में ट्रैफ़िक को एफसीएम की ओर ले जाना स्पाइक का कारण बन सकता है।
फ्रंट-लोडिंग कोटा टोकन का उपयोग: कोटा विंडो में अनुरोधों को समान रूप से फैलाने के बजाय कोटा विंडो की शुरुआत में सभी कोटा टोकन को समाप्त करने से ऑन-ऑफ दोलन पैदा होंगे जो लोड-बैलेंस के लिए कठिन और महंगे हैं।
विशेष कार्यक्रम: छुट्टियों (नए साल की पूर्व संध्या) या खेल आयोजनों ( फीफा विश्व कप ) के दौरान यातायात में वृद्धि।
"वक्र को समतल करके" ट्रैफ़िक स्पाइक्स का समाधान करें
यह अनुभाग जहां संभव हो वहां ट्रैफ़िक स्पाइक्स को सुचारू करने की रणनीतियों का वर्णन करता है - "वक्र को समतल करने" की रणनीतियाँ।
एफसीएम का उपयोग केवल उचित उपयोग के मामलों के लिए करें
ऐसे कुछ उपयोग के मामले हैं जहां अधिसूचना देने के लिए एफसीएम का उपयोग करना आवश्यक या उचित नहीं है।
उदाहरण के लिए, कैलेंडर ईवेंट सूचनाओं के लिए, आप अपने ऐप सर्वर से अधिसूचना भेजने के बजाय उचित समय पर अधिसूचना प्रदर्शित करने के लिए अपने ऐप में एक स्थानीय कार्य शेड्यूल कर सकते हैं। FCM संदेशों को कैलेंडर सिंक तक सीमित करें।
स्पाइक्स से बचें
एक स्केलिंग एंटी-पैटर्न सर्वर-साइड थ्रॉटलिंग लागू करने के बजाय जितनी जल्दी हो सके एफसीएम सूचनाएं भेजना है, जितनी जल्दी सिस्टम अनुमति देगा। निम्न पर विचार करें:
- क्या आपके सभी ग्राहकों को 1 मिनट की विंडो के भीतर एक ही अधिसूचना प्राप्त करने की आवश्यकता है? उदाहरण के लिए, क्या 5 मिनट की डिलीवरी विंडो अभी भी आपकी व्यावसायिक ज़रूरतों को पूरा करेगी?
- क्या स्पाइक्स को सुचारू करने के लिए आपके ग्राहकों को प्राथमिकता के आधार पर विभाजित किया जा सकता है?
- क्या आपकी सूचनाएं समय से पहले निर्धारित की जा सकती हैं?
जहां भी संभव हो : उन रणनीतियों से बचें जिनके परिणामस्वरूप आपका एफसीएम प्रेषण कोटा तुरंत समाप्त हो जाता है, केवल आपके टोकन बकेट के फिर से भरते ही पैटर्न को दोहराने के लिए। यह एक्सेस पैटर्न एफसीएम और उस पर निर्भर सिस्टम के लिए लोड-संतुलन समस्याएं पैदा करता है। जितना संभव हो धीरे-धीरे यातायात बढ़ाएं। कम से कम, 60 सेकंड की टाइम-विंडो में 0 से अधिकतम आरपीएस तक रैंप। उच्च आरपीएस के लिए लंबी विंडो को प्राथमिकता दें।
"ऑन-द-घंटे" ट्रैफ़िक से बचें
जहां संभव हो : प्रत्येक :00, :15, :30, और :45 मिनट के निशान के 2 मिनट की विंडो के भीतर संदेश भेजने से बचें।
सर्वर-साइड थ्रॉटलिंग लागू करें
एफसीएम पर यातायात के प्रवाह की निगरानी और प्रबंधन के लिए सर्वर-साइड थ्रॉटलिंग लागू करें।
पुनर्प्रयासों को संभालना
जबकि एफसीएम अत्यधिक उपलब्ध होने का प्रयास करता है, कभी-कभी कुछ अनुरोध समय समाप्त हो जाते हैं या विफल हो जाते हैं। हालांकि कारण अलग-अलग हैं, निम्नलिखित सर्वोत्तम प्रथाएं ट्रैफ़िक भीड़ के प्रभाव को कम करते हुए संदेश को जल्द से जल्द वितरित करने के लिए पुनः प्रयास व्यवहार को अनुकूलित करती हैं।
समय समाप्ति
पुनः प्रयास करने से पहले अनुरोध भेजने पर कम से कम 10 सेकंड का समय निर्धारित करें। एफसीएम की अधिकांश आंतरिक रिमोट प्रक्रिया कॉल 10 सेकंड के टाइमआउट का उपयोग करती हैं।
त्रुटियाँ
- 400, 401, 403, 404 त्रुटियों के लिए: निरस्त करें, और पुनः प्रयास न करें।
- 429 त्रुटियों के लिए: पुनः प्रयास-आफ्टर हेडर में निर्धारित अवधि की प्रतीक्षा करने के बाद पुनः प्रयास करें। यदि कोई पुनः प्रयास-बाद हेडर सेट नहीं है, तो डिफ़ॉल्ट 60 सेकंड है।
- 500 त्रुटियों के लिए: घातीय बैकऑफ़ के साथ पुनः प्रयास करें।
घातीय बैकऑफ़
पुनः प्रयास प्रवर्धन से बचने के लिए, पुनः प्रयास अनुरोधों के लिए घबराहट के साथ घातीय बैक-ऑफ लागू करें। उदाहरण के लिए, फायरबेस एडमिन एसडीके, घातीय बैकऑफ़ लागू करता है।
यहां कुछ और अनुशंसित सेटिंग्स दी गई हैं:
- न्यूनतम अंतराल: एफसीएम के साथ विफल अनुरोध को तुरंत पुनः प्रयास न करें। विफल अनुरोध को पुनः प्रयास करने से पहले कम से कम 10 सेकंड प्रतीक्षा करें।
- अधिकतम अंतराल: अनिश्चित काल तक पुनः प्रयास करने के बजाय, उन अनुरोधों को छोड़ने के लिए अधिकतम अंतराल निर्धारित करें जो अब समय पर नहीं हैं।
यदि किसी अनुरोध को लगातार घातीय बैकऑफ़ के साथ पुनः प्रयास किया जाता है और 60 मिनट बाद भी विफल हो रहा है, तो इसे या तो पुनः प्रयास योग्य त्रुटि के रूप में गलत वर्गीकृत किया जाता है, या एफसीएम एक आउटेज का अनुभव कर रहा है जहां पुनः प्रयास अनजाने में स्थिति को बढ़ा सकता है।
रोलआउट और रोलबैक योजनाएँ बनाएँ और क्रमिक परिवर्तन करें
बड़े पैमाने पर ट्रैफ़िक परिवर्तन करते समय, जैसे कि FCM पर ट्रैफ़िक बढ़ाना या क्षेत्रों या नेटवर्कों में ट्रैफ़िक स्थानांतरित करना, रोलआउट/रोलबैक योजना डिज़ाइन करना और क्रमिक परिवर्तन लागू करना आपके उपयोगकर्ताओं, आपकी सेवा और FCM की सुरक्षा करेगा।
- एक रोलआउट योजना हितधारकों की अपेक्षाओं को संरेखित करती है। कुछ स्थितियों में (नीचे चर्चा की गई है), आप आश्चर्य से बचने के लिए अपनी रोलआउट योजना को समय से पहले एफसीएम टीम के साथ साझा करना चाह सकते हैं।
- एक रोलबैक योजना आपको आकस्मिकताओं को ध्यान में रखने और अप्रत्याशित विफलताओं से जल्दी और सुरक्षित रूप से उबरने के लिए तंत्र तैयार करने की अनुमति देती है।
- क्रमिक परिवर्तन करने के दो पहलू हैं:
- "चरण-वार" रैंप-अप: चरण 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% या इससे बेहतर होने चाहिए। 1 दिन से 1 सप्ताह तक प्रत्येक चरण को " सोक " (लोड के तहत सिस्टम व्यवहार का निरीक्षण करें)। यह आपको अगले "स्टेप-अप" से पहले संभावित समस्याओं का पता लगाने की अनुमति देता है
- धीरे-धीरे ट्रैफ़िक रैंप-अप: ट्रैफ़िक बढ़ाने के लिए प्रत्येक "कदम" उठाते समय, कम से कम एक घंटे की अवधि में ट्रैफ़िक को सुचारू करें। यह एफसीएम के लोड-बैलेंसिंग बुनियादी ढांचे को हॉटस्पॉट और भीड़भाड़ की संभावना को कम करते हुए आपके नए ट्रैफ़िक को उचित रूप से मापने की अनुमति देता है।
यहां वैश्विक स्तर पर 500,000 आरपीएस को एफसीएम लिगेसी HTTP एपीआई से एफसीएम HTTP v1 एपीआई में स्थानांतरित करने के लिए एक काल्पनिक परिदृश्य दिया गया है:
| सप्ताह | कदम | क्रमिक रैंप-अप रणनीति |
|---|---|---|
| 0 | 1% रैंप-अप | एक घंटे के दौरान 0 से 5,000 RPS से FCM HTTP v1 तक सुचारू रूप से रैंप-अप। |
| 1 | 5% रैंप-अप | 2 घंटे में 5,000 से 25,000 आरपीएस तक सुचारू रूप से रैंप-अप। |
| 2 | 10% रैंप-अप | 2 घंटे में 25,000 से 50,000 आरपीएस तक सुचारू रूप से रैंप-अप |
| 3 | 25% रैंप-अप | 3 घंटे में 50,000 से 125,000 आरपीएस तक रैंप-अप |
| 4 | 50% रैंप-अप | 6 घंटे में 125,000 से 250,000 आरपीएस तक रैंप-अप |
| 5 | 75% रैंप-अप | 6 घंटे में 250,000 से 375,000 आरपीएस तक रैंप-अप |
| 6 | 100% रैंप-अप | 6 घंटे में 375,000 से 500,000 आरपीएस तक की वृद्धि |
काल्पनिक रोलबैक योजना:
- यदि 95-प्रतिशत विलंबता 500 एमएस से अधिक हो जाती है या यदि किसी भी चरण पर एक घंटे से अधिक के लिए त्रुटि अनुपात 1% से अधिक हो जाता है, तो तुरंत पिछले चरण पर वापस जाने के लिए गतिशील कॉन्फ़िगरेशन का उपयोग करें।
- विलंबता और त्रुटि अनुपात नाममात्र के स्तर पर वापस आने तक पहले के चरणों में रोलबैक जारी रखें।
एफसीएम से कब संपर्क करना है
यदि निम्नलिखित में से कोई भी लागू हो तो फायरबेस सपोर्ट के माध्यम से एफसीएम से संपर्क करें:
- डिफ़ॉल्ट कोटा अब आपके उपयोग के मामले को पूरा नहीं करता है
- आप वैश्विक स्तर पर 100,000 आरपीएस या महाद्वीपीय रूप से 30,000 आरपीएस के पैमाने पर 3 महीने की अवधि के भीतर अपना भेजने का पैटर्न बदल रहे हैं।