ब्लॉग

हम अपनी ही सेवाओं पर रेट लिमिट लगा रहे थे

Mythex का API एक नेटवर्क पते से प्रति मिनट 300 अनुरोध की अनुमति देता है। यह सीमा API को किसी एक व्यक्ति या स्क्रिप्ट के हमला करने से बचाने के लिए है। प्रोडक्शन में इसने हमारी अपनी सेवाओं को मना करना शुरू कर दिया: हमारे एज का वह हिस्सा जो पब्लिश किए गए ऐप्स सर्व करता है, और वह सेवा जो AI एजेंट चलाती है, क्योंकि दोनों API तक केवल कुछ ही पतों से पहुँचते हैं। अब हमारी आंतरिक क्रेडेंशियल वाले अनुरोध छूट में हैं, और बाकी सबकी सीमा पहले जैसी ही है।

लक्षण

API हमारी कुछ आंतरिक कॉल्स को 429 Too Many Requests से जवाब देने लगा। तीन तरह की कॉल्स प्रभावित हुईं, और हर एक Mythex इस्तेमाल करने वाले किसी के लिए मायने रखती है:

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

इनमें से किसी में भी लोग API को कॉल नहीं कर रहे थे। सब कुछ हम थे।

यह क्यों हुआ

प्रति-पता रेट लिमिट एक धारणा बनाती है: एक पता लगभग एक कॉलर है। लोगों के लिए यह काफ़ी सही है। हमारे अपने इन्फ़्रास्ट्रक्चर के लिए यह बहुत गलत है।

  • पब्लिश किए गए ऐप्स और प्रीव्यू सर्व करने वाली एज सेवा API तक कुछ साझा आउटगोइंग पतों से पहुँचती है। हर पब्लिश किए गए ऐप के हर विज़िटर और हर प्रीव्यू जाँच, सब इन्हीं कुछ पतों में से किसी एक से आते हुए दिखते हैं।
  • ऑर्केस्ट्रेटर, यानी वह सेवा जो एजेंट टर्न चलाती है, API तक एक कंटेनर पते से पहुँचता है। हर चल रहा टर्न, हर यूज़र के लिए, उसे साझा करता है।

तो एक व्यक्ति के लिए बना बजट पूरी सेवा के सारे ट्रैफ़िक में बँट रहा था। वे सेवाएँ मिलकर उसे खर्च कर रही थीं, और लिमिटर ने वही किया जो उसे कहा गया था: उसने उन्हें मना कर दिया।

समाधान

हमारी अपनी सेवाएँ पहले से ही साबित करती हैं कि वे कौन हैं। हर आंतरिक कॉल एक आंतरिक टोकन लेकर चलती है, और API के आंतरिक सेक्शन के हर रूट को कुछ करने से पहले वह टोकन जाँचना होता है।

रेट लिमिटर अब वही जाँच इस्तेमाल करता है। जिस अनुरोध का टोकन आंतरिक टोकन से मेल खाता है, वह एक अनुमति-सूची में है और प्रति-पता बजट में नहीं गिना जाता। बाकी सब पहले की तरह गिने जाते हैं: प्रति पता प्रति मिनट 300 अनुरोध।

दो विवरणों ने इसे एक छेद बनने से रोका:

  1. गलत टोकन को छूट नहीं मिलती। अनुमति-सूची केवल असली आंतरिक टोकन से मेल खाती है। बनावटी टोकन वाला अनुरोध बाकी किसी की तरह गिना और थ्रॉटल किया जाता है, और आंतरिक रूट उसे 401 Unauthorized से अब भी अस्वीकार करते हैं।
  2. सीमा खुद नहीं बदली। हमने जगह बनाने के लिए संख्या नहीं बढ़ाई। संख्या बढ़ाने से समस्या कुछ समय के लिए छिप जाती और ट्रैफ़िक फिर बढ़ने पर फिर विफल होती, और जिस स्थिति के लिए सीमा है उसकी सुरक्षा भी कमज़ोर होती।

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

हमने क्या सीखा

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

अगर आप Mythex पर बनाते हैं तो इसका क्या अर्थ है

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

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

Mythex · Pricing · AI से कुछ भी बनाएँ · वेबसाइट और ऐप टेम्पलेट · Mythex की तुलना · AI से ऐप बनाने की शब्दावली · AI से ऐप बनाने के फ्री टूल · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)