Ի՞նչ է rate limiting-ը։ Պարզ ուղեցույց հավելվածներ կառուցողների համար

Rate limiting-ը կանոն է, որ սահմանափակում է, թե քանի հարցում կարող է անել ինչ-որ մեկը համակարգին տրված ժամանակում։ Օրինակ՝ րոպեում 5 մուտքի փորձ կամ ժամում 100 API կանչ։ Երբ սահմանը լրանում է, հետագա հարցումները մերժվում են (սովորաբար 429 Too Many Requests սխալի կոդով), մինչև ժամանակային պատուհանը չթարմանա։ Այն պաշտպանում է հավելվածները չարաշահումից, թույլ չի տալիս մեկ ծանր օգտատիրոջը բոլորի համար դանդաղեցնել բաները և կանխում է անվերահսկելի ծախսերը։

Rate limiting-ի հետ դուք հանդիպում եք երկու կողմից․ ծառայությունները, որոնք դուք կանչում եք, սահմանափակում են ձեզ, իսկ ձեր սեփական հավելվածը պետք է սահմանափակի իր օգտատերերին։

Ինչու է rate limiting-ը կարևոր AI-ով կառուցելիս

AI-ով կառուցված հավելվածները հաճախ միանում են վճարովի ծառայությունների՝ AI մոդելներ, էլ․ փոստ, SMS, քարտեզներ, և յուրաքանչյուր կանչ արժե փող։ Դրա համար rate limiting-ը միաժամանակ և անվտանգության, և բյուջեի գործիք է։

• Ծախսերի վերահսկում։ Եթե ձեր հավելվածը ունի «հարցրու AI-ին» դաշտ և առանց սահմանի է, բոտը կարող է գիշերվա ընթացքում հազարավոր հարցումներ ուղարկել։ Յուրաքանչյուրի համար դուք վճարում եք։
• Անվտանգություն։ Առանց սահմանի մուտքի ձևի վրա, հարձակվողը կարող է հազարավոր գաղտնաբառեր փորձել մեկ հաշվի համար։ Րոպեում մի քանի փորձի սահմանը դա անիրագործելի է դարձնում։
• Մնալ առցանց։ Մեկ սխալ աշխատող սցենար՝ երբեմն ձեր սեփական կոդը, որը մնացել է անվերջ ցիկլում, կարող է ծանրաբեռնել ձեր տվյալների բազան և անջատել հավելվածը։
• Հարգել այլ ծառայությունների սահմանները։ Երբ ձեր հավելվածը չափազանց հաճախ է կանչում արտաքին API-ն, դուք եք ստանում 429 սխալները, և գործառույթները կոտրվում են ձեր օգտատերերի համար։

AI կառուցողները կկառուցեն այն, ինչ խնդրում եք։ Եթե սահմանների մասին չեք հիշատակում, դրանք հաճախ բաց են թողնվում։

Ամենօրյա անալոգիա

Պատկերացրեք սրճարանի անվճար լրացման քաղաքականությունը․ «Մեկ անվճար լրացում մեկ այցելուի համար»։

• Այն ոչ ոքի չի արգելում սուրճ վայելել։
• Այն կանխում է, որ մեկ մարդը ամբողջ օրը կանգնի գնահատիչի մոտ և բոլոր աշխատակիցների համար լրացնի ֆլասկը։
• Երբ որևէ մեկը չորրորդ լրացում է խնդրում, բարիստան քաղաքավարի ասում է՝ «հիմա չէ» — դա 429-ն է։

Լավ rate limit-ը անտեսանելի է սովորական հաճախորդների համար և նկատվում է միայն անսովոր բան անողի համար։

Ինչպես է աշխատում rate limiting-ը

Rate limiter-ին անհրաժեշտ է երեք բան․

Երբ հարցում է գալիս, հավելվածը ստուգում է այդ «ով»-ի հաշվիչը։ Սահմանից ցածր՝ հարցումն անցնում է և հաշվիչը աճում է։ Սահմանից բարձր՝ հարցումը մերժվում է։

Հաշվելու մի քանի տարածված եղանակ կա․

Հաշվիչները պետք է պահվեն արագ և համօգտագործվող տեղում։ Մեկ փոքր սերվերի վրա հիշողությունը բավական է։ Երբ հավելվածը աշխատում է մի քանի մեքենաների վրա, հաշվիչը սովորաբար ապրում է համօգտագործվող պահոցում, օրինակ՝ Redis-ում կամ տվյալների բազայում, հակառակ դեպքում յուրաքանչյուր մեքենա առանձին է հաշվում, և իրական սահմանը դառնում է մի քանի անգամ բարձր։

Ինչպես է հայտնվում սահմանված հարցումը

Երբ հարցումը սահմանից դուրս է, լավ աշխատող API-ն պատասխանում է․

• Կարգավիճակի կոդ 429 Too Many Requests։
• Հաճախ Retry-After վերնագիր՝ ասելով, քանի վայրկյան սպասել։
• Երբեմն վերնագրեր, որոնք ցույց են տալիս ձեր սահմանը և քանի հարցում է մնացել այս պատուհանում (անունները տարբերվում են մատակարարից կախված)։

Ձեր հավելվածը 429-ին պետք է պատասխանի սպասելով և նորից փորձելով ավելի ուշ՝ նախընտրելիորեն exponential backoff-ով, այսինքն՝ յուրաքանչյուր ձախողված փորձից հետո սպասելով մի փոքր ավելի երկար (1 վայրկյան, հետո 2, հետո 4), այլ ոչ թե ծառայությունը անընդհատ հարվածելով։

Օրինակ՝ AI գրող օգնական

Ենթադրենք, կառուցել եք հավելված, որտեղ օգտատերերը տեքստ են տեղադրում և ստանում AI վերագրում։

Առանց սահմանների․ ինչ-որ մեկը գիշերվա ընթացքում 20,000 հարցում ուղարկող սցենար է գրում։ Ձեր AI մատակարարի հաշիվը բարձրանում է, և ձեր հաշիվը հասնում է մատակարարի սեփական rate limit-ին, ուստի իրական օգտատերերը առավոտյան սխալներ են տեսնում։

Խելամիտ սահմաններով․

1. Յուրաքանչյուր մուտք գործած օգտատիրոջ համար․ 30 վերագրում ժամում անվճար պլանի վրա, 300՝ վճարովի։ Սահմանից դուրս օգտատերը տեսնում է․ «Դուք հասել եք այս ժամվա սահմանին։ Կրկին փորձեք 12 րոպեից կամ անցեք վճարովի պլանի։»
2. Գրանցման ձևի IP հասցեի համար․ 5 գրանցում ժամում, որպեսզի բոտերը չստեղծեն հազարավոր անվճար հաշիվներ՝ օգտատիրոջ սահմանը շրջանցելու համար։
3. Ծախսերի սահման սահմանված ձեր AI մատակարարի վահանակում՝ որպես վերջին պաշտպանական գիծ, եթե մնացածը ձախողվի։
4. Մատակարարի սահմանների հետ աշխատելը․ եթե AI մատակարարը 429 է վերադարձնում, ձեր սերվերը սպասում է և կրկնում մեկ կամ երկու անգամ, ապա ցույց է տալիս բարյացակամ «զբաղված է, խնդրում ենք կրկին փորձել» հաղորդագրություն։

Սահմանները ստուգվում են սերվերի վրա։ Բրաուզերում գոյություն ունեցող սահմանը, օրինակ՝ կոճակը 30 սեղմումից հետո անջատելը, կարող է շրջանցվել ցանկացած մարդու կողմից, ով ուղղակիորեն կանչում է ձեր API-ն։

Բանալի տերմիններ

Տարածված թյուրըմբռնումներ

• «Rate limiting-ը միայն մեծ հավելվածների համար է»։ Փոքր հավելվածները նույնպես թիրախ են, քանի որ բոտերը սկանավորում են ամբողջ ինտերնետը բաց ձևերի և AI վերջնակետերի համար։ Չարաշահման արժեքը կախված չէ ձեր չափից։
• «Բավական է կոճակը թաքցնել»։ Բրաուզերի կողմից սահմանները քաղաքավարություն են, ոչ պաշտպանություն։ Իրական սահմանները պետք է կիրառվեն սերվերի վրա։
• «Յուրաքանչյուր IP սահմանը միշտ արդար է»։ Շատ մարդիկ կարող են կիսել մեկ IP հասցե՝ գրասենյակ, դպրոց, բջջային ցանց։ Օգտատիրոջ սահմանները ավելի արդար են, երբ մարդիկ մուտք են գործած։
• «429-ը նշանակում է, որ ծառայությունը կոտրված է»։ Այն նշանակում է, որ դուք չափազանց հաճախ եք կանչում այն։ Ստուգեք ձեր կոդը ցիկլերի համար և պահեք արդյունքները, որոնք հազվադեպ են փոխվում՝ տե՛ս ինչ է caching-ը։
• «Rate limiting-ը փոխարինում է ծախսերի սահմանին»։ Օգտագործեք երկուսը։ Ձեր հավելվածի սահմանները կարող են սխալներ ունենալ․ մատակարարի ծախսերի սահմանը ձեր պահուստային պաշտպանությունն է։

Ինչ հարցնել ձեր AI կառուցողից

• «Ավելացրու սերվերի կողմից rate limiting մուտքի, գրանցման, գաղտնաբառի վերականգնման և AI վերջնակետի համար։ Առաջարկիր խելամիտ սահմաններ։»
• «Սահմանիր յուրաքանչյուր մուտք գործած օգտատիրոջ համար [N] AI հարցում ժամում և երբ հասնի սահմանին, ցույց տուր հստակ հաղորդագրություն՝ սպասման ժամանակով։»
• «Երբ արտաքին API-ն վերադարձնում է 429, կրկին փորձիր exponential backoff-ով մինչև 3 անգամ, ապա ցույց տուր բարյացակամ սխալ։»
• «Որտե՞ղ են պահվում rate limit հաշվիչները։ Կաշխատեն արդյոք, եթե հավելվածը աշխատի մի քանի մեքենայի վրա։»
• «Գրանցիր, երբ օգտատերը կամ IP հասցեն հասնում է սահմանին, որ կարողանամ նկատել չարաշահումը։»
• «Ո՞ր արտաքին ծառայություններն է այս հավելվածը կանչում և որո՞նք են դրանց rate limit-ները։»

Rate limiting-ը Mythex-ում

Mythex-ի փաստաթղթերը այս մասին ուղիղ են AI գործառույթների համար․ ձեր կառուցած հավելվածների rate limit-ները, անվտանգությունը և ծախսերի վերահսկումը ձերն են որոշելու՝ տե՛ս Կառուցել AI հավելված։ Խնդրեք գործակալին ավելացնել սահմանները նույն հաղորդագրության մեջ, որտեղ խնդրում եք գործառույթը։ Pro պլանում հրապարակված ծառայությունը կարող է աշխատել մինչև երեք մեքենայի վրա, երբ թրաֆիկը մեծ է (տե՛ս Հոսթինգի սահմանները), ուստի խնդրեք հաշվիչներ, որոնք ապրում են տվյալների բազայում, այլ ոչ թե մեկ սերվերի հիշողության մեջ։

Սրան առնչվող ընթերցանություն․ ինչ է API-ն, ինչպես օգտագործել LLM API-ները և անվտանգության ստուգաթերթը AI-ով կառուցված հավելվածների համար։

Հարցեր