Šta je ograničenje broja zahteva? Vodič za pravljenje aplikacija, jednostavno

Rate limiting je pravilo koje ograničava koliko zahteva neko može da pošalje sistemu u zadatom vremenu, na primer 5 pokušaja prijave u minuti ili 100 API poziva na sat. Kada se dostigne limit, dalji zahtevi se odbijaju (obično greškom 429 Too Many Requests) dok se vremenski prozor ne resetuje. Štiti aplikacije od zloupotrebe, sprečava da jedan intenzivan korisnik uspori stvari svima i zaustavlja nekontrolisane troškove.

Sa rate limitingom se susrećete sa dve strane: servisi koje pozivate ograničavaju vas, a vaša sopstvena aplikacija treba da ograničava svoje korisnike.

Zašto rate limiting važi kada pravite aplikacije uz AI

Aplikacije pravljene uz AI često se povezuju sa plaćenim servisima, kao što su AI modeli, mejl, SMS i mape, a svaki poziv košta novac. Zato je rate limiting i sigurnosna i budžetska funkcija.

• Kontrola troškova. Ako vaša aplikacija ima polje „pitaj AI“ i nema limit, bot može da pošalje hiljade zahteva preko noći. Plaćate svaki od njih.
• Bezbednost. Bez limita na formularu za prijavu, napadač može da proba hiljade lozinki za jedan nalog. Limit od nekoliko pokušaja u minuti to čini nepraktičnim.
• Ostajanje na mreži. Jedan loše ponašajući skript, ponekad i vaš sopstveni kod zaglavljen u petlji, može da preoptereti bazu i sruši aplikaciju.
• Poštovanje tuđih limita. Kada vaša aplikacija prečesto poziva spoljni API, vi dobijate 429 greške, a funkcije se pokvare za vaše korisnike.

AI alati prave ono što tražite. Ako ne pomenete limite, često ih nema.

Svakodnevna analogija

Zamislite pravilo u kafiću za besplatno dopunjavanje: „Jedno besplatno dopunjavanje po gostu po poseti.“

• Ne sprečava nikoga da uživa u kafi.
• Sprečava jednu osobu da stoji na šanku ceo dan i dopunjava termos za celu kancelariju.
• Kada neko zatraži četvrto dopunjavanje, konobar ljubazno kaže „ne sada“, a to je 429.

Dobar rate limit je nevidljiv za obične goste i primeti ga samo neko ko radi nešto neobično.

Kako rate limiting radi

Ograničavač (rate limiter) treba tri stvari:

Kada stigne zahtev, aplikacija proverava brojač za taj „ko“. Ispod limita: zahtev prolazi i brojač raste. Preko limita: zahtev se odbija.

Postoji nekoliko uobičajenih načina brojanja:

Brojači moraju da budu sačuvani negde brzo i zajednički. Na jednom malom serveru dovoljna je memorija. Kada aplikacija radi na više mašina, brojač obično živi u zajedničkom skladištu kao što su Redis ili baza podataka, inače svaka mašina broji za sebe i stvarni limit postane nekoliko puta veći.

Kako izgleda odgovor kada je limit dostignut

Kada je zahtev preko limita, dobro napravljen API odgovara ovako:

• Statusni kod 429 Too Many Requests.
• Često zaglavlje Retry-After, koje kaže koliko sekundi treba čekati.
• Ponekad zaglavlja koja pokazuju vaš limit i koliko zahteva imate još u ovom prozoru (nazivi variraju među provajderima).

Vaša aplikacija treba da odgovori na 429 tako što će čekati i pokušati kasnije, po mogućnosti uz eksponencijalno čekanje (exponential backoff), što znači da se posle svakog neuspelog pokušaja čeka malo duže (1 sekunda, pa 2, pa 4), umesto da se servis bombarduje.

Radni primer: AI asistent za pisanje

Recimo da ste napravili aplikaciju u kojoj korisnici nalepe tekst i dobijaju AI prepisanu verziju.

Bez limita: neko napiše skript koji šalje 20.000 zahteva preko noći. Račun vašeg AI provajdera skoči, a vaš nalog dostigne sopstveni limit provajdera, pa pravi korisnici tokom jutra vide greške.

Sa razumnim limitima:

1. Po prijavljenom korisniku: 30 prepisivanja na sat u besplatnom paketu, 300 u plaćenom. Preko limita korisnik vidi: „Dostigli ste limit za ovaj sat. Pokušajte ponovo za 12 minuta ili nadogradite paket.“
2. Po IP adresi na formularu za registraciju: 5 registracija na sat, da botovi ne bi pravili hiljade besplatnih naloga i tako zaobišli limit po korisniku.
3. Limit potrošnje postavljen u kontrolnom panelu vašeg AI provajdera, kao poslednja linija odbrane ako sve drugo zakaže.
4. Rukovanje limitima provajdera: ako AI provajder vrati 429, vaš server čeka i pokuša još jednom ili dva puta, pa prikazuje prijateljsku poruku „zauzeti smo, pokušajte ponovo“.

Limiti se proveravaju na serveru. Limit koji postoji samo u pregledaču, na primer onemogućavanje dugmeta posle 30 klikova, može da zaobiđe svako ko direktno poziva vaš API.

Ključni pojmovi

Česte zablude

• „Rate limiting je samo za velike aplikacije.“ I male aplikacije su mete, jer botovi skeniraju ceo internet u potrazi za otvorenim formularima i AI krajnjim tačkama. Cena zloupotrebe ne zavisi od veličine.
• „Dovoljno je sakriti dugme.“ Limiti u pregledaču su ljubaznost, a ne zaštita. Pravi limiti moraju da se sprovode na serveru.
• „Limiti po IP adresi su uvek pravični.“ Mnogo ljudi deli jednu IP adresu, kancelarija, škola ili mobilna mreža. Limiti po korisniku su pravičniji kada su ljudi prijavljeni.
• „429 znači da je servis pokvaren.“ Znači da ga pozivate prečesto. Proverite kod zbog petlji i keširajte rezultate koji se retko menjaju. Pogledajte šta je keširanje.
• „Rate limiting zamenjuje limit potrošnje.“ Koristite oboje. Limiti u vašoj aplikaciji mogu imati greške; limit potrošnje kod provajdera je vaša rezerva.

Šta da tražite od AI alata za pravljenje aplikacija

• „Dodaj rate limiting na serveru za prijavu, registraciju, reset lozinke i AI krajnju tačku. Predloži razumne limite.“
• „Ograniči svakog prijavljenog korisnika na [N] AI zahteva na sat i pokaži jasnu poruku sa vremenom čekanja kada to dostigne.“
• „Kada spoljni API vrati 429, pokušaj ponovo uz eksponencijalno čekanje do 3 puta, pa prikaži prijateljsku grešku.“
• „Gde se čuvaju brojači limita? Hoće li raditi ako aplikacija radi na više mašina?“
• „Beleži kada korisnik ili IP adresa dostigne limit, da mogu da uočim zloupotrebu.“
• „Koje spoljne servise ova aplikacija poziva i koji su njihovi limiti?“

Rate limiting u Mythex-u

Dokumentacija Mythex-a je direktna po tom pitanju za AI funkcije: limiti zahteva, bezbednost i kontrola troškova u aplikacijama koje pravite su vaša odgovornost da ih osmislite. Pogledajte Pravljenje AI aplikacije. Zatražite limite agentu u istoj poruci u kojoj tražite funkciju. U Pro paketu objavljeni servis može da radi na do tri mašine kada je saobraćaj velik (pogledajte Ograničenja hostinga), pa tražite brojače koji žive u bazi, a ne u memoriji jednog servera.

Povezano čitanje: šta je API, kako koristiti LLM API-je i bezbednosna lista za aplikacije pravljene uz AI.

Pitanja