Blog

Po e kufizonim veten tonë me rate limit

API-ja e Mythex lejon 300 kërkesa në minutë nga një adresë rrjeti e vetme. Ky kufi ekziston për të na mbrojtur nga një person ose skript që e bombardon API-n. Në prodhim, filloi të refuzonte shërbimet tona — pjesën e edge-it që shërben aplikacionet e publikuara dhe shërbimin që ekzekuton agjentin AI — sepse secili prej tyre e arrin API-n vetëm nga një grusht adresash. Kërkesat që mbajnë kredencialin tonë të brendshëm tani janë të përjashtuara, dhe të tjerët kufizohen saktësisht si më parë.

Simptoma

API-ja filloi t’u përgjigjej disa thirrjeve tona të brendshme me 429 Too Many Requests. Ishin goditur tre lloje thirrjesh, dhe secili ka rëndësi për dikë që përdor Mythex:

  • Kërkimi se cili aplikacion jeton në një domain të personalizuar. Kur një vizitor hap një aplikacion të publikuar në domainin e vet, edge-i ynë e pyet API-n se ku ndodhet sajti. Një 429 aty do të thotë një vizitor që nuk arrin dot një sajt.
  • Ruajtja e një ture agjenti që po ekzekutohet. Ndërsa agjenti punon, progresi i tij ruhet ndërsa shkon, që një përgjigje të mbijetojë një rifreskim ose një lidhje të ndërprerë. Një 429 aty do të thotë progres që nuk u ruajt.
  • Kontrolli i aksesit në një preview. Preview-ja e një aplikacioni që po ndërtoni është e mbrojtur, dhe mbrojtja e pyet API-n. Një 429 aty do të thotë një preview që nuk hapet.

Asnjë nga këto nuk ishin njerëz që thërrisnin API-n. Të gjitha ishim ne.

Pse ndodhi

Një kufi për adresë bën një supozim: një adresë është afërsisht një thirrës. Për njerëzit, kjo është mjaft afër. Për infrastrukturën tonë, është shumë e gabuar.

  • Shërbimi edge që shërben aplikacionet e publikuara dhe preview-të e arrin API-n nga disa adresa dalëse të përbashkëta. Çdo vizitor i çdo aplikacioni të publikuar dhe çdo kontroll preview-je vjen si nga njëra prej atyre pak adresave.
  • Orkestratori — shërbimi që ekzekuton turat e agjentit — e arrin API-n nga një adresë kontejneri të vetme. Çdo tur që po ekzekutohet, për çdo përdorues, e ndan atë.

Kështu buxheti që ishte për një person po ndahej mes gjithë trafikut të një shërbimi të tërë. Shërbimet u përdorën njëra-tjetrës, dhe kufizuesi bëri atë që i ishte thënë: i refuzoi.

Zgjidhja

Shërbimet tona të brendshme e vërtetojnë tashmë identitetin e tyre. Çdo thirrje e brendshme mban një token të brendshëm, dhe çdo rrugë nën seksionin e brendshëm të API-t kontrollon atë token para se të bëjë çfarëdo gjëje.

Kufizuesi tani përdor të njëjtën kontroll. Një kërkesë me token që përputhet me atë të brendshmin është në një listë të lejuar dhe nuk llogaritet në buxhetin për adresë. Çdo gjë tjetër llogaritet saktësisht si më parë: 300 kërkesa në minutë për adresë.

Dy detaje e mbajtën këtë larg nga të qenit një vrimë:

  1. Një token i gabuar nuk merr kalim. Lista e lejuar përputhet vetëm me token-in e vërtetë të brendshëm. Një kërkesë me një token të shpikur llogaritet dhe kufizohet si çdo tjetër, dhe rrugët e brendshme e refuzojnë përsëri me 401 Unauthorized.
  2. Vetë kufiri nuk u ndryshua. Nuk e ngritëm numrin për të bërë vend, sepse kjo do ta fshihte problemin derisa trafiku të rritej përsëri, dhe do ta dobësonte mbrojtjen për rastin për të cilin ekziston kufiri.

I vendosëm cilësimet e kufizuesit në një funksion të vogël dhe shkruam teste kundër tij. Njëri dërgon 20 kërkesa me token-in e brendshëm te një kufizues i vendosur për të lejuar 5, dhe pret që të 20 të kenë sukses. Një tjetër dërgon kërkesa të thjeshta nga një adresë dhe pret që 5 të parat të kenë sukses dhe ato pas tyre të refuzohen. Një i tretë dërgon kërkesa me token të falsifikuar dhe pret që të refuzohen në të njëjtën mënyrë.

Çfarë nxorëm nga kjo

  • Kufijtë mbajnë supozime. "Një adresë, një thirrës" është e integruar në një kufi për adresë. Pushon së qeni e vërtetë sapo shërbimet tuaja të brendshme ndodhen pas adresave të përbashkëta — dhe shumë prej tyre janë: load balancer-ë, rrjete edge, kontejnerë, rrjete zyrash.
  • Dalloni trafikun tuaj me identitet, jo me adresë. Adresat janë mënyra se si arrin trafiku, jo kush e dërgoi. Ne kishim tashmë një kredencial që vërteton se një thirrje është e jona; kufizuesi thjesht nuk po e shikonte.
  • Mos e rregulloni duke rritur numrin. Një kufi më i madh do ta kishte bërë 429-at të zhdukeshin për një kohë, do të kishte mbrojtur më pak, dhe do të dështonte sërish më vonë.
  • Shikoni kush po kufizohet. Një 429 që bie mbi shërbimin tuaj është një raport gabimi për kufijtë tuaj, jo shenjë që kufizuesi punon.

Çfarë do të thotë nëse ndërtoni në Mythex

Nuk ka asgjë për të ndryshuar nga ana juaj. Aplikacionet e publikuara në domain të personalizuar, turet e agjentit dhe preview-të nuk varen më nga sa e zënë është pjesa tjetër e Mythex. Trafiku i vetë aplikacionit tuaj është çështja juaj: kufiri i përshkruar këtu është në API-n tonë, jo në aplikacionet që publikoni.

Nëse keni një backend të vetin, i njëjti kurth zbatohet për çdo rate limit që shtoni. Udhëzuesit tanë për çfarë është një API dhe listën e sigurisë për aplikacionet e ndërtuara me AI janë një vend i mirë për të filluar. Dhe për një rast tjetër ku infrastruktura jonë na pengonte vetveten, shihni si arritëm deploy-e me zero gabime 502.

Mythex · Pricing · Ndërtoni çdo gjë me AI · Shablone faqesh dhe aplikacionesh · Mythex në krahasim · Fjalori i ndërtimit të aplikacioneve me AI · Mjete falas për ndërtimin e aplikacioneve me 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 Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)