ჩვენ საკუთარ სერვისებს ვზღუდავდით
Mythex-ის API წუთში ერთ ქსელურ მისამართს 300 მოთხოვნას უშვებს. ეს ლიმიტი იმისთვისაა, რომ API დაიცვას ერთმა ადამიანმა ან სკრიპტმა, რომელიც მას ბომბავს. წარმოებაში ის უარს ამბობდა ჩვენს საკუთარ სერვისებზე — ედჟის ნაწილზე, რომელიც გამოქვეყნებულ აპებს ემსახურება, და სერვისზე, რომელიც AI აგენტს უშვებს — რადგან თითოეული მათგანი API-ს მხოლოდ რამდენიმე მისამართიდან აწვდის მოთხოვნებს. ახლა შიდა კრედენციალით მოსული მოთხოვნები ლიმიტს არ ექვემდებარება, ყველა სხვა კი ზუსტად ისევე იზღუდება, როგორც აქამდე.
სიმპტომი
API-მ ზოგიერთ ჩვენს შიდა გამოძახებას 429 Too Many Requests-ით უპასუხა. სამი სახის გამოძახებას შეხვდა, და თითოეულს მნიშვნელობა აქვს იმისთვის, ვინც Mythex-ს იყენებს:
- მოძებნა, რომელი აპი ცხოვრობს მორგებულ დომენზე. როცა ვიზიტორი გამოქვეყნებულ აპს საკუთარ დომენზე ხსნის, ჩვენი ედჟი API-ს ეკითხება, სად არის საიტი. აქ 429 ნიშნავს ვიზიტორს, რომელსაც საიტთან კავშირი არ აქვს.
- აქტიური აგენტის ბრუნის შენახვა. აგენტის მუშაობისას მისი პროგრესი ნაბიჯ-ნაბიჯ ინახება, რომ პასუხი გვერდის განახლებას ან გაწყვეტილ კავშირს გადაურჩეს. აქ 429 ნიშნავს პროგრესს, რომელიც არ შენახულა.
- გადახედვაზე წვდომის შემოწმება. აპის გადახედვა, რომელსაც აშენებთ, დაცულია, და დაცვა API-ს ეკითხება. აქ 429 ნიშნავს გადახედვას, რომელიც არ იხსნება.
ამათგან არცერთი არ იყო ადამიანი, რომელიც API-ს იძახდა. ყველა ჩვენ ვიყავით.
რატომ მოხდა
მისამართზე დაფუძნებული ლიმიტი ერთ დაშვებას აკეთებს: ერთი მისამართი დაახლოებით ერთი გამომძახებელია. ადამიანებისთვის ეს საკმარისად ახლოსაა. ჩვენი საკუთარი ინფრასტრუქტურისთვის ეს სრულიად არასწორია.
- ედჟის სერვისი, რომელიც გამოქვეყნებულ აპებს და გადახედვებს ემსახურება, API-ს რამდენიმე საერთო გამავალი მისამართიდან უკავშირდება. ყოველი ვიზიტორი ყოველი გამოქვეყნებული აპისა და ყოველი გადახედვის შემოწმება ერთ-ერთი ამ მცირე მისამართიდან მოდის.
- ორკესტრატორი — სერვისი, რომელიც აგენტის ბრუნებს უშვებს — API-ს ერთი კონტეინერის მისამართიდან უკავშირდება. ყოველი გაშვებული ბრუნი, ყოველი მომხმარებლისთვის, ამ მისამართს იყენებს.
ამიტომ ერთი ადამიანისთვის განკუთვნილი ბიუჯეტი მთელი სერვისის მთელ ტრაფიკზე ნაწილდებოდა. ამ სერვისებმა ის ერთად ამოწურეს, და ლიმიტერმა ის გააკეთა, რაც უნდა გაეკეთებინა: უარი უთხრა.
გამოსწორება
ჩვენმა სერვისებმა უკვე თავად დაამტკიცეს, ვინ არიან. თითოეულ შიდა გამოძახებას თან აქვს შიდა ტოკენი, და API-ს შიდა მონაკვეთის ყოველი მარშრუტი ამ ტოკენს ამოწმებს, სანამ რაიმეს გააკეთებს.
ლიმიტერი ახლა იგივე შემოწმებას იყენებს. მოთხოვნა, რომლის ტოკენიც შიდასთან ემთხვევა, ნებადართული სიაშია და მისამართის ბიუჯეტში არ ითვლება. ყველაფერი დანარჩენი ისევ ისე ითვლება, როგორც იყო: 300 მოთხოვნა წუთში მისამართზე.
ორი დეტალი ამას უსაფრთხოდ ტოვებდა:
- არასწორი ტოკენი არ გადის. ნებადართული სია მხოლოდ რეალურ შიდა ტოკენს ემთხვევა. მოთხოვნა გამოგონილი ტოკენით ისევ ითვლება და იზღუდება, და შიდა მარშრუტები მას
401 Unauthorized-ით უარყოფენ. - თვით ლიმიტი არ შეცვლილა. ჩვენ არ ავწიეთ რიცხვი ადგილის გასაკეთებლად. მისი აწევა პრობლემას დროებით დამალავდა, სანამ ტრაფიკი ისევ არ გაიზრდებოდა, და შეასუსტებდა დაცვას იმ შემთხვევისთვის, რისთვისაც ლიმიტი არსებობს.
ლიმიტერის პარამეტრები ერთ პატარა ფუნქციაში გადავიტანეთ და მასზე ტესტები დავწერეთ. ერთი ტესტი 20 მოთხოვნას შიდა ტოკენით უშვებს ლიმიტერზე, რომელიც 5-ს უშვებს, და ელის, რომ ყველა 20 წარმატებული იქნება. მეორე ტესტი ერთი მისამართიდან ჩვეულებრივ მოთხოვნებს უშვებს და ელის, რომ პირველი ხუთი წარმატებული იქნება, შემდეგები კი უარყოფილი. მესამე ყალბი ტოკენით მოთხოვნებს უშვებს და ელის, რომ ისინი იმავე სახით უარყოფილი იქნება.
რა ვისწავლეთ
- ლიმიტები საკუთარ დაშვებებს ატარებს. „ერთი მისამართი, ერთი გამომძახებელი“ მისამართზე დაფუძნებულ ლიმიტშია ჩაშენებული. ეს წყვეტს სიმართლეს, როგორც კი თქვენი საკუთარი სერვისები საერთო მისამართების უკან ხვდება — და ბევრი ასეა: დატვირთვის ბალანსერები, ედჟ ქსელები, კონტეინერები, ოფისის ქსელები.
- თქვენი ტრაფიკი ვინ გამოგზავნა, მისი ანგარიშით განასხვავეთ, და არა მისამართით. მისამართი ის გზაა, რომლითაც ტრაფიკი მოდის, და არა ის, ვინც გამოგზავნა. ჩვენ უკვე გვქონდა კრედენციალი, რომელიც ამტკიცებს, რომ გამოძახება ჩვენია; ლიმიტერს უბრალოდ არ უყურებდა.
- არ გაასწოროთ რიცხვის აწევით. უფრო დიდი ლიმიტი 429-ებს დროებით გააქრობდა, ნაკლებად დაიცავდა და მოგვიანებით ისევ წარუმატებელი იქნებოდა.
- შეხედეთ, ვინ იზღუდება. 429, რომელიც თქვენს საკუთარ სერვისს ხვდება, ლიმიტების შესახებ ბაგის რეპორტია, და არა იმის ნიშანი, რომ ლიმიტერი მუშაობს.
რას ნიშნავს ეს, თუ Mythex-ზე აგებთ
თქვენს მხრიდან არაფრის შეცვლა არ მოგიწევთ. გამოქვეყნებული აპები მორგებულ დომენებზე, აგენტის ბრუნები და გადახედვები აღარ არის დამოკიდებული იმაზე, რამდენად დაკავებულია Mythex-ის დანარჩენი ნაწილი. თქვენი აპის საკუთარი ტრაფიკი თქვენი საქმეა: აქ აღწერილი ლიმიტი ჩვენს API-ზეა, და არა აპებზე, რომელსაც აქვეყნებთ.
თუ თქვენი ბექენდი გაქვთ, იგივე ხაფანგი მოქმედებს ნებისმიერ ლიმიტზე, რომელსაც თავად დაამატებთ. დასაწყისისთვის კარგია ჩვენი გზამკვლევები რა არის API და უსაფრთხოების ჩამონათვალი AI-ით აგებული აპებისთვის. ჩვენი ინფრასტრუქტურის სხვა შემთხვევისთვის, სადაც ის საკუთარ თავს ეჯახება, იხილეთ როგორ მივიყვანეთ დეპლოიმენტები ნულოვან 502 შეცდომამდე.