Co je rate limiting? Srozumitelný průvodce pro tvůrce aplikací

Rate limiting je pravidlo, které omezuje, kolik požadavků může někdo odeslat systému za daný čas, například 5 pokusů o přihlášení za minutu nebo 100 volání API za hodinu. Jakmile se limit vyčerpá, další požadavky se odmítnou (obvykle s chybovým kódem 429 Too Many Requests), dokud se časové okno neobnoví. Chrání aplikace před zneužitím, zabrání tomu, aby jeden náročný uživatel zpomalil věci všem, a brání nekontrolovatelným nákladům.

S rate limitingem se setkáte ze dvou stran: služby, které voláte, omezují vás, a vaše vlastní aplikace by měla omezovat své uživatele.

Proč na rate limitingu záleží, když stavíte s AI

Aplikace postavené pomocí AI se často napojují na placené služby (modely AI, e-mail, SMS, mapy) a každé volání stojí peníze. Rate limiting je tak zároveň bezpečnostní funkce i funkce pro kontrolu rozpočtu.

• Kontrola nákladů. Pokud má vaše aplikace políčko „zeptej se AI“ a žádný limit, bot jí přes noc může poslat tisíce požadavků. Zaplatíte za každý z nich.
• Bezpečnost. Bez limitu na přihlašovacím formuláři může útočník zkoušet tisíce hesel u jednoho účtu. Limit několika pokusů za minutu to dělá nepraktickým.
• Zůstat online. Jeden špatně se chovající skript, někdy i váš vlastní kód zaseknutý v cyklu, může přetížit databázi a shodit aplikaci.
• Respektovat limity jiných služeb. Když vaše aplikace volá externí API příliš často, dostáváte chyby 429 vy a funkce přestanou fungovat vašim uživatelům.

Tvůrci aplikací s AI postaví to, co požadujete. Pokud o limitech nezmíníte, často zůstanou nedotčené.

Každodenní přirovnání

Představte si pravidlo kavárny pro bezplatné dolévání: „Jedno bezplatné dolití na zákazníka a návštěvu.“

• Nikomu nebrání v tom, aby si kávu užil.
• Brání jednomu člověku, aby celý den stál u pultu a dolíval termosku pro celou kancelář.
• Když někdo požádá o čtvrté dolití, barista zdvořile řekne „zrovna ne“. To je ten 429.

Dobrý limit je pro běžné zákazníky neviditelný a všimne si ho jen ten, kdo dělá něco neobvyklého.

Jak rate limiting funguje

Omezovač potřebuje tři věci:

Když dorazí požadavek, aplikace zkontroluje počet pro dané „kdo“. Pod limitem: požadavek projde a počet se zvýší. Nad limitem: požadavek se odmítne.

Existuje několik běžných způsobů počítání:

Počty je třeba ukládat na rychlé a sdílené místo. Na jednom malém serveru stačí paměť. Jakmile aplikace běží na několika strojích, počítadlo obvykle žije ve sdíleném úložišti, jako je Redis nebo databáze. Jinak každý stroj počítá zvlášť a skutečný limit je několikanásobně vyšší.

Jak vypadá odpověď s omezením

Když je požadavek nad limitem, dobře navržené API odpoví:

• Stavovým kódem 429 Too Many Requests.
• Často hlavičkou Retry-After, která říká, kolik sekund počkat.
• Někdy hlavičkami, které ukazují váš limit a kolik požadavků vám v tomto okně zbývá (názvy se u poskytovatelů liší).

Vaše aplikace by měla na 429 reagovat čekáním a pozdějším opakováním, ideálně s exponenciálním ústupem (exponential backoff). To znamená čekat po každém neúspěšném pokusu o něco déle (1 sekundu, pak 2, pak 4), místo aby službu bombardovala.

Praktický příklad: asistent pro psaní s AI

Řekněme, že jste postavili aplikaci, kde uživatelé vloží text a dostanou přepis od AI.

Bez limitů: někdo napíše skript, který přes noc odešle 20 000 požadavků. Účet u poskytovatele AI vyskočí a váš účet narazí na vlastní rate limit poskytovatele, takže skuteční uživatelé celé dopoledne vidí chyby.

Se rozumnými limity:

1. Na přihlášeného uživatele: 30 přepisů za hodinu v bezplatném tarifu, 300 v placeném. Nad limit uživatel uvidí: „Dosáhli jste limitu pro tuto hodinu. Zkuste to znovu za 12 minut, nebo si upgradujte.“
2. Na IP adresu ve formuláři registrace: 5 registrací za hodinu, aby boti nezakládali tisíce bezplatných účtů a neobešli limit na uživatele.
3. Limit výdajů nastavený v administraci vašeho poskytovatele AI jako poslední obrana, kdyby selhalo všechno ostatní.
4. Řešení limitů poskytovatele: pokud poskytovatel AI vrátí 429, váš server počká a zkusí to znovu jednou nebo dvakrát, a pak zobrazí přátelskou zprávu „služba je vytížená, zkuste to prosím znovu“.

Limity se kontrolují na serveru. Limit, který existuje jen v prohlížeči, například vypnutí tlačítka po 30 kliknutích, může obejít kdokoli, kdo volá vaše API přímo.

Klíčové pojmy

Časté mylné představy

• „Rate limiting je jen pro velké aplikace.“ Malé aplikace jsou také cíle, protože boti prohledávají celý internet kvůli otevřeným formulářům a koncovým bodům AI. Náklady zneužití nezávisí na vaší velikosti.
• „Stačí schovat tlačítko.“ Limity v prohlížeči jsou zdvořilost, ne ochrana. Skutečné limity musí být vynuceny na serveru.
• „Limity podle IP jsou vždy spravedlivé.“ Mnoho lidí může sdílet jednu IP adresu, třeba kancelář, školu nebo mobilní síť. Jakmile jsou lidé přihlášeni, jsou limity na uživatele spravedlivější.
• „Chyba 429 znamená, že služba je rozbitá.“ Znamená, že ji voláte příliš často. Zkontrolujte svůj kód kvůli cyklům a ukládejte do mezipaměti výsledky, které se často nemění. Viz co je caching.
• „Rate limiting nahrazuje limit výdajů.“ Používejte obojí. Limity ve vaší aplikaci mohou mít chyby; limit výdajů u poskytovatele je vaše záložní pojistka.

Na co se ptát svého AI nástroje

• „Přidej rate limiting na serveru pro přihlášení, registraci, obnovu hesla a koncový bod AI. Navrhni rozumné limity.“
• „Omez každého přihlášeného uživatele na [N] požadavků AI za hodinu a když ho dosáhne, zobraz jasnou zprávu s dobou čekání.“
• „Když externí API vrátí 429, zkus to znovu s exponenciálním ústupem až třikrát a pak zobraz přátelskou chybu.“
• „Kde se ukládají počítadla limitů? Budou fungovat, když aplikace poběží na více než jednom stroji?“
• „Zaznamenej, kdykoli uživatel nebo IP narazí na limit, abych mohl odhalit zneužití.“
• „Které externí služby tato aplikace volá a jaké mají limity?“

Rate limiting v Mythexu

Dokumentace Mythexu je k tomu u funkcí AI přímá: limity, bezpečnost a kontrola nákladů v aplikacích, které stavíte, jsou na vás, aby je navrhnete. Viz Vytvořte aplikaci s AI. Požádejte agenta o limity ve stejné zprávě, ve které žádáte o funkci. V tarifu Pro může publikovaná služba při velkém provozu běžet až na třech strojích (viz limity hostingu), takže si řekněte o počítadla uložená v databázi, a ne v paměti jednoho serveru.

Související čtení: co je API, jak používat LLM API a bezpečnostní kontrolní seznam pro aplikace postavené pomocí AI.

Otázky