நாங்களே எங்கள் சொந்த சேவைகளை rate-limit செய்துகொண்டிருந்தோம்

Mythex-இன் API ஒரு network முகவரியிலிருந்து நிமிடத்துக்கு 300 கோரிக்கைகளை அனுமதிக்கிறது. ஒரு நபர் அல்லது script API-ஐ அடித்துத் துன்புறுத்துவதிலிருந்து எங்களைப் பாதுகாக்கவே அந்த வரம்பு உள்ளது. Production-இல் அது எங்கள் சொந்த சேவைகளையே மறுக்கத் தொடங்கியது. அதாவது, வெளியிடப்பட்ட ஆப்களுக்குச் சேவை செய்யும் எங்கள் edge-இன் பகுதியும், AI ஏஜென்ட்டை இயக்கும் சேவையும். ஏனெனில் ஒவ்வொன்றும் சில முகவரிகளிலிருந்து மட்டுமே API-ஐ அடைகின்றன. எங்கள் உள் நற்சான்று கொண்ட கோரிக்கைகள் இப்போது விலக்கப்பட்டுள்ளன. மற்ற அனைவரும் முன்பு போலவே வரம்புக்கு உட்பட்டவர்கள்.

அறிகுறி

API எங்கள் சொந்த உள் அழைப்புகளில் சிலவற்றுக்கு 429 Too Many Requests என்று பதில் சொல்லத் தொடங்கியது. மூன்று வகை அழைப்புகள் பாதிக்கப்பட்டன. ஒவ்வொன்றும் Mythex-ஐப் பயன்படுத்தும் ஒருவருக்கு முக்கியமானது:

• ஒரு தனிப்பயன் domain-இல் எந்த ஆப் இருக்கிறது என்று தேடுதல். ஒரு பார்வையாளர் வெளியிடப்பட்ட ஆப்பை அதன் சொந்த domain-இல் திறக்கும்போது, எங்கள் edge அந்தத் தளம் எங்கே இருக்கிறது என்று API-இடம் கேட்கிறது. அங்கே 429 என்பது ஒரு தளத்தை அடைய முடியாத பார்வையாளர் என்று பொருள்.
• இயங்கும் ஏஜென்ட் turn-ஐ சேமித்தல். ஏஜென்ட் வேலை செய்யும்போது அதன் முன்னேற்றம் போகப் போகச் சேமிக்கப்படுகிறது. அதனால் பதில் refresh அல்லது துண்டிக்கப்பட்ட இணைப்பிலிருந்து தப்பும். அங்கே 429 என்பது சேமிக்கப்படாத முன்னேற்றம்.
• preview-க்கான அணுகலைச் சரிபார்த்தல். நீங்கள் கட்டும் ஆப்பின் preview பாதுகாக்கப்பட்டுள்ளது. அந்தக் காவல் API-இடம் கேட்கிறது. அங்கே 429 என்பது திறக்காத ஒரு preview.

இவற்றில் எதுவும் API-ஐ அழைத்த மக்கள் அல்ல. அனைத்தும் நாங்களே.

இது ஏன் நடந்தது

ஒரு முகவரிக்கான rate limit ஒரே ஒரு அனுமானத்தைக் கொண்டுள்ளது: ஒரு முகவரி என்பது ஏறத்தாழ ஒரு அழைப்பாளர். மக்களுக்கு அது போதுமான அளவு நெருக்கமானது. எங்கள் சொந்த உள்கட்டமைப்புக்கு அது மோசமாகத் தவறானது.

• வெளியிடப்பட்ட ஆப்களுக்கும் preview-களுக்கும் சேவை செய்யும் edge சேவை, சில பகிரப்பட்ட வெளிச்செல்லும் முகவரிகளிலிருந்து API-ஐ அடைகிறது. ஒவ்வொரு வெளியிடப்பட்ட ஆப்பின் ஒவ்வொரு பார்வையாளரும், ஒவ்வொரு preview சோதனையும், அந்தச் சில முகவரிகளில் ஒன்றிலிருந்து வருவது போலத் தெரிகிறது.
• ஏஜென்ட் turns-ஐ இயக்கும் orchestrator, ஒரு container முகவரியிலிருந்து API-ஐ அடைகிறது. இயங்கும் ஒவ்வொரு turn-உம், ஒவ்வொரு பயனருக்கும், அதைப் பகிர்ந்துகொள்கிறது.

எனவே ஒரு நபருக்காக வடிவமைக்கப்பட்ட பட்ஜெட், முழு சேவையின் போக்குவரத்து அனைத்தின் மீதும் பிரிக்கப்பட்டுக்கொண்டிருந்தது. அந்தச் சேவைகள் அதைத் தங்களுக்குள் பயன்படுத்தித் தீர்த்தன. வரம்பு கூறப்பட்டதைச் சரியாகச் செய்தது: அவற்றை மறுத்தது.

சரி

எங்கள் சொந்த சேவைகள் ஏற்கனவே தாங்கள் யார் என்பதை நிரூபிக்கின்றன. ஒவ்வொரு உள் அழைப்பும் ஓர் உள் token-ஐ எடுத்துச் செல்கிறது. API-இன் உள் பகுதியின் கீழ் உள்ள ஒவ்வொரு route-உம் எதையும் செய்வதற்கு முன் அந்த token-ஐ சரிபார்க்கிறது.

Rate limiter இப்போது அதே சரிபார்ப்பைப் பயன்படுத்துகிறது. உள் token-உடன் பொருந்தும் கோரிக்கை ஒரு அனுமதிப் பட்டியலில் உள்ளது. அது ஒரு முகவரிக்கான பட்ஜெட்டில் கணக்கிடப்படாது. மற்ற அனைத்தும் முன்பு போலவே கணக்கிடப்படுகின்றன: ஒரு முகவரிக்கு நிமிடத்துக்கு 300 கோரிக்கைகள்.

இதை ஒரு ஓட்டையாக மாறவிடாமல் இரண்டு விவரங்கள் தடுத்தன:

1. தவறான token-க்கு அனுமதி இல்லை. அனுமதிப் பட்டியல் உண்மையான உள் token-உடன் மட்டுமே பொருந்தும். போலியான token கொண்ட கோரிக்கை மற்ற எதையும் போலவே கணக்கிடப்பட்டு வரம்பிடப்படும். உள் routes அதை இன்னும் 401 Unauthorized உடன் நிராகரிக்கும்.
2. வரம்பே மாறவில்லை. இடம் உருவாக்க எண்ணை உயர்த்தவில்லை. எண்ணை உயர்த்தியிருந்தால், போக்குவரத்து மீண்டும் வளரும் வரை பிரச்சினையை மறைத்திருக்கும். வரம்பு எதற்காக இருக்கிறதோ அந்த நிகழ்வுக்கான பாதுகாப்பையும் பலவீனப்படுத்தியிருக்கும்.

Limiter-இன் அமைப்புகளை ஒரு சிறிய function-க்குள் நகர்த்தி, அதற்கெதிராகச் சோதனைகள் எழுதினோம். ஒன்று: உள் token கொண்டு 20 கோரிக்கைகளை 5-ஐ மட்டும் அனுமதிக்கும் limiter-க்கு அனுப்பி, 20-உம் வெற்றியடைய வேண்டும் என எதிர்பார்க்கிறது. இன்னொன்று: ஒரே முகவரியிலிருந்து சாதாரண கோரிக்கைகளை அனுப்பி, முதல் ஐந்து வெற்றியடைய வேண்டும், பின்னர் வருபவை மறுக்கப்பட வேண்டும் என எதிர்பார்க்கிறது. மூன்றாவது: போலி token கொண்ட கோரிக்கைகளை அனுப்பி, அவை அதே முறையில் மறுக்கப்பட வேண்டும் என எதிர்பார்க்கிறது.

இதிலிருந்து நாங்கள் எடுத்துக்கொண்டவை

• வரம்புகள் அனுமானங்களைச் சுமக்கின்றன. "ஒரு முகவரி, ஒரு அழைப்பாளர்" என்பது ஒரு முகவரிக்கான வரம்பில் கட்டப்பட்டுள்ளது. உங்கள் சொந்த சேவைகள் பகிரப்பட்ட முகவரிகளுக்குப் பின்னால் அமர்ந்தவுடன் அது உண்மையாக இருப்பதை நிறுத்துகிறது. பலவும் அப்படித்தான் அமர்கின்றன: load balancers, edge networks, containers, அலுவலக நெட்வொர்க்குகள்.
• உங்கள் சொந்தப் போக்குவரத்தை முகவரியால் அல்ல, அடையாளத்தால் வேறுபடுத்துங்கள். முகவரிகள் போக்குவரத்து எப்படி வருகிறது என்பதைக் காட்டுகின்றன. அதை அனுப்பியவர் யார் என்பதை அல்ல. அழைப்பு எங்களுடையது என்று நிரூபிக்கும் ஒரு நற்சான்று எங்களிடம் ஏற்கனவே இருந்தது. limiter அதைப் பார்க்கவில்லை, அவ்வளவுதான்.
• எண்ணை உயர்த்தி சரிசெய்யாதீர்கள். பெரிய வரம்பு 429-களை சிறிது காலத்துக்கு மறைத்திருக்கும். குறைவாகவே பாதுகாத்திருக்கும். பின்னர் மீண்டும் தோல்வியடைந்திருக்கும்.
• யார் வரம்பிடப்படுகிறார்கள் என்று பாருங்கள். உங்கள் சொந்த சேவையின் மீது விழும் 429, உங்கள் வரம்புகளைப் பற்றிய ஒரு பிழை அறிக்கை. limiter வேலை செய்கிறது என்பதன் அடையாளம் அல்ல.

Mythex-இல் நீங்கள் கட்டினால் இதன் பொருள்

உங்கள் பக்கத்தில் எதையும் மாற்ற வேண்டியதில்லை. தனிப்பயன் domains-இல் வெளியிடப்பட்ட ஆப்கள், ஏஜென்ட் turns, மற்றும் previews இனி Mythex-இன் மற்ற பகுதி எவ்வளவு பிஸியாக இருக்கிறது என்பதைச் சார்ந்திருக்காது. உங்கள் ஆப்பின் சொந்தப் போக்குவரத்து உங்கள் ஆப்பின் விஷயம். இங்கே விவரிக்கப்பட்ட வரம்பு எங்கள் API-இல் உள்ளது, நீங்கள் வெளியிடும் ஆப்களில் அல்ல.

நீங்களே ஒரு backend இயக்கினால், நீங்கள் சேர்க்கும் எந்த rate limit-க்கும் இதே பொறி பொருந்தும். API என்றால் என்ன மற்றும் AI-ஆல் கட்டிய ஆப்களுக்கான பாதுகாப்புப் பட்டியல் ஆகியவை தொடங்க நல்ல இடங்கள். எங்கள் சொந்த உள்கட்டமைப்பு தன் வழியிலேயே தடுக்கும் மற்றொரு நிகழ்வுக்கு, எங்கள் deploy-களை பூஜ்ஜிய 502 பிழைகளுக்குக் கொண்டுவந்தது எப்படி என்பதைப் பாருங்கள்.