რა არის Rate Limiting? მარტივი გზამკვლევი აპების შემქმნელებისთვის
Rate limiting არის წესი, რომელიც ზღუდავს, რამდენი მოთხოვნა შეუძლია ვინმეს სისტემისთვის გააკეთოს დროის გარკვეულ მონაკვეთში — მაგალითად, 5 შესვლის მცდელობა წუთში ან 100 API გამოძახება საათში. ლიმიტის მიღწევის შემდეგ შემდგომი მოთხოვნები უარყოფილია (ჩვეულებრივ შეცდომის კოდით 429 Too Many Requests), სანამ დროის ფანჯარა არ განახლდება. ის იცავს აპებს ბოროტად გამოყენებისგან, ხელს უშლის, რომ ერთმა მძიმე მომხმარებელმა ყველას შეანელოს, და აჩერებს არაკონტროლირებად ხარჯებს.
რate limiting ორი მხრიდან შეგხვდებათ: სერვისები, რომლებსაც თქვენ იძახებთ, ზღუდავენ თქვენ, ხოლო თქვენი საკუთარი აპი უნდა ზღუდავდეს თავის მომხმარებლებს.
რატომ არის rate limiting მნიშვნელოვანი AI-ით აპების შექმნისას
AI-ით აშენებული აპები ხშირად უკავშირდება ფასიან სერვისებს — AI მოდელებს, ელფოსტას, SMS-ს, რუკებს — და ყოველი გამოძახება ფულს ჯდება. ამიტომ rate limiting არის როგორც უსაფრთხოების, ისე ბიუჯეტის ფუნქცია.
- ხარჯების კონტროლი. თუ თქვენს აპში არის „ჰკითხე AI-ს“ ველი და ლიმიტი არ არის, ბოტმა ღამით ათასობით მოთხოვნა შეიძლება გაგზავნოს. თითოეულს თქვენ იხდით.
- უსაფრთხოება. შესვლის ფორმაზე ლიმიტის გარეშე შემტევს შეუძლია ათასობით პაროლი სცადოს ერთ ანგარიშზე. წუთში რამდენიმე მცდელობის ლიმიტი ამას არაპრაქტიკულს ხდის.
- ონლაინ დარჩენა. ერთმა არასწორად მომუშავე სკრიპტმა — ზოგჯერ თქვენმავე კოდმა, რომელიც ციკლში ჩარჩა — შეიძლება მონაცემთა ბაზა გადატვირთოს და აპი გათიშოს.
- სხვა სერვისების ლიმიტების პატივისცემა. როცა თქვენი აპი გარე API-ს ძალიან ხშირად იძახებს, თქვენ იღებთ 429 შეცდომებს და თქვენი მომხმარებლებისთვის ფუნქციები ირღვევა.
AI შემქმნელები ზუსტად იმას ააშენებენ, რასაც სთხოვთ. თუ ლიმიტებს არ ახსენებთ, ისინი ხშირად გამორჩებიან.
ყოველდღიური ანალოგია
წარმოიდგინეთ კაფეს უფასო დანამატის წესი: „ერთი უფასო დანამატი მომხმარებელზე ვიზიტში.“
- ის არავის ართმევს ყავის სიამოვნებას.
- ის აჩერებს ერთ ადამიანს, რომელიც მთელი დღე დაუსრულებლად ავსებს თერმოსს მთელი ოფისისთვის.
- როცა ვინმე მეოთხე დანამატს ითხოვს, ბარისტა თავაზიანად ეუბნება „ახლა არა“ — ეს არის
429.
კარგი ლიმიტი ჩვეულებრივი მომხმარებლისთვის უხილავია და მხოლოდ უჩვეულო ქცევას ამჩნევს.
როგორ მუშაობს rate limiting
Rate limiter სამ რამეს საჭიროებს:
| ნაწილი | რა კითხვას პასუხობს | მაგალითები |
|---|---|---|
| ვინ | ვისი მოთხოვნები ითვლება? | მომხმარებლის ანგარიში, IP მისამართი, API გასაღები |
| რამდენი | რა არის ლიმიტი? | 5, 60, 1 000 მოთხოვნა |
| რა დროში | რა ფანჯარაში? | წამში, წუთში, საათში, დღეში |
მოთხოვნის მოსვლისას აპი ამ „ვინის“ დათვლას ამოწმებს. ლიმიტში ყოფნისას მოთხოვნა გადის და დათვლა იზრდება. ლიმიტის გადაჭარბებისას მოთხოვნა უარყოფილია.
დათვლის რამდენიმე გავრცელებული გზა არსებობს:
| მეთოდი | როგორ მუშაობს | კომპრომისი |
|---|---|---|
| ფიქსირებული ფანჯარა | დათვლა საათის მიხედვით ნულდება — მაგალითად, ყოველი წუთის დასაწყისში | მარტივია, მაგრამ ორი ფანჯრის საზღვარზე აძლევს მოკლე აფეთქებას |
| მოცურებადი ფანჯარა | ყურადღება ეთმობა ბოლო 60 წამს ახლიდან | უფრო გლუვია, გამოთვლა ოდნავ მეტ სამუშაოს მოითხოვს |
| Token bucket | თითოეულ მომხმარებელს აქვს ვედრო, რომელიც მუდმივი სიჩქარით ივსება; თითო მოთხოვნა ერთ ტოკენს იღებს | საშუალებას იძლევა მოკლე აფეთქებებს, საშუალო სიჩქარე კი სტაბილურია |
დათვლები სწრაფ და საერთო საცავში უნდა ინახებოდეს. ერთ პატარა სერვერზე მეხსიერება საკმარისია. როცა აპი რამდენიმე მანქანაზე მუშაობს, მრთველი ჩვეულებრივ Redis-ის ან მონაცემთა ბაზის მსგავს საერთო საცავში ცხოვრობს — წინააღმდეგ შემთხვევაში თითოეული მანქანა ცალკე ითვლის და რეალური ლიმიტი რამდენჯერმე მაღლდება.
როგორ გამოიყურება ლიმიტირებული პასუხი
როცა მოთხოვნა ლიმიტს სცდება, კეთილსინდისიერი API ასე პასუხობს:
- სტატუსის კოდი
429 Too Many Requests. - ხშირად
Retry-Afterსათაური, რომელიც მიუთითებს, რამდენი წამი უნდა დაელოდოთ. - ზოგჯერ სათაურები, რომლებიც აჩვენებს თქვენს ლიმიტს და იმას, რამდენი მოთხოვნა დარჩა ამ ფანჯარაში (სახელები პროვაიდერის მიხედვით განსხვავდება).
თქვენმა აპმა 429-ზე უნდა დაიცადოს და მოგვიანებით ხელახლა სცადოს — იდეალურად exponential backoff-ით, რაც ნიშნავს, რომ ყოველი წარუმატებელი მცდელობის შემდეგ უფრო დიდხანს ელოდება (1 წამი, მერე 2, მერე 4), ვიდრე სერვისს ეჯახება.
სამუშაო მაგალითი: AI წერის ასისტენტი
ვთქვათ, აშენებთ აპს, სადაც მომხმარებლები აკოპირებენ ტექსტს და AI-სგან გადაწერილს იღებენ.
ლიმიტების გარეშე: ვინმე ღამით სკრიპტს უშვებს, რომელიც 20 000 მოთხოვნას აგზავნის. თქვენი AI პროვაიდერის ანგარიში იზრდება და თქვენი ანგარიში პროვაიდერის საკუთარ ლიმიტს ეჯახება, ამიტომ ნამდვილი მომხმარებლები დილის განმავლობაში შეცდომებს ხედავენ.
გონივრული ლიმიტებით:
- შესული მომხმარებლის მიხედვით: 30 გადაწერა საათში უფასო გეგმაზე, 300 ფასიანზე. ლიმიტის გადაჭარბებისას მომხმარებელი ხედავს: „ამ საათის ლიმიტი ამოიწურა. სცადეთ 12 წუთში ან გააუმჯობესეთ გეგმა.“
- IP მისამართის მიხედვით რეგისტრაციის ფორმაზე: 5 რეგისტრაცია საათში, რომ ბოტებმა ათასობით უფასო ანგარიში არ შექმნან მომხმარებელზე ლიმიტის გვერდის ასავლელად.
- ხარჯის ზღვარი თქვენი AI პროვაიდერის დაფაზე, როგორც ბოლო ხაზი, თუ ყველაფერი სხვა ვერ შეიკავებს.
- პროვაიდერის ლიმიტების დამუშავება: თუ AI პროვაიდერი 429-ს აბრუნებს, თქვენი სერვერი ერთი ან ორჯერ ელოდება და ხელახლა ცდილობს, შემდეგ კი აჩვენებს მეგობრულ შეტყობინებას „ბოლოს, სცადეთ ხელახლა“.
ლიმიტები სერვერზე მოწმდება. ლიმიტი, რომელიც მხოლოდ ბრაუზერში არსებობს — მაგალითად, ღილაკის გათიშვა 30 დაწკაპუნების შემდეგ — ნებისმიერს შეუძლია გვერდი აუაროს, ვინც თქვენს API-ს პირდაპირ იძახებს.
ძირითადი ტერმინები
| ტერმინი | მნიშვნელობა |
|---|---|
| Rate limit | მაქსიმალური მოთხოვნები, დაშვებული დროის ფანჯარაში. |
| Quota | უფრო დიდი ზღვარი, ხშირად დღის ან თვის მიხედვით, ზოგჯერ ფასიან გეგმასთან დაკავშირებული. |
| 429 | HTTP სტატუსის კოდი „ძალიან ბევრი მოთხოვნა“. |
| Retry-After | პასუხის სათაური, რომელიც მიუთითებს, რამდენი ხანი უნდა დაელოდოთ ხელახლა ცდამდე. |
| Throttling | შენელება ან უარყოფა ლიმიტის გადაჭარბებულ მოთხოვნებზე. ხშირად სინონიმად იხმარება. |
| Exponential backoff | თანდათან უფრო გრძელი ლოდინი ხელახალ ცდებს შორის. |
| Burst | მოკლე ზვავი ბევრი მოთხოვნისა ერთდროულად. |
| Brute-force შეტევა | ათასობით პაროლის ან კოდის ცდა, სანამ ერთი არ იმუშავებს. |
გავრცელებული მცდარი წარმოდგენები
- „Rate limiting მხოლოდ დიდი აპებისთვისაა.“ პატარა აპებიც სამიზნეა, რადგან ბოტები მთელ ინტერნეტს სკანირებენ ღია ფორმებისა და AI endpoint-ების საძებნელად. ბოროტად გამოყენების ღირებულება თქვენს ზომაზე არ არის დამოკიდებული.
- „ღილაკის დამალვა საკმარისია.“ ბრაუზერის მხარეს ლიმიტები სიკეთეა, დაცვა არა. ნამდვილი ლიმიტები სერვერზე უნდა მოქმედებდეს.
- „IP-ის მიხედვით ლიმიტები ყოველთვის სამართლიანია.“ ბევრი ადამიანი შეიძლება ერთ IP მისამართს იზიარებდეს — ოფისი, სკოლა, მობილური ქსელი. შესულ ადამიანებზე მომხმარებლის მიხედვით ლიმიტი უფრო სამართლიანია.
- „429 ნიშნავს, რომ სერვისი გატყდა.“ ნიშნავს, რომ მას ძალიან ხშირად იძახებთ. შეამოწმეთ კოდი ციკლებზე და ქეშირება გაუკეთეთ შედეგებს, რომლებიც ხშირად არ იცვლება — იხილეთ რა არის ქეშირება.
- „Rate limiting ხარჯის ზღვარს ანაცვლებს.“ გამოიყენეთ ორივე. აპის ლიმიტებს შეიძლება ხარვეზი ჰქონდეს; პროვაიდერის ხარჯის ზღვარი თქვენი სარეზერვო დაცვაა.
რა სთხოვოთ თქვენს AI შემქმნელს
- „დაამატე სერვერის მხარეს rate limiting შესვლაზე, რეგისტრაციაზე, პაროლის აღდგენაზე და AI endpoint-ზე. შემოგვთავაზე გონივრული ლიმიტები.“
- „შეზღუდე ყოველი შესული მომხმარებელი [N] AI მოთხოვნით საათში და ლიმიტის მიღწევისას აჩვენე ნათელი შეტყობინება დაცდის დროით.“
- „როცა გარე API 429-ს აბრუნებს, ხელახლა სცადე exponential backoff-ით მაქსიმუმ 3-ჯერ, შემდეგ აჩვენე მეგობრული შეცდომა.“
- „სად ინახება rate-limit დათვლები? იმუშავებს თუ არა ისინი, თუ აპი რამდენიმე მანქანაზე გაეშვება?“
- „ჩაწერე ყოველ ჯერზე, როცა მომხმარებელი ან IP ლიმიტს ეჯახება, რომ ბოროტად გამოყენება დავინახო.“
- „რომელ გარე სერვისებს იძახებს ეს აპი და რა ლიმიტები აქვთ მათ?“
Rate limiting Mythex-ში
Mythex-ის დოკუმენტაცია ამაზე პირდაპირია AI ფუნქციებისთვის: rate limits, უსაფრთხოება და ხარჯების კონტროლი თქვენს მიერ აშენებულ აპებში თქვენი ამოცანაა — იხილეთ AI აპის აშენება. ლიმიტების დამატება მოითხოვეთ აგენტისთვის იმავე შეტყობინებაში, სადაც ფუნქციას ითხოვთ. Pro-ზე გამოქვეყნებული სერვისი მძიმე ტრაფიკისას შეიძლება სამ მანქანაზე გაეშვას (იხილეთ ჰოსტინგის ლიმიტები), ამიტომ მოითხოვეთ მთვლელები, რომლებიც მონაცემთა ბაზაში ინახება და არა ერთი სერვერის მეხსიერებაში.
დაკავშირებული წაკითხვა: რა არის API, როგორ გამოვიყენოთ LLM API-ები და უსაფრთხოების ჩამონათვალი AI-ით აშენებული აპებისთვის.
კითხვები
რა არის rate limiting მარტივად რომ ვთქვათ?
Rate limiting არის წესი, რომელიც ზღუდავს, რამდენი მოთხოვნა შეუძლია მომხმარებელს, მოწყობილობას ან აპს გარკვეულ პერიოდში — მაგალითად, 5 შესვლის მცდელობა წუთში ან 100 API გამოძახება საათში. ლიმიტის გადაჭარბებული მოთხოვნები უარყოფილია, სანამ ფანჯარა არ განახლდება.
რას ნიშნავს 429 Too Many Requests შეცდომა?
HTTP სტატუსი 429 ნიშნავს, რომ ძალიან ბევრი მოთხოვნა გაგზავნეთ მოკლე დროში და მიაღწიეთ rate limit-ს. პასუხში ხშირად არის Retry-After სათაური, რომელიც მიუთითებს, რამდენი ხანი უნდა დაელოდოთ. გამოსავალია შენელება, პაუზის შემდეგ ხელახლა ცდა, ან იმის შემცირება, თუ რამდენად ხშირად აპი იძახებს სერვისს.
რატომ სჭირდება ჩემს AI-ზე დაფუძნებულ აპს rate limiting?
ყოველი AI მოთხოვნა ხარჯს ნიშნავს ტოკენებში. ლიმიტის გარეშე ერთმა მომხმარებელმა ან ბოტმა შეიძლება ათასობით მოთხოვნა გაგზავნოს, დიდი ანგარიში დააგროვოს ან პროვაიდერის კვოტა ამოწუროს, რაც ფუნქციას ყველასთვის გათიშავს. მომხმარებელზე ლიმიტები ხარჯებს წინასწარ განჭვრეტადს ხდის.
rate limiting იგივეა, რაც throttling?
ისინი მჭიდროდ დაკავშირებულია და ხშირად ერთმანეთის ნაცვლად იხმარება. Rate limiting ჩვეულებრივ ნიშნავს ლიმიტს გადაჭარბებული მოთხოვნების უარყოფას, ხოლო throttling შეიძლება ნიშნავდეს მათ შენელებას ან რიგში დაყენებას პირდაპირი უარის ნაცვლად.
rate limiting აჩერებს DDoS შეტევებს?
ეხმარება პატარა დატვირთვებისა და ინდივიდუალური მომხმარებლების ან IP მისამართების ბოროტად გამოყენებისგან, მაგრამ დიდი განაწილებული შეტევა ბევრი მისამართიდან ერთდროულად მოდის. ასეთი შეტევისგან დაცვა ჩვეულებრივ ქსელის ან CDN დონეზე ხდება, სანამ ტრაფიკი თქვენს აპამდე მიაღწევს.