Što je ograničavanje brzine (rate limiting)? Jednostavan vodič za graditelje aplikacija

Rate limiting je pravilo koje ograničava koliko zahtjeva netko može poslati sustavu u zadanom vremenu, na primjer 5 pokušaja prijave u minuti ili 100 poziva API-ja na sat. Kad se dosegne ograničenje, daljnji zahtjevi se odbijaju (obično s kodom greške 429 Too Many Requests) dok se vremenski prozor ne resetira. Štiti aplikacije od zloupotrebe, sprječava da jedan zahtjevan korisnik uspori sve ostale i zaustavlja nekontrolirane troškove.

S rate limitingom se susrećete s dvije strane: usluge koje zovete ograničavaju vas, a vaša aplikacija trebala bi ograničavati svoje korisnike.

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

Aplikacije izrađene uz AI često se povezuju s plaćenim uslugama (AI modeli, e-pošta, SMS, karte), a svaki poziv košta novac. Zato je rate limiting i sigurnosna značajka i značajka za kontrolu budžeta.

• Kontrola troškova. Ako vaša aplikacija ima okvir „pitaj AI“ bez ograničenja, bot joj može poslati tisuće zahtjeva preko noći. Platite svaki od njih.
• Sigurnost. Bez ograničenja na obrascu za prijavu napadač može isprobati tisuće lozinki za jedan račun. Ograničenje od nekoliko pokušaja u minuti to čini nepraktičnim.
• Ostajanje online. Jedna loše ponašajuća skripta, a ponekad i vaš vlastiti kod zaglavljen u petlji, može preopteretiti bazu podataka i srušiti aplikaciju.
• Poštivanje ograničenja drugih servisa. Kad vaša aplikacija prečesto zove vanjski API, vi dobijete greške 429, a funkcije pokvare vašim korisnicima.

Alati za izradu s AI-jem izgradit će ono što tražite. Ako ne spomenete ograničenja, često ih ni ne bude.

Svakodnevna usporedba

Zamislite pravilo besplatnog dopunjavanja kave u kafiću: „Jedno besplatno dopunjavanje po gostu po posjetu.“

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

Dobro ograničenje je nevidljivo običnim gostima i primijeti ga samo netko tko radi nešto neobično.

Kako rate limiting radi

Ograničavač treba tri stvari:

Kad stigne zahtjev, aplikacija provjeri brojač za taj „tko“. Ispod ograničenja: zahtjev prolazi i brojač raste. Iznad ograničenja: zahtjev se odbija.

Postoji nekoliko uobičajenih načina brojanja:

Brojači moraju biti spremljeni negdje brzo i zajednički. Na jednom malom serveru dovoljna je memorija. Kad aplikacija radi na više strojeva, brojač obično živi u zajedničkoj pohrani poput Redisa ili baze podataka, inače svaki stroj broji zasebno i stvarno ograničenje postane nekoliko puta veće.

Kako izgleda odgovor kad je ograničenje prekoračeno

Kad je zahtjev iznad ograničenja, dobro ponašan API odgovara:

• Statusom 429 Too Many Requests.
• Često zaglavljem Retry-After koje kaže koliko sekundi treba čekati.
• Ponekad zaglavljima koja pokazuju vaše ograničenje i koliko zahtjeva vam je ostalo u ovom prozoru (nazivi variraju ovisno o pružatelju).

Vaša aplikacija treba na 429 odgovoriti čekanjem i ponovnim pokušajem kasnije, idealno s eksponencijalnim čekanjem (exponential backoff), što znači da čeka sve duže nakon svakog neuspjelog pokušaja (1 sekundu, pa 2, pa 4), umjesto da bombardira uslugu.

Primjer na djelu: AI asistent za pisanje

Recimo da ste izradili aplikaciju u kojoj korisnici zalijepe tekst i dobiju AI prepisivanje.

Bez ograničenja: netko napiše skriptu koja preko noći pošalje 20.000 zahtjeva. Račun vašeg AI pružatelja naraste, a vaš račun dosegne ograničenje samog pružatelja pa stvarni korisnici cijelo jutro vide greške.

S razumnim ograničenjima:

1. Po prijavljenom korisniku: 30 prepisivanja na sat u besplatnom planu, 300 u plaćenom. Iznad ograničenja korisnik vidi: „Dosegnuli ste ograničenje za ovaj sat. Pokušajte za 12 minuta ili nadogradite.“
2. Po IP adresi na obrascu za registraciju: 5 registracija na sat, da botovi ne bi stvarali tisuće besplatnih računa i zaobišli ograničenje po korisniku.
3. Ograničenje potrošnje postavljeno u nadzornoj ploči vašeg AI pružatelja, kao zadnja linija obrane ako sve ostalo zakaže.
4. Rukovanje ograničenjima pružatelja: ako AI pružatelj vrati 429, vaš server čeka i pokuša ponovno jednom ili dvaput, a zatim prikaže prijateljsku poruku „zauzeto, pokušajte ponovno“.

Ograničenja se provjeravaju na serveru. Ograničenje koje postoji samo u pregledniku, primjerice onemogućavanje gumba nakon 30 klikova, može zaobići svatko tko izravno zove vaš API.

Ključni pojmovi

Česte zablude

• „Rate limiting je samo za velike aplikacije.“ I male aplikacije su mete, jer botovi skeniraju cijeli internet tražeći otvorene obrasce i AI krajnje točke. Trošak zloupotrebe ne ovisi o vašoj veličini.
• „Dovoljno je sakriti gumb.“ Ograničenja na strani preglednika su ljubaznost, a ne zaštita. Stvarna ograničenja moraju se provoditi na serveru.
• „Ograničenja po IP adresi su uvijek pravedna.“ Mnogo ljudi može dijeliti jednu IP adresu: ured, školu, mobilnu mrežu. Ograničenja po korisniku pravednija su kad su ljudi prijavljeni.
• „429 znači da je usluga pokvarena.“ Znači da je zovete prečesto. Provjerite ima li vaš kod petlje i predmemorirajte rezultate koji se rijetko mijenjaju. Pogledajte što je predmemoriranje.
• „Rate limiting zamjenjuje ograničenje potrošnje.“ Koristite oboje. Ograničenja u vašoj aplikaciji mogu imati greške; ograničenje potrošnje kod pružatelja vaša je zadnja zaštita.

Što tražiti od AI alata za izradu aplikacija

• „Dodaj ograničavanje brzine na poslužiteljskoj strani za prijavu, registraciju, reset lozinke i AI krajnju točku. Predloži razumna ograničenja.“
• „Ograniči svakog prijavljenog korisnika na [N] AI zahtjeva na sat i prikaži jasnu poruku s vremenom čekanja kad to dosegne.“
• „Kad vanjski API vrati 429, pokušaj ponovno s eksponencijalnim čekanjem do 3 puta, a zatim prikaži prijateljsku poruku o grešci.“
• „Gdje se spremaju brojači ograničenja? Hoće li raditi ako aplikacija radi na više strojeva?“
• „Zapiši kad korisnik ili IP adresa dosegne ograničenje, da mogu uočiti zloupotrebu.“
• „Koje vanjske usluge ova aplikacija zove i koja su njihova ograničenja?“

Rate limiting u Mythexu

Dokumentacija Mythexa jasna je oko ovoga za AI značajke: ograničenja brzine, sigurnosne i troškovne kontrole u aplikacijama koje izrađujete su vaša stvar i vi ih dizajnirate. Pogledajte Izradi AI aplikaciju. Zatražite ograničenja u istoj poruci u kojoj tražite značajku. Na Pro planu objavljena usluga može raditi na do tri stroja kad je promet velik (pogledajte ograničenja hostinga), pa tražite brojače koji žive u bazi podataka, a ne u memoriji jednog servera.

Srodno čitanje: što je API, kako koristiti LLM API-je i sigurnosna lista za aplikacije izrađene uz AI.

Pitanja