आम्ही स्वतःच्या सेवांवर rate limit लावत होतो

Mythex च्या API ला एका network पत्त्यावरून प्रति मिनिट 300 विनंत्यांची परवानगी आहे. ती मर्यादा एखाद्या व्यक्तीने किंवा script ने API वर हल्ला करण्यापासून संरक्षण करण्यासाठी आहे. Production मध्ये, तिने आमच्याच सेवांना नाकारायला सुरुवात केली — आमच्या edge चा तो भाग जो प्रकाशित ॲप्स सेवा करतो आणि AI agent चालवणारी सेवा — कारण त्यांपैकी प्रत्येक API ला मूठभर पत्त्यांवरूनच पोहोचते. आमचे अंतर्गत credential असलेल्या विनंत्यांना आता सूट आहे, आणि बाकी सर्वांवर पूर्वीसारखीच मर्यादा आहे.

लक्षण

API ने आमच्या स्वतःच्या काही अंतर्गत कॉल्सना 429 Too Many Requests ने उत्तर देणे सुरू केले. तीन प्रकारचे कॉल्स प्रभावित झाले, आणि प्रत्येकाचा Mythex वापरणाऱ्या कोणालातरी फरक पडतो:

• Custom domain वर कोणते ॲप आहे ते शोधणे. जेव्हा visitor स्वतःच्या domain वर प्रकाशित ॲप उघडतो, तेव्हा आमचा edge API ला ती साइट कुठे आहे ते विचारतो. तिथे 429 म्हणजे साइटपर्यंत पोहोचू न शकणारा visitor.
• चालणारी agent turn सेव्ह करणे. Agent काम करत असताना त्याची प्रगती तो जाताना सेव्ह होते, त्यामुळे refresh किंवा तुटलेल्या connection नंतरही उत्तर टिकते. तिथे 429 म्हणजे न सेव्ह झालेली प्रगती.
• Preview चा प्रवेश तपासणे. तुम्ही बांधत असलेल्या ॲपचे preview gated आहे, आणि gate API ला विचारतो. तिथे 429 म्हणजे न उघडणारे preview.

यापैकी कोणतेही API ला कोणी व्यक्तीने कॉल केले नव्हते. सर्व आमच्याच होते.

हे का घडले

प्रति-पत्ता rate limit एक गृहीतक धरते: एक पत्ता साधारणपणे एक caller असतो. लोकांसाठी ते पुरेसे जवळ आहे. आमच्या स्वतःच्या पायाभूत सुविधांसाठी ते चुकीचे आहे.

• Published ॲप्स आणि previews सेवा करणारी edge सेवा काही सामायिक outgoing पत्त्यांवरून API ला पोहोचते. प्रत्येक published ॲपचा प्रत्येक visitor, आणि प्रत्येक preview तपासणी, त्यांपैकी एका पत्त्यावरून आल्यासारखी दिसते.
• Orchestrator — agent turns चालवणारी सेवा — API ला एका container पत्त्यावरून पोहोचते. प्रत्येक चालणारी turn, प्रत्येक वापरकर्त्यासाठी, तो पत्ता सामायिक करते.

म्हणजे एका व्यक्तीसाठी बनवलेले बजेट संपूर्ण सेवेच्या सर्व ट्रॅफिकमध्ये वाटले जात होते. त्या सेवांनी ते आपापसात संपवले, आणि limiter ने सांगितल्याप्रमाणेच केले: त्यांना नाकारले.

उपाय

आमच्या स्वतःच्या सेवा आधीच सिद्ध करतात की त्या कोण आहेत. प्रत्येक अंतर्गत कॉल एक अंतर्गत token वाहतो, आणि API च्या अंतर्गत विभागाखालील प्रत्येक route काहीही करण्याआधी त्या token ची तपासणी करतो.

Rate limiter आता तीच तपासणी वापरतो. जी विनंती token जुळते तिला allow list वर ठेवले जाते आणि प्रति-पत्ता बजेटमध्ये मोजले जात नाही. बाकी सर्व पूर्वीसारखेच मोजले जाते: प्रति पत्ता प्रति मिनिट 300 विनंत्या.

दोन तपशिलांनी हे पळवाट बनू दिले नाही:

1. चुकीच्या token ला सूट नाही. Allow list फक्त खरे अंतर्गत token जुळवते. बनावट token असलेली विनंती मोजली जाते आणि इतर कोणत्याही प्रमाणे throttle होते, आणि अंतर्गत routes ती 401 Unauthorized ने नाकारतात.
2. मर्यादा बदलली नाही. जागा करण्यासाठी आम्ही आकडा वाढवला नाही. आकडा वाढवल्याने समस्या पुन्हा ट्रॅफिक वाढेपर्यंत लपली असती, आणि ज्या प्रकरणासाठी मर्यादा आहे त्यासाठीचे संरक्षण कमी केले असते.

आम्ही limiter च्या सेटिंग्ज एका लहान function मध्ये हलवल्या आणि त्यावर चाचण्या लिहिल्या. एक चाचणी अंतर्गत token सह 20 विनंत्या 5 ची परवानगी असलेल्या limiter वर पाठवते, आणि सर्व 20 यशस्वी होतील अशी अपेक्षा करते. दुसरी एका पत्त्यावरून साध्या विनंत्या पाठवते आणि पहिल्या पाच यशस्वी आणि नंतरच्या नाकारल्या जातील अशी अपेक्षा करते. तिसरी बनावट token असलेल्या विनंत्या पाठवते आणि त्या त्याच पद्धतीने नाकारल्या जातील अशी अपेक्षा करते.

त्यातून आम्ही काय शिकलो

• मर्यादांमध्ये गृहीतके असतात. "एक पत्ता, एक caller" प्रति-पत्ता मर्यादेत अंगभूत आहे. तुमच्या स्वतःच्या सेवा सामायिक पत्त्यांमागे आल्या की ते खरे राहणे थांबते — आणि अनेक सेवा असतात: load balancers, edge networks, containers, office networks.
• तुमचे स्वतःचे ट्रॅफिक पत्त्यानुसार नव्हे, ओळखीनुसार वेगळे करा. पत्ते म्हणजे ट्रॅफिक कसे येते, कोणी पाठवले ते नव्हे. कॉल आपला आहे हे सिद्ध करणारे credential आमच्याकडे आधीच होते; limiter फक्त त्याकडे पाहत नव्हता.
• आकडा वाढवून दुरुस्त करू नका. मोठी मर्यादा काही काळ 429 गायब केले असते, कमी संरक्षण दिले असते आणि नंतर पुन्हा अपयशी ठरले असते.
• कोणाला throttle होत आहे ते पहा. तुमच्या स्वतःच्या सेवेवर लागलेला 429 हा तुमच्या मर्यादांबद्दलचा bug अहवाल आहे, limiter काम करत आहे याचे चिन्ह नव्हे.

तुम्ही Mythex वर बांधत असाल तर याचा अर्थ

तुमच्या बाजूला बदलण्यासारखे काहीच नाही. Custom domains वरील प्रकाशित ॲप्स, agent turns आणि previews आता बाकी Mythex किती व्यस्त आहे यावर अवलंबून नाहीत. तुमच्या ॲपचा स्वतःचा ट्रॅफिक तुमच्या ॲपचा विषय आहे: येथे वर्णन केलेली मर्यादा आमच्या API वर आहे, तुम्ही प्रकाशित केलेल्या ॲप्सवर नाही.

तुमचा स्वतःचा backend चालवत असाल तर, तुम्ही जोडलेल्या कोणत्याही rate limit ला हाच सापळा लागू होतो. API म्हणजे काय आणि AI-built ॲप्ससाठी सुरक्षा चेकलिस्ट ही सुरुवात करण्यासाठी चांगली मार्गदर्शक आहेत. आणि आमच्या स्वतःच्या पायाभूत सुविधा स्वतःलाच अडवतात त्याच्या दुसऱ्या उदाहरणासाठी, deploys शून्य 502 errors पर्यंत कसे आणले पहा.