अपने सर्वर रहित अनुप्रयोगों को सीमित करने की दर

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

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

2- उपयोगकर्ता कोटा प्रबंधित करें: आप अपनी सेवाओं के उचित उपयोग के लिए अपने उपयोगकर्ताओं के लिए कोटा निर्धारित करना चाह सकते हैं। इसके अलावा, यदि आप अलग-अलग मूल्य-निर्धारण स्तरों में अपनी सेवाएं प्रदान करते हैं, तो आपको कोटा की आवश्यकता हो सकती है।

3- लागत नियंत्रित करें: कई वास्तविक जीवन उदाहरण हैं कि कैसे एक अनियंत्रित प्रणाली बड़े बिलों का कारण बन सकती है। सर्वर रहित अनुप्रयोगों के लिए यह काफी जोखिम भरा है, इसकी अत्यधिक स्केलेबल प्रकृति का धन्यवाद। दर सीमित करने से आपको इन लागतों को नियंत्रित करने में मदद मिलेगी।

समाधान

विभिन्न परतों में कई वैकल्पिक दर सीमित समाधान हैं। मैं एक संक्षिप्त पेशेवरों/विपक्ष विश्लेषण के साथ 3 मुख्य सूची दूंगा।

1- कार्य का समवर्ती स्तर:

क्लाउड प्रदाता आपके सर्वर रहित फ़ंक्शन निष्पादन को मापने के लिए कई कंटेनर बनाते हैं। आप समवर्ती कंटेनरों/उदाहरणों की अधिकतम संख्या के लिए एक सीमा निर्धारित कर सकते हैं। हालांकि यह आपको संगामिति को सीमित करने में मदद कर सकता है, लेकिन यह नियंत्रित नहीं करता है कि आपके फ़ंक्शन को एक सेकंड में कितनी बार कॉल किया जाएगा।

यहां आप एडब्ल्यूएस लैम्ब्डा और Google क्लाउड फ़ंक्शंस के लिए समवर्ती को कैसे सीमित कर सकते हैं।

पेशेवरों:

कोई ओवरहेड नहीं
कॉन्फ़िगर करने में आसान

विपक्ष:

पूर्ण समाधान नहीं है। केवल संगामिति को नियंत्रित करता है। प्रति सेकंड निष्पादन की संख्या सीमित नहीं है।

2- API गेटवे पर दर सीमित करना

यदि आप एपीआई गेटवे के माध्यम से अपने कार्यों का उपयोग कर रहे हैं, तो आप एपीआई गेटवे पर अपनी दर सीमित करने वाली नीति लागू कर सकते हैं। AWS और GCP दोनों के पास अपने समाधानों को कॉन्फ़िगर करने के तरीके के बारे में गाइड हैं।

पेशेवरों:

कोई ओवरहेड नहीं
कॉन्फ़िगर करने में आसान

विपक्ष:

केवल तभी लागू होता है जब आप एपीआई गेटवे का उपयोग कर रहे हों।
यह प्रति उपयोगकर्ता या प्रति आईपी कोटा जैसे अधिक परिष्कृत मामलों का समर्थन नहीं करता है।

3- रेडिस के साथ सीमित दर

यह सबसे पूर्ण और शक्तिशाली उपाय है। कई रेडिस आधारित दर सीमित पुस्तकालय उपलब्ध हैं। जेरेमी डेली के ब्लॉग पोस्ट में, उन्होंने Elasticache को एक संभावित समाधान के रूप में खारिज करते हुए कहा कि* this adds a “non-serverless” component and another thing to manage *. यहाँ Upstash अपने सर्वर रहित मॉडल और प्रति-अनुरोध-मूल्य निर्धारण के साथ एक बहुत अच्छा विकल्प बन गया है।

पेशेवरों:

शक्तिशाली, आप एक अनुकूलित तर्क लागू कर सकते हैं जो आपके उपयोगकर्ता मॉडल के अनुकूल हो।
स्केलेबल समाधान। देखें कि कैसे जीथब रेट सीमित करने के लिए रेडिस का उपयोग करता है
समृद्ध पारिस्थितिकी तंत्र, कई खुले स्रोत पुस्तकालय:redis_rate, redis-cell, node-ratelimiter

विपक्ष:

Redis का उपयोग करने का ओवरहेड।

कोड:Redis के साथ रेट लिमिटिंग

दर सीमित पुस्तकालयों के लिए धन्यवाद, अपने आवेदन कोड तक सीमित दर लागू करना बहुत आसान है। यहाँ नीचे उदाहरण कोड प्रति सेकंड प्रति आईपी एडब्ल्यूएस लैम्ब्डा फ़ंक्शन के निष्पादन को सीमित करता है:

const RateLimiter = require("async-ratelimiter");
const Redis = require("ioredis");
const { getClientIp } = require("request-ip");

const rateLimiter = new RateLimiter({
  db: new Redis("YOUR_REDIS_URL"),
  max: 1,
  duration: 5_000,
});

module.exports.hello = async (event) => {
  const clientIp = getClientIp(event) || "NA";
  const limit = await rateLimiter.get({ id: clientIp });
  if (!limit.remaining) {
    return {
      statusCode: 429,
      body: JSON.stringify({
        message: "Sorry, you are rate limited. Wait for 5 seconds",
      }),
    };
  }

  return {
    statusCode: 200,
    body: JSON.stringify({
      message: "hello!",
    }),
  };
};

पूरे उदाहरण के लिए ट्यूटोरियल पर जाएँ।

पढ़ने की सूची

https://cloud.google.com/architecture/rate-limiting-strategies-techniques

https://www.jeremydaly.com/throttling-third-party-api-calls-with-aws-lambda/

https://medium.com/google-cloud/rate-limit-your-api-usage-with-cloud-endpoints-quotas-1270da55d2bf

https://github.blog/2021-04-05-how-we-scaled-github-api-sharded-replicated-rate-limiter-redis/

https://redis.io/commands/incr#pattern-rate-limiter

https://stripe.com/blog/rate-limiters