API प्रबंधन में Rate Limiting
September 16, 2022
इंटरनेट के विकास के साथ, अधिक से अधिक कंपनियां क्लाउड-नेटिव और माइक्रोसर्विसेज को अपना रही हैं। हालांकि, क्लाउड-नेटिव और माइक्रोसर्विसेज की तकनीकी विशेषताओं के कारण, हमें सैकड़ों अलग-अलग सेवाओं को एक साथ प्रबंधित करना पड़ता है। इसलिए, न केवल हमें पूरे सिस्टम के सुचारू संचालन पर विचार करना होता है, बल्कि हर API-आधारित सेवा की सुरक्षा और स्थिरता का भी ध्यान रखना होता है।
रेट लिमिटिंग API-आधारित सेवाओं की स्थिरता सुनिश्चित करने के लिए सबसे महत्वपूर्ण समाधानों में से एक है। हालांकि, यदि प्रत्येक सेवा को रेट लिमिटेशन की आवश्यकता होती है, तो एप्लिकेशन अत्यधिक भारी हो जाएगा। डिजिटल दुनिया में सभी ट्रैफिक के प्रवेश और निकास के रूप में, API गेटवे सभी सेवाओं के एकीकृत API प्रबंधन को प्राप्त करने में मदद करता है। यह सिस्टम सेवा के स्थिर संचालन की सुरक्षा करता है। यह लेख दिखाता है कि हम Apache APISIX API गेटवे के माध्यम से रेट लिमिटिंग कैसे प्राप्त करते हैं और रेट लिमिटिंग रणनीतियों और तकनीकों का वर्णन करता है।
रेट लिमिटिंग क्या है
रेट लिमिटिंग इंटरनेट ट्रैफिक को नियंत्रित करने और थ्रूपुट को अधिकतम करने की एक रणनीति है। रेट लिमिटिंग का उपयोग करने से केवल विशिष्ट सीमा के अंतर्गत अनुरोधों को सिस्टम तक पहुंचने की अनुमति मिलती है; सिस्टम सीमा से अधिक होने वाले किसी भी अतिरिक्त अनुरोध को कतारबद्ध कर देगा, उनकी प्राथमिकता को कम करेगा या उन्हें अस्वीकार या छोड़ देगा। रेट लिमिटिंग सिस्टम को ट्रैफिक स्पाइक्स या दुर्भावनापूर्ण हमलों जैसी अप्रत्याशित घटनाओं से भी बचाता है और सिस्टम को सुसंगत, स्थिर सेवाएं प्रदान करने में सक्षम बनाता है।
उदाहरण के लिए, जब एक ट्रेंडिंग ट्वीट ट्रैफिक स्पाइक पैदा करता है, तो ट्विटर को सर्वर क्रैश से बचने के लिए रेट लिमिटेशन लगाना पड़ता है।
आपको इसकी आवश्यकता क्यों है
पहले, आइए हमारे वास्तविक जीवन में कुछ सरल उपयोग के मामलों को देखें जो रेट लिमिटिंग का उपयोग करते हैं। उदाहरण के लिए, पर्यटक आकर्षण केवल छुट्टियों के लिए एक निश्चित संख्या में टिकट ही बेच सकते हैं। इसके अलावा, हमें आमतौर पर लोकप्रिय रेस्तरां में भोजन का आनंद लेने से पहले बुकिंग करनी पड़ती है या लंबे समय तक प्रतीक्षा करनी पड़ती है।
API गेटवे में, रेट लिमिटिंग के कई लाभ भी हैं। रेट लिमिटिंग हमारी API-आधारित सेवाओं पर कुछ सीमाएं लगाएगी, इसके सुचारू संचालन को सुरक्षित करेगी और ट्रैफिक स्पाइक्स के कारण सर्वर क्रैश से होने वाले अनावश्यक नुकसान से बचाएगी। यहां हमने पांच अलग-अलग व्यावहारिक सीमाओं को सूचीबद्ध किया है:
- अनुरोध दर को सीमित करें।
- प्रति समय इकाई में अनुरोधों की संख्या को सीमित करें।
- अनुरोधों को विलंबित करें।
- क्लाइंट अनुरोधों को अस्वीकार करें।
- प्रतिक्रिया दर को सीमित करें।
आपको इसकी आवश्यकता कब होगी
पहचान और प्रमाणीकरण के साथ, रेट लिमिटिंग निम्नलिखित तरीकों से अपने लाभों को अधिकतम कर सकती है और सिस्टम की उपलब्धता में सुधार कर सकती है:
- दुर्भावनापूर्ण हमलों से बचें।
- सिस्टम के स्थिर संचालन को सुरक्षित करें और ट्रैफिक स्पाइक्स के कारण सर्वर क्रैश से बचें।
- अपस्ट्रीम या डाउनस्ट्रीम सेवाओं द्वारा उत्पन्न बग के कारण अनुरोध स्पाइक्स से सर्वर क्रैश को रोकें।
- बहुत अधिक बार महंगे API कॉल से बचें।
- API कॉल की आवृत्ति को सीमित करके संसाधनों की अनावश्यक बर्बादी को कम करें।
रेट लिमिटिंग के पीछे का सिद्धांत
पिछले अनुभागों में, हमने रेट लिमिटिंग के लाभों का परिचय दिया है। इस अनुभाग में, आइए इसके पीछे के सिद्धांतों को जानें! रेट लिमिटिंग का निम्न-स्तरीय कार्यान्वयन विशिष्ट एल्गोरिदम द्वारा प्राप्त किया जाता है। सामान्यतः उपयोग किए जाने वाले एल्गोरिदम में शामिल हैं:
- काउंटर एल्गोरिदम
- फिक्स्ड विंडो
- स्लाइडिंग विंडो
- लीकी बकेट एल्गोरिदम
- टोकन बकेट एल्गोरिदम
काउंटर एल्गोरिदम
काउंटर एल्गोरिदम को समझना अपेक्षाकृत आसान है, और इसके दो प्रकार हैं:
पहला प्रकार है फिक्स्ड विंडो एल्गोरिदम, जो एक निश्चित समय इकाई में एक काउंटर को बनाए रखता है और यदि यह पता चलता है कि समय इकाई बीत चुकी है तो काउंटर को शून्य पर रीसेट कर देगा।
दूसरा प्रकार है स्लाइडिंग विंडो एल्गोरिदम, जो पहले वाले पर आधारित एक सुधार है; इसमें निम्नलिखित चरण होते हैं:
- समय इकाइयों को कई अंतरालों में विभाजित करें (प्रत्येक को एक ब्लॉक कहा जाता है)।
- प्रत्येक ब्लॉक में एक काउंटर होता है; किसी भी आने वाले अनुरोध से काउंटर 1 से बढ़ जाएगा।
- एक निश्चित समय के बाद, यह समय विंडो एक ब्लॉक आगे बढ़ जाती है।
- यह उस समय विंडो में सभी ब्लॉक्स के काउंटरों को जोड़कर उस समय विंडो में कुल अनुरोधों की गणना करेगा; यदि कुल अनुरोध सीमा से अधिक हो जाते हैं, तो यह उस समय विंडो में सभी अनुरोधों को छोड़ देगा।
लीकी बकेट एल्गोरिदम
मान लीजिए कि एक लीकी बकेट है; सभी अनुरोध पहले कतारबद्ध होंगे, और फिर लीकी बकेट उन्हें एक स्थिर दर पर भेजेगा।

यदि अनुरोध बकेट की क्षमता से अधिक हो जाते हैं, तो सिस्टम किसी भी अतिरिक्त अनुरोध को छोड़ देगा और अस्वीकार कर देगा। लीकी बकेट एल्गोरिदम अनुरोध दर को सीमित कर सकता है और सुनिश्चित कर सकता है कि सभी अनुरोध एक स्थिर दर पर भेजे जाएं, जो एक आसान-प्रवेश लेकिन कठिन-निकास मोड बनाता है।
इस एल्गोरिदम में मुख्य चरण:
- सभी अनुरोध एक निश्चित आकार के बकेट में संग्रहीत होते हैं।
- बकेट बकेट खाली होने तक एक स्थिर दर पर अनुरोध भेजेगा।
- जब बकेट भर जाता है, तो सिस्टम किसी भी अतिरिक्त अनुरोध को छोड़ देगा।
टोकन बकेट एल्गोरिदम
टोकन बकेट एल्गोरिदम में दो भाग होते हैं: टोकन उत्पन्न करना और छोड़ना। टोकन बकेट एक स्थिर दर पर टोकन उत्पन्न करता है और उन्हें एक निश्चित संग्रहण बकेट में संग्रहीत करता है। जब एक अनुरोध टोकन बकेट से गुजरता है, तो अनुरोध एक या अधिक टोकन लेता है। जब टोकन बकेट में टोकन की संख्या अधिकतम क्षमता तक पहुंच जाती है, तो टोकन बकेट नए उत्पन्न टोकन को छोड़ देगा। इसके अलावा, यदि कोई टोकन नहीं बचा है, तो संग्रहण बकेट आने वाले अनुरोधों को अस्वीकार कर देगा।

टोकन बकेट एल्गोरिदम के मुख्य चरण:
- टोकन बकेट एक स्थिर दर पर टोकन उत्पन्न करेगा और उन्हें संग्रहण बकेट में डालेगा।
- यदि टोकन बकेट भर जाता है, तो नए उत्पन्न टोकन सीधे छोड़ दिए जाएंगे। जब एक अनुरोध आता है, तो यह संग्रहण बकेट से एक या अधिक टोकन लेता है।
- यदि टोकन बकेट में कोई टोकन नहीं बचा है, तो सिस्टम किसी भी आने वाले अनुरोध को अस्वीकार कर देगा।
API गेटवे के माध्यम से रेट लिमिटिंग प्राप्त करें
यदि केवल कुछ API-आधारित सेवाओं को प्रबंधित करने की आवश्यकता है, तो हम सीधे सेवा में रेट-लिमिटिंग एल्गोरिदम का उपयोग कर सकते हैं। उदाहरण के लिए, यदि आप अपने सिस्टम को विकसित करने के लिए Go का उपयोग कर रहे हैं, तो यह tollbooth या golang.org/x/time/rate का उपयोग करेगा। यदि आप Lua का उपयोग कर रहे हैं, तो आप NGINX के limit_req, limit_conn, और Lua-resty-limit-traffic मॉड्यूल का उपयोग कर सकते हैं।
यदि रेट लिमिटिंग API-आधारित सेवा पर आधारित है, तो रेट लिमिटिंग की सीमाएं सेवा द्वारा ही निर्धारित की जाएंगी, और प्रत्येक सेवा की अलग-अलग सीमाएं हो सकती हैं। यदि API-आधारित सेवाओं की संख्या में काफी वृद्धि होती है, तो सीमाएं और अंतर प्रबंधन-स्तरीय समस्याएं पैदा करेंगी। तब, हम सभी API सेवाओं को एकीकृत रूप से प्रबंधित करने के लिए API गेटवे का उपयोग नहीं कर सकते हैं। आप API गेटवे का उपयोग करके रेट-लिमिटिंग समस्याओं को हल करते समय गेटवे पर असंबंधित व्यावसायिक सुविधाओं को भी लागू कर सकते हैं, जैसे पहचान, प्रमाणीकरण, लॉग, ऑब्जर्वेबिलिटी, आदि।
Apache APISIX एक गतिशील, रियल-टाइम, उच्च-प्रदर्शन क्लाउड-नेटिव गेटवे है। APISIX ने वर्तमान में 80 से अधिक अलग-अलग प्लगइन्स का समर्थन किया है, और इसने एक समृद्ध पारिस्थितिकी तंत्र बनाया है। हम APISIX के प्लगइन्स, जैसे limit-req, limit-conn, और limit-count का उपयोग करके API-आधारित सेवाओं के ट्रैफिक को प्रबंधित कर सकते हैं। यहां, मैं APISIX रेट-लिमिट प्लगइन्स के उपयोग को प्रदर्शित करने के लिए एक उपयोग केस साझा करूंगा।
मान लीजिए कि एक API-आधारित सेवा (/user/login) है जो उपयोगकर्ताओं को लॉग इन करने में मदद करती है। दुर्भावनापूर्ण हमलों और संसाधन की कमी से बचने के लिए, हमें सिस्टम की स्थिरता सुनिश्चित करने के लिए रेट-लिमिटिंग फ़ंक्शन को सक्षम करने की आवश्यकता है।
अनुरोधों को सीमित करें
limit-req प्लगइन अनुरोध दर को सीमित करता है, जो लीकी बकेट एल्गोरिदम का उपयोग करता है, और हम इसे संबंधित रूट या विशिष्ट ग्राहकों के साथ बांधते हैं।
हम सीधे APISIX के Admin API का उपयोग करके ऐसा रूट बना सकते हैं:
X-API-Key APISIX कॉन्फ़िगरेशन में admin_key है।
curl http://127.0.0.1:9080/apisix/admin/routes/1 \ -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "methods": ["POST"], "uri": "/user/login", "plugins": { "limit-req": { "rate": 3, "burst": 2, "rejected_code": 503, "key": "remote_addr" } }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }'
इस कोड स्निपेट का अर्थ: हम क्लाइंट के IP पते को अनुरोध दर को सीमित करने के लिए आवश्यकता के रूप में उपयोग करते हैं।
- यदि अनुरोध दर 3 अनुरोध/सेकंड (
rate) से कम है, तो अनुरोध सामान्य है; - यदि अनुरोध दर 3 अनुरोध/सेकंड से अधिक और 5 अनुरोध/सेकंड (
rate+burst) से कम है, तो हम इन अतिरिक्त अनुरोधों को कम प्राथमिकता देंगे; - यदि अनुरोध दर 5 अनुरोध/सेकंड (
rate+burst) से अधिक है, तो अधिकतम सीमा से अधिक होने वाले किसी भी अनुरोध को HTTP कोड 503 वापस कर दिया जाएगा।
यदि आप limit-req के बारे में अधिक जानना चाहते हैं, तो कृपया इस डॉक को देखें: APISIX limit-req
कनेक्शनों को सीमित करें
limit-conn प्लगइन समानांतर अनुरोधों (या समानांतर कनेक्शनों) को सीमित करता है। निम्नलिखित /user/login के लिए इस प्लगइन को सक्षम करने के लिए एक उदाहरण कोड स्निपेट है:
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "methods": ["POST"], "uri": "/user/login", "id": 1, "plugins": { "limit-conn": { "conn": 3, "burst": 2, "default_conn_delay": 0.1, "rejected_code": 503, "key": "remote_addr" } }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }'
इस कोड स्निपेट का अर्थ: हम क्लाइंट के IP पते को समानांतर अनुरोधों को सीमित करने के लिए आवश्यकता के रूप में उपयोग करते हैं।
- यदि एक ही क्लाइंट के समानांतर कनेक्शन 3 (
conn) से कम हैं, तो यह सामान्य स्थिति 200 का जवाब देगा; - यदि समानांतर कनेक्शन 3 (
conn) से अधिक लेकिन 5 (conn+burst) से कम हैं, तो हम अतिरिक्त अनुरोधों को धीमा कर देंगे, और 0.1 सेकंड की देरी समय बढ़ाएंगे; - यदि समानांतर कनेक्शन 5 (
conn+burst) से अधिक हैं, तो यह अनुरोध अस्वीकार कर दिया जाएगा और HTTP कोड 503 वापस कर दिया जाएगा।
यदि आप limit-conn के बारे में अधिक जानना चाहते हैं, तो कृपया इस डॉक को देखें: APISIX limit-conn
गिनती को सीमित करें
limit-count प्लगइन Github के API रेट लिमिटिंग के समान है; यह एक विशिष्ट समय अंतराल में कुल अनुरोधों की संख्या को सीमित करेगा और शेष अनुरोधों की संख्या को HTTP हेडर में वापस पास करेगा। निम्नलिखित /user/login के लिए इस प्लगइन को सक्षम करने के लिए एक उदाहरण कोड स्निपेट है:
curl -i http://127.0.0.1:9080/apisix/admin/routes/1 \ -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "uri": "/user/login", "plugins": { "limit-count": { "count": 3, "time_window": 60, "rejected_code": 503, "key": "remote_addr", "policy": "local" } }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:9001": 1 } } }'
इस कोड स्निपेट का अर्थ: हम क्लाइंट के IP पते को अनुरोधों की संख्या को सीमित करने के लिए आवश्यकता के रूप में उपयोग करते हैं; काउंटर स्थानीय मेमोरी में सहेजा जाता है।
यदि 60 सेकंड (time_window) के भीतर 3 (count) से अधिक अनुरोध हैं, तो 3 बार से अधिक भेजे गए अनुरोध HTTP कोड 503 (rejected_code) वापस कर देंगे।
यदि आप limit-count के बारे में अधिक जानना चाहते हैं, तो कृपया इस डॉक को देखें: APISIX limit-count
Apache APISIX रेट लिमिटिंग के लाभ
जब हम NGINX का उपयोग करके ट्रैफिक को प्रबंधित करते हैं, यदि API अनुरोधों की संख्या ट्रैफिक का एक बड़ा विस्फोट पैदा करती है, तो NGINX अपनी कमियों को उजागर करेगा, और इनमें से एक कमी यह है कि यह कॉन्फ़िगरेशन को गतिशील रूप से लोड नहीं कर सकता है। दूसरी ओर, APISIX की सेवाएं (जैसे रूट और सेवा) कॉन्फ़िगरेशन हॉट-रिलोडिंग का समर्थन कर सकती हैं। यहां तक कि यदि ट्रैफिक का एक बड़ा विस्फोट होता है, तो APISIX तुरंत रेट लिमिटेशन और अन्य सुरक्षा प्लगइन कॉन्फ़िगरेशन को संशोधित कर सकता है। etcd की वॉच मैकेनिज्म के कारण, यह APISIX को सेवाओं को रीलोड किए बिना मिलीसेकंड के भीतर डेटा लेयर को अपडेट करने की अनुमति देता है।
इसके अलावा, APISIX क्लस्टर-स्तरीय रेट लिमिटिंग का भी समर्थन करता है। उदाहरण के लिए, हम limit-count का उपयोग करके policy की कॉन्फ़िगरेशन को redis या redis-cluster में संशोधित कर सकते हैं। इसलिए, हम विभिन्न APISIX नोड्स के बीच गणना परिणामों को साझा करके क्लस्टर-स्तरीय रेट को सीमित कर सकते हैं।
एक DevOps के रूप में, सभी API सेवाओं को प्रबंधित करने के लिए एक ग्राफिकल डैशबोर्ड का उपयोग करना उत्पादकता को बढ़ाएगा। APISIX एक साफ-सुथरा दृश्य प्रबंधन डैशबोर्ड प्रदान करता है जो API कॉन्फ़िगरेशन संशोधन को और अधिक सुविधाजनक बनाता है।
निष्कर्ष
रेट लिमिटिंग वास्तविक व्यावसायिक परिदृश्यों में एक सामान्य आवश्यकता है, और यह सिस्टम को ट्रैफिक स्पाइक्स से बचाने और इसके सुचारू संचालन को सुनिश्चित करने का एक महत्वपूर्ण तरीका है। रेट लिमिटिंग API सेवाओं के प्रबंधन का केवल एक हिस्सा है; हम कई अन्य तकनीकों का उपयोग करके महत्वपूर्ण सुरक्षा समर्थन प्रदान कर सकते हैं और उपयोगकर्ता अनुभव में सुधार कर सकते हैं।