rate limits-ის მიღმა: Codex-სა და Sora-ზე წვდომის მასშტაბირება
ჯონა კოჰენისგან, ტექნიკური შტაბის წევრი
გასულ წელს, როგორც Codex-მა, ისე Sora-მ სწრაფი მიღება ნახა და გამოყენებამ მალევე გადააჭარბა იმას, რასაც თავდაპირველად ველოდით. ერთსა და იმავე ნიმუშს ვხედავდით: მომხმარებლები ერთვებიან, რეალურ ღირებულებას პოულობენ და შემდეგ rate limits-ს ეჯახებიან.
Rate limits შეუძლია მოთხოვნის განაწილებაში დაეხმაროს და სამართლიანი წვდომა უზრუნველყოს; თუმცა, როცა მომხმარებლები ღირებულებას იღებენ, მკაცრ შეჩერებაზე მიჯახება შეიძლება გამაღიზიანებელი იყოს. გვინდოდა გზა, რომ მომხმარებლებს გაგრძელება შეძლებოდათ, თან სისტემის წარმადობა და ჩვენი მიდგომისადმი ნდობა დაგვეცვა.
ამის გადასაჭრელად შევქმენით რეალურ დროში მოქმედი წვდომის ძრავა, რომელიც გამოყენებას ითვლის. ამ ძრავის ერთ-ერთი ფენაა credits-ის შეძენის შესაძლებლობა. როცა მომხმარებლები თავიანთ rate limits-ს აჭარბებენ, credits მათ საშუალებას აძლევს ჩვენი პროდუქტები გააგრძელონ credit ბალანსის ხარჯზე.
ამის საფუძველში დევს რთული სისტემა, რომელიც აერთიანებს ლიმიტებს, რეალურ დროში გამოყენების თვალთვალს და credit ბალანსებს ერთიან access მოდელში. ეს პოსტი ხსნის, რატომ მოითხოვა Codex-ისა და Sora-ს მასშტაბირებამ წვდომის კონტროლის თავიდან გააზრება, როგორ აერთიანებს მტკიცებადად სწორი, რეალურ დროში მოქმედი სისტემა rate limits-სა და credits-ს თითო მოთხოვნაზე და როგორ ხსნის ეს საფუძველი ახლა ორივე პროდუქტზე დამატებით წვდომას.
უფრო ფართოდ რომ შევხედოთ, ტრადიციული წვდომის მოდელები, როგორც წესი, არჩევანის გაკეთებას გაიძულებს:
- Rate limits თავიდან შეიძლება სასარგებლო იყოს, მაგრამ ამოწურვის შემდეგ მომხმარებლებს ცუდ გამოცდილებას უტოვებს: „მოგვიანებით დაბრუნდით“
- გამოყენებაზე დაფუძნებული ბილინგი მოქნილია, მაგრამ მომხმარებლებს პირველი token-იდანვე ახდევინებს — რაც ადრეული ექსპერიმენტებისთვის იდეალური არ არის
Codex-ისა და Sora-სთვის არცერთი მათგანი ცალკე საკმარისი არ იყო. თუ უბრალოდ rate limits-ს ავწევდით, დავკარგავდით მოთხოვნის დაბალანსებისა და სამართლიანობის მნიშვნელოვან კონტროლს და ყველას მოსამსახურებლად capacity აღარ გვეყოფოდა. თუ მთლიანად ასინქრონულ usage billing-ს დავეყრდნობოდით, მივიღებდით დაყოვნებას, გადაჭარბებებს ან შეჯერების პრობლემებს — ზუსტად იმ ტიპის საკითხებს, რომლებსაც მომხმარებლები ყველაზე მეტად ამჩნევენ მაშინ, როცა ყველაზე მეტად არიან ჩართულები.
ამის ნაცვლად გვჭირდებოდა ერთი ჰიბრიდული სისტემა, რომელიც რეალურ დროში ლიმიტებს pay-as-you-go წვდომასთან აერთიანებდა:
ამ სისტემას უნდა შეძლებოდა:
- Rate limits-ის აღსრულება მათ ამოწურვამდე
- შეუმჩნევლად გადასვლა credits-ზე იმავე მოთხოვნის ფარგლებში
- ამ გადაწყვეტილების რეალურ დროში მიღება
- Credit მოხმარების აღრიცხვისას მკაცრი სიზუსტისა და აუდიტირებადობის უზრუნველყოფა
ერთ-ერთი მთავარი კონცეპტუალური ცვლილება, რომელიც შევიტანეთ, იყო წვდომის გადაწყვეტილებათა ჩანჩქერად მოდელირება. იმის ნაცვლად, რომ ვიკითხოთ „ეს დაშვებულია?“, ვკითხულობთ „რამდენია დაშვებული და საიდან?“ გამოყენების დათვლისას სისტემა შემდეგ მიმდევრობას გადის:
ეს მოდელი ასახავს იმას, თუ როგორ აღიქვამენ პროდუქტს რეალურად მომხმარებლები. Rate limits, უფასო ტიერები, credits, პრომოაქციები და enterprise უფლებამოსილებები — ეს ყველაფერი უბრალოდ ერთი და იმავე გადაწყვეტილების სტეკის ფენებია. მომხმარებლის პერსპექტივიდან ისინი „სისტემას არ ცვლიან“ — ისინი უბრალოდ აგრძელებენ Codex-ისა და Sora-ს გამოყენებას. ამიტომაც ჩანს credits უხილავად: ის უბრალოდ ჩანჩქერის კიდევ ერთი ელემენტია.
Credit მოხმარების სამართავად შევაფასეთ მესამე მხარის usage billing და metering პლატფორმები. ისინი კარგად ერგება ინვოისირებასა და რეპორტინგს, მაგრამ ვერ აკმაყოფილებდა ორ კრიტიკულ მოთხოვნას:
როდესაც მომხმარებელი ლიმიტს აღწევს და credits ხელმისაწვდომი აქვს, სისტემამ ეს დაუყოვნებლივ უნდა იცოდეს. მიახლოებითმა ან დაგვიანებულმა დათვლამ შეიძლება გამოიწვიოს მოულოდნელი ბლოკები, არათანმიმდევრული ბალანსები და არასწორი გადასახადები. Codex-ისა და Sora-ს მსგავსი ინტერაქტიული პროდუქტებისთვის ასეთი ჩავარდნები თვალსაჩინო და გამაღიზიანებელია.
ასევე გვჭირდებოდა სრული გამჭვირვალობის შეთავაზება თითოეული შედეგისთვის:
- რატომ იყო მოთხოვნა დაშვებული ან დაბლოკილი
- რამდენი გამოყენება მოიხმარა მან
- რომელი ლიმიტები ან ბალანსები იქნა გამოყენებული
ეს შესაძლებლობა მჭიდროდ უნდა ყოფილიყო ჩაშენებული ჩვენს გადაწყვეტილებათა ჩანჩქერში და არა ცალკე, იზოლირებულად გადაჭრილი usage billing პლატფორმაში, რომელიც მხოლოდ მიმდინარე პროცესის ერთ ნაწილს ხედავდა. იმისთვის, რომ მომხმარებლებს ჩვენს პროდუქტებზე წვდომა ჰქონოდათ ნდობის შელახვის გარეშე, გვჭირდებოდა სრული კონტროლი სისწორეზე, დროულობაზე და დაკვირვებადობაზე. ამან in-house გადაწყვეტისკენ გვიბიძგა.
ამის უზრუნველსაყოფად შევქმენით განაწილებული გამოყენებისა და ბალანსების სისტემა, რომელიც სპეციალურად სინქრონული წვდომის გადაწყვეტილებებისთვისაა შექმნილი.
მაღალ დონეზე, სისტემა:
- ადევნებს თვალს თითო მომხმარებლის, თითო ფუნქციის გამოყენებას
- ინარჩუნებს rate-limit ფანჯრებს
- ინარჩუნებს რეალურ დროში credit ბალანსებს
- აკლებს ბალანსებს იდემპოტენტურად სტრიმინგული async პროცესორის მეშვეობით
ყოველი მოთხოვნა გადის ერთიან შეფასების გზას, რომელიც რეალურ დროში წყვეტს, რამდენი გამოყენებაა დაშვებული — სინქრონულად მოიხმარს rate limits-ს და, საჭიროების შემთხვევაში, ამოწმებს საკმარის credits-ს; შემდეგ აბრუნებს ერთ საბოლოო შედეგს, ხოლო credit ჩამოწერებს ასინქრონულად ასწორებს. ეს უზრუნველყოფს თანმიმდევრულ ქცევას პროდუქტებს შორის და გამორიცხავს გუნდებს შორის ლოგიკის დუბლირებას.
ამ სისტემის ერთ-ერთი მთავარი დიზაინის პრინციპია ის, რომ უნდა შეგვეძლოს დავამტკიცოთ, რომ ჩვენი ბილინგი სწორია. ეს ასახავს ჩვენი credit მხარდაჭერის საწყისებს, რომელიც enterprise მომხმარებლებიდან წარმოიშვა. ზემოთ მოცემულ სისტემის დიაგრამაში გვაქვს სამი ცალკე მონაცემთა ნაკრები, რომლებიც ერთმანეთთან არის დაკავშირებული:
- პროდუქტის გამოყენების მოვლენები: რა გააკეთა მომხმარებელმა რეალურად
- მონეტიზაციის მოვლენები: რისთვის ვახდევინებთ მომხმარებელს მის გამოყენებაზე
- ბალანსის განახლება: რამდენით შევცვალეთ მომხმარებლის credit ბალანსი და რატომ
ეს მონაცემთა ნაკრებები შემთხვევითი გვერდითი პროდუქტი არ არის; რეალურად, სწორედ ისინი ამოძრავებენ სისტემას, სადაც ყოველი ნაკრები შემდეგს ააქტიურებს. იმის განცალკევება, თუ რა მოხდა, რა გადასახადი უკავშირდებოდა მას და რა ჩამოვაჭერით, გვაძლევს საშუალებას დამოუკიდებლად შევამოწმოთ, თავიდან გავუშვათ და შევაჯეროთ თითოეული ფენა. ეს არის შეგნებული კომპრომისი, სადაც ჩვენ მტკიცებადად სწორობას ვანიჭებთ უპირატესობას, იმის ფასად, რომ credit ბალანსის განახლებები ოდნავ დაგვიანდეს. როგორ მივაღწიეთ ამას:
- პროდუქტის გამოყენების მოვლენები ქვეყნდება მომხმარებლის ყველა აქტივობისთვის, მიუხედავად იმისა, იწვევს თუ არა ის credit მოხმარებას. ეს ქმნის მომხმარებლის აქტივობის აუდიტის კვალს და გვაძლევს საშუალებას ავხსნათ, რატომ ჩამოვაჭერით ან არ ჩამოვაჭერით credits.
- ყოველ მოვლენას აქვს სტაბილური idempotency key, ამიტომ retry, replay ან worker-ის გადატვირთვა ვერასდროს გამოიწვევს ბალანსის ორმაგ ჩამოჭრას, რაც ორმაგ დარიცხვას თავიდან გვარიდებს. ეს ასევე გვაძლევს საშუალებას ოფლაინ რეჟიმში batch reconciliation გავუშვათ ჩვენი შედეგების გადასამოწმებლად.
- ბალანსების განახლებას ვაკეთებთ ასინქრონულად (მაგრამ მაინც თითქმის რეალურ დროში) და არა სინქრონულად, რათა აუდიტის კვალი შევქმნათ. ჩვენ ვუშვებთ მომხმარებლის ბალანსის განახლებაში მცირე დაყოვნებას, რათა შევძლოთ სისტემის გამართულობის დამტკიცება და მომხმარებლების დარწმუნება, რომ არასწორად არ ვუწერთ თანხას. როცა ეს მოკლე დაყოვნება მომხმარებლის credit ბალანსის გადაჭარბებას იწვევს, ავტომატურად ვაბრუნებთ თანხას; მკაცრ აღსრულებაზე წინ მტკიცებადად სწორობასა და მომხმარებლის ნდობას ვაყენებთ.
- Credit Balance-ს ვამცირებთ და Balance Update ჩანაწერს ვამატებთ ერთი ატომური მონაცემთა ბაზის ტრანზაქციის ფარგლებში. Balance updates სერიალიზებულია თითო ანგარიშზე, ამიტომ ერთდროული მოთხოვნები ვერასდროს შეეჯიბრება ერთმანეთს ერთსა და იმავე credits-ის დახარჯვაზე. Balance Update ჩანაწერი შეიცავს როგორც ჩამოწერის ოდენობას, ისე კავშირს იმ monetization event-თან, რომელმაც ეს განახლება გამოიწვია; ამის ერთი მონაცემთა ბაზის ტრანზაქციაში მოქცევა გვაძლევს გარანტიას, რომ credit ბალანსის თითოეულ ცვლილებაზე აუდიტის კვალი გვაქვს.
მთელი ეს სიმკაცრე ერთ მიზანს ემსახურება: წვდომა მარტივი და უსაფრთხო გავხადოთ. როცა ადამიანები ქმნიან ან კოდს წერენ, მათ არ უნდა უწევდეთ ფიქრი იმაზე, გაივლის თუ არა მოთხოვნა, ზედმეტს გადაახდევინებენ თუ არა, ან სწორია თუ არა მათი ბალანსი. გამოყენების, ბილინგისა და ბალანსების მტკიცებადად სწორად ქცევით მომხმარებლებს ვაძლევთ სისტემას, რომელიც მათ გამოცდილებას ყურადღებას არ აცდენს. სწორედ ეს გვაძლევს საშუალებას, მკაცრი შეჩერებები უწყვეტი წვდომით ჩავანაცვლოთ — და სწორედ ეს ხდის credits-ს გამოსადეგს რეალური მუშაობის შუაგულში და არა მხოლოდ ინვოისზე.
ჩვენი მიდგომის ძირითადი პრინციპი მომხმარებლის იმპულსის დაცვაა. თითოეული არქიტექტურული გადაწყვეტილება პირდაპირ უკავშირდება მომხმარებლისთვის ხილულ შედეგს: რეალურ დროში ბალანსები არასაჭირო შეწყვეტებს აცილებს, ატომური მოხმარება ორმაგ დარიცხვას თავიდან გვარიდებს, ხოლო ერთიანი წვდომის ლოგიკა პროგნოზირებად ქცევას უზრუნველყოფს. შედეგად, ადამიანებს შეუძლიათ უფრო დიდხანს იმუშაონ, უფრო ღრმად გამოიკვლიონ და პროექტები უფრო შორს წაიყვანონ მკაცრ შეჩერებებსა თუ ნაადრევ სატარიფო ცვლილებებთან შეჯახების გარეშე.
როდესაც მომხმარებლები ჩართულები არიან, სისტემა უნდა ეხმარებოდეს მათ გაგრძელებაში და არა ხელს უშლიდეს. ლიმიტები და credits უკანა ფონზე ქრება.
ამ გამოცდილების შექმნა მოითხოვდა წვდომის, გამოყენებისა და ბილინგის ერთიან სისტემად თავიდან გააზრებას და ისეთი ინფრასტრუქტურის აგებას, რომელიც სისწორეს პირველი კლასის პროდუქტულ ფუნქციად განიხილავს. იგივე საფუძველი დროთა განმავლობაში მეტ პროდუქტზეც შეიძლება გავრცელდეს; Codex და Sora მხოლოდ დასაწყისია.
