Šta je rate limiting? Objašnjenje bez žargona za one koji prave aplikacije

Rate limiting je pravilo koje ograničava koliko zahtjeva neko može poslati sistemu u zadanom vremenu, na primjer 5 pokušaja prijave u minuti ili 100 API poziva na sat. Kad se dostigne limit, daljnji zahtjevi se odbijaju (obično greškom 429 Too Many Requests) dok se vremenski prozor ne resetuje. Štiti aplikacije od zloupotrebe, sprječava da jedan teški korisnik uspori stvari svima i zaustavlja troškove koji izmiču kontroli.

Susrećete se s rate limitingom sa dvije strane: servisi koje pozivate ograničavaju vas, a vaša aplikacija treba ograničavati svoje korisnike.

Zašto je rate limiting važan kad pravite uz AI

Aplikacije napravljene uz AI često se povezuju s plaćenim servisima: AI modeli, e-mail, SMS, mape. Svaki poziv košta novac. Zato je rate limiting i sigurnosna i budžetska funkcija.

• Kontrola troškova. Ako vaša aplikacija ima kutiju „pitaj AI“ i nema limita, bot joj može poslati hiljade zahtjeva preko noći. Plaćate svaki od njih.
• Sigurnost. Bez limita na formi za prijavu, napadač može isprobati hiljade lozinki za jedan nalog. Limit od nekoliko pokušaja u minuti to čini nepraktičnim.
• Ostajanje online. Jedna loša skripta, ponekad i vaš vlastiti kod zaglavljen u petlji, može preopteretiti bazu i srušiti aplikaciju.
• Poštovanje limita drugih servisa. Kad vaša aplikacija prečesto poziva vanjski API, vi dobijete 429 greške, a funkcije se pokvare za vaše korisnike.

AI alati će napraviti ono što tražite. Ako ne spomenete limite, često ih nema.

Analogija iz svakodnevnog života

Zamislite pravilo u kafiću o besplatnom dopunjavanju: „Jedno besplatno dopunjavanje po gostu po posjeti.“

• Ne sprječava nikoga da uživa u kafi.
• Sprječava jednu osobu da stoji na šanku cijeli dan i dopunjava termos za cijeli ured.
• Kad neko zatraži četvrto dopunjavanje, konobar ljubazno kaže „ne sada“. To je 429.

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

Kako rate limiting radi

Rate limiter treba tri stvari:

Kad stigne zahtjev, aplikacija provjeri brojač za taj „ko“. Ako je ispod limita, zahtjev prolazi i brojač raste. Ako je preko limita, zahtjev se odbija.

Postoji nekoliko uobičajenih načina brojanja:

Brojači moraju biti spremljeni na brzom i zajedničkom mjestu. Na jednom malom serveru dovoljna je memorija. Kad aplikacija radi na više mašina, brojač obično živi u zajedničkom skladištu poput Redisa ili baze, inače svaka mašina broji posebno i stvarni limit postaje nekoliko puta veći.

Kako izgleda odgovor kad je limit dostignut

Kad je zahtjev preko limita, dobro ponašan API odgovara s:

• Statusnim kodom 429 Too Many Requests.
• Često zaglavljem Retry-After, koje kaže koliko sekundi treba čekati.
• Ponekad zaglavljima koja pokazuju vaš limit i koliko zahtjeva vam je ostalo u ovom prozoru (nazivi variraju od provajdera do provajdera).

Vaša aplikacija treba na 429 odgovoriti čekanjem i ponovnim pokušajem kasnije, idealno s eksponencijalnim backoffom, što znači da se čeka malo duže nakon svakog neuspjelog pokušaja (1 sekunda, pa 2, pa 4), umjesto da se servis bombarduje.

Radni primjer: AI asistent za pisanje

Recimo da ste napravili aplikaciju u kojoj korisnici nalijepe tekst i dobiju AI prepis.

Bez limita: neko napiše skriptu koja pošalje 20.000 zahtjeva preko noći. Račun vašeg AI provajdera naraste, a vaš nalog dostigne vlastiti rate limit provajdera, pa pravi korisnici cijelo jutro vide greške.

Uz razumne limite:

1. Po prijavljenom korisniku: 30 prepisa 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 formi 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 kontrolnoj tabli vašeg AI provajdera, kao posljednja linija odbrane ako sve ostalo zakaže.
4. Rukovanje limitima provajdera: ako AI provajder vrati 429, vaš server čeka i pokuša još jednom ili dva puta, pa prikaže prijateljsku poruku „zauzeti smo, pokušajte ponovo“.

Limiti se provjeravaju na serveru. Limit koji postoji samo u pregledaču, na primjer onemogućavanje dugmeta nakon 30 klikova, može zaobići svako ko direktno zove vaš API.

Ključni pojmovi

Česte zablude

• „Rate limiting je samo za velike aplikacije.“ Male aplikacije su također mete, jer botovi skeniraju cijeli internet tražeći otvorene forme i AI krajnje tačke. Cijena zloupotrebe ne zavisi od vaše veličine.
• „Dovoljno je sakriti dugme.“ Limiti u pregledaču su ljubaznost, a ne zaštita. Pravi limiti moraju se provoditi na serveru.
• „Limiti po IP adresi su uvijek pošteni.“ Mnogo ljudi dijeli jednu IP adresu: kancelarija, škola, mobilna mreža. Limiti po korisniku su pošteniji kad su ljudi prijavljeni.
• „429 znači da je servis pokvaren.“ Znači da ga pozivate prečesto. Provjerite kod za petlje i keširajte rezultate koji se rijetko mijenjaju, pogledajte šta je keširanje.
• „Rate limiting zamjenjuje limit potrošnje.“ Koristite oboje. Limiti u vašoj aplikaciji mogu imati greške; limit potrošnje kod provajdera je vaša rezerva.

Šta tražiti od vašeg AI alata

• „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 zahtjeva na sat i prikaži jasnu poruku s vremenom čekanja kad ga dostigne.“
• „Kad vanjski API vrati 429, pokušaj ponovo s eksponencijalnim backoffom do 3 puta, pa prikaži prijateljsku grešku.“
• „Gdje se čuvaju brojači rate limita? Hoće li raditi ako aplikacija radi na više mašina?“
• „Bilježi svaki put kad korisnik ili IP dostigne limit, da mogu uočiti zloupotrebu.“
• „Koje vanjske servise ova aplikacija poziva i koji su njihovi rate limiti?“

Rate limiting u Mythexu

Dokumentacija Mythexa je direktna po ovom pitanju za AI funkcije: rate limitima, sigurnosti i kontroli troškova u aplikacijama koje pravite upravljate vi. Pogledajte Izgradnju AI aplikacije. Zatražite limite u istoj poruci u kojoj tražite funkciju. Na Pro paketu objavljeni servis može raditi na do tri mašine kad je saobraćaj velik (pogledajte ograničenja hostinga), pa tražite brojače koji žive u bazi, a ne u memoriji jednog servera.

Srodno štivo: šta je API, kako koristiti LLM API-je i kontrolna lista sigurnosti za aplikacije napravljene uz AI.

Pitanja