فراتر از محدودیتهای تعداد درخواست: گسترش دسترسی به Codex و Sora
نوشته Jonah Cohen، عضو کادر فنی
در سال گذشته، هر دو Codex و Sora رشد و پذیرش سریعی داشتهاند، بهگونهای که میزان استفاده از آنها خیلی زود از آنچه در ابتدا انتظار میرفت فراتر رفته است. ما یک الگوی ثابت مشاهده کردهایم: کاربران وارد میشوند، ارزش واقعی را پیدا میکنند و سپس با محدودیتهای تعداد درخواست مواجه میشوند.
محدودیتهای تعداد درخواست میتوانند به هموار کردن تقاضا و تضمین دسترسی منصفانه کمک کنند؛ با این حال، زمانی که کاربران در حال دریافت ارزش هستند، مواجهه با یک توقف کامل میتواند ناامیدکننده باشد. ما به دنبال راهی بودیم که کاربران بتوانند به کار خود ادامه دهند، در حالی که عملکرد سیستم و اعتماد کاربران به رویکرد ما حفظ شود.
برای حل این مسئله، ما یک موتور دسترسی بلادرنگ ساختیم که میزان استفاده را محاسبه میکند. یکی از لایههای آن موتور، قابلیت خرید اعتبار است. زمانی که کاربران از محدودیتهای تعداد درخواست خود عبور میکنند، اعتبارها به آنها اجازه میدهند با کاهش مانده اعتبارشان، به استفاده از محصولات ما ادامه دهند.
در پسِ این ماجرا، یک سیستم پیچیده وجود دارد که محدودیتها، پایش استفاده در زمان واقعی و موجودی اعتبار را در یک مدل دسترسی واحد با هم ادغام میکند. این پست توضیح میدهد چرا مقیاسدهی Codex و Sora نیازمند بازنگری در کنترل دسترسی بود، چگونه یک سیستم بلادرنگِ اثباتشده، محدودیتهای تعداد درخواست و اعتبارها را بهازای هر درخواست ادغام میکند، و چگونه آن زیربنا اکنون دسترسی بیشتری را برای هر دو محصول فراهم میکند.
با نگاهی کلی، مدلهای سنتی در دسترس معمولاً شما را مجبور به انتخاب میکنند:
- محدودیتهای تعداد درخواست در ابتدا میتوانند مفید باشند، اما وقتی کاربران با پیام «بعداً برگردید» مواجه میشوند، تجربه بدی خواهند داشت
- صورتحساب مبتنی بر استفاده انعطافپذیر است، اما کاربران را مجبور میکند از اولین توکن هزینه پرداخت کنند—که برای پشتیبانی از کاوش اولیه ایدهآل نیست
برای Codex و Sora، هیچکدام بهتنهایی کافی نبود. اگر ما به سادگی محدودیتهای تعداد درخواست را افزایش میدادیم، کنترلهای مهم هموارسازی تقاضا و انصاف را از دست میدادیم و ظرفیتمان برای خدمترسانی به همه تمام میشد. اگر کاملاً به صورتحسابِ مبتنی بر استفاده غیرهمزمان تکیه میکردیم، با تأخیر، هزینههای مازاد یا مشکلات تطبیق و تسویه روبهرو میشدیم—دقیقاً همان نوع مسائلی که کاربران زمانی متوجه آن میشوند که بیش از هر زمان دیگری درگیر و فعال هستند.
آنچه ما به آن نیاز داشتیم، یک سیستم ترکیبی واحد بود که محدودیتهای لحظهای را با دسترسی پرداخت به میزان استفاده ترکیب کند:
این سیستم باید:
- محدودیتهای تعداد درخواست را تا زمانی که به سقف آنها برسد اعمال کند
- بهصورت یکپارچه و در همان درخواست به استفاده از اعتبار منتقل شود
- آن تصمیم را در زمان واقعی بگیرید
- هنگام پیگیری مصرف اعتبار، بهطور دقیق و قابل ممیزی عمل کنید
یکی از تغییرات مفهومی کلیدی که ایجاد کردیم، مدلسازی دسترسی بهعنوان یک آبشار تصمیمگیری بود. بهجای آنکه بپرسیم «آیا این مجاز است؟»، میپرسیم «چه مقدار مجاز است، و از کجا تأمین میشود؟» هنگام محاسبهٔ میزان مصرف، سیستم مراحل زیر را طی میکند:
این مدل بازتابدهندهٔ نحوهٔ واقعی استفادهٔ کاربران از محصول است. محدودیت تعداد درخواست، سطح رایگان، اعتبار، طرحهای ترویجی و امتیازات سازمانی همگی صرفاً لایههایی در یک پشتهٔ تصمیمگیری واحد هستند. از دید کاربر، آنها بین سیستمهای مختلف «سوئیچ» نمیکنند—بلکه فقط به استفاده از Codex و Sora ادامه میدهند. به همین دلیل است که اعتبارها نامرئی به نظر میرسند؛ آنها صرفاً یکی دیگر از اجزای همان آبشار تصمیمگیری هستند.
ما پلتفرمهای شخصِ ثالث برای صورتحساب و سنجش میزان مصرف را ارزیابی کردیم تا مدیریت مصرف اعتبار را بر عهده بگیرند. آنها برای صدور صورتحساب و گزارشدهی بسیار مناسب هستند، اما دو نیاز حیاتی را برآورده نمیکنند:
هنگامی که کاربر به یک محدودیت میرسد و اعتبارهای در دسترس دارد، سیستم باید بلافاصله مطلع شود. محاسبهٔ مصرف بهصورت تقریبی یا با تأخیر، خود را به شکل مسدودشدنهای ناگهانی، ناهماهنگی در موجودیها و هزینههای نادرست نشان میدهد. برای محصولات تعاملی مانند Codex و Sora، این ناکامیها به وضوح دیده میشوند و آزاردهنده هستند.
ما همچنین باید شفافیت را در هر نتیجهای ارائه میدادیم:
- چرا یک درخواست مجاز یا مسدود شده است
- اینکه چه میزان مصرف را به خود اختصاص داده است
- کدام محدودیتها یا توازنها اعمال شدهاند
این قابلیت باید بهصورت فشرده و یکپارچه در دلِ آبشار تصمیمگیری ما ادغام میشد، نه اینکه بهطور جداگانه در یک پلتفرم مستقلِ صورتحساب مبتنی بر استفاده پیادهسازی شود—پلتفرمی که فقط بخشی از آنچه در حال رخ دادن است را میبیند. برای اینکه کاربران بتوانند بدون به خطر انداختن اعتماد به محصولات ما دسترسی داشته باشند، نیاز داشتیم که کنترل کامل بر درستی، زمانبندی و قابلیت مشاهدهپذیری داشته باشیم. همین موضوع ما را به سمت یک راهکارِ در داخل مجموعه سوق داد.
برای پشتیبانی از این مدل، یک سامانهٔ توزیعشدهٔ مصرف و مدیریت موجودی طراحی و پیادهسازی کردیم که بهطور ویژه برای تصمیمگیریهای دسترسیِ همزمان ساخته شده است.
در سطح بالا، سیستم:
- میزان مصرف را بهازای هر کاربر و هر قابلیت پایش میکند
- پنجرههای محدودیت تعداد درخواست را حفظ میکند
- موجودیهای اعتباری را بهصورت لحظهای حفظ میکند.
- موجودی را از طریق یک پردازشگر جریانیِ غیرهمزمان، بدون کسرِ موارد تکراری در صورت اجرای مجدد کسر میکند
هر درخواست از یک مسیر ارزیابی واحد عبور میکند که بهصورت آنی تصمیم میگیرد چه میزان مصرف مجاز است؛ این کار با مصرف همزمان از محدودیتهای تعداد درخواست و، در صورت لزوم، بررسی کفایت اعتبار انجام میشود. سپس یک نتیجهٔ قطعی بازمیگرداند و هرگونه کسر از اعتبار را بهصورت غیرهمزمان تسویه میکند. این امر رفتار یکنواخت را در تمام محصولات تضمین میکند و منطق تکراری را در بین تیمها حذف میکند.
یکی از اصول کلیدی طراحی این سیستم این است که باید بتوانیم اثبات کنیم که صورتحساب ما صحیح است. این موضوع بازتابدهندهٔ ریشههای پشتیبانی از اعتبار در سیستم ماست که در ابتدا از مشتریان سازمانی آغاز شد. در نمودار سیستم بالا، سه مجموعه داده جداگانه داریم که همگی به هم مرتبط هستند:
- رویدادهای استفاده از محصول: آنچه کاربر واقعاً انجام داده است
- رویدادهای کسب درآمد: هزینهای که بابت استفاده کاربر از او دریافت میشود
- بهروزرسانیهای موجودی: میزان تعدیل مانده اعتبار کاربر و دلیل آن
این مجموعهدادهها یک محصول جانبیِ تصادفی نیستند؛ بلکه در واقع خودِ سیستم را به حرکت درمیآورند، بهگونهای که هر مجموعهداده، مجموعهدادهٔ بعدی را فعال میکند. تفکیک آنچه رخ داده، هرگونه هزینهٔ مرتبط، و آنچه از موجودی کسر شده است، به ما امکان میدهد هر لایه را بهطور مستقل ممیزی، بازپخش و تطبیق کنیم. این یک مصالحهٔ آگاهانه است که در آن، درستیِ قابلاثبات را در اولویت قرار دادهایم، حتی اگر به بهای اندکی تأخیر در بهروزرسانی موجودی اعتبار باشد. چگونه به این دستاورد رسیدیم:
- رویدادهای استفاده از محصول برای تمام فعالیتهای کاربر منتشر میشوند، چه منجر به مصرف اعتبار شوند و چه نشوند. این کار یک سابقهٔ قابلممیزی از فعالیتهای کاربر فراهم میکند و به ما امکان میدهد توضیح دهیم چرا اعتبار کسر کردهایم، یا چرا کسر نکردهایم.
- هر رویداد یک کلید ایدمپوتنسیِ پایدار دارد؛ بنابراین تلاشهای مجدد، بازپخشها یا راهاندازی دوبارهٔ پردازشگر هرگز نمیتوانند موجودی را دوبار کسر کنند، و این از دوبار هزینهکردن جلوگیری میکند. این کار همچنین به ما امکان میدهد یک فرایند تطبیقِ دستهای اجرا کنیم تا عملکرد خود را بهصورت آفلاین راستیآزمایی کنیم.
- ما بهجای بهروزرسانیهای همزمان، بهروزرسانیهای غیر همزمان (اما همچنان نزدیک به فوری) موجودی را انجام میدهیم تا یک مسیر ممیزی ایجاد کنیم. ما یک تأخیر کوچک در بهروزرسانی موجودی کاربر را میپذیریم تا بتوانیم ثابت کنیم که سیستم بهدرستی کار میکند و به کاربران خود اطمینان دهیم که هزینهها را بهاشتباه از آنها دریافت نمیکنیم. وقتی آن تأخیر کوتاه باعث میشود از موجودی اعتبار کاربر فراتر برویم، ما بهطور خودکار آن را بازپرداخت میکنیم؛ ما درستیِ قابلاثبات و اعتماد کاربران را بر اجرای سختگیرانه ترجیح میدهیم.
- ما موجودی اعتبار را کاهش میدهیم و یک رکورد بهروزرسانی موجودی را در قالب یک تراکنش اتمیِ واحد در پایگاه داده درج میکنیم. بهروزرسانیهای موجودی برای هر حساب بهصورت سریالی انجام میشوند، بنابراین درخواستهای همزمان هرگز نمیتوانند برای مصرف یک اعتبار واحد با یکدیگر رقابت کنند. رکورد بهروزرسانی موجودی هم مبلغ کسرشده را در بر دارد و هم ارجاعی به رویداد درآمدزاییای که این بهروزرسانی را فعال کرده است؛ قرار دادن این موارد در قالب یک تراکنش واحدِ پایگاه داده تضمین میکند که برای هر تغییری در موجودی اعتبار، یک سابقهٔ قابلممیزی در اختیار داشته باشیم.
تمام این سختگیری از یک هدف پشتیبانی میکند: ساده و ایمن کردن دسترسی. وقتی افراد در حال خلق محتوا یا کدنویسی هستند، نباید نگران این باشند که آیا درخواستشان پردازش میشود یا خیر، آیا بیشازحد از آنها هزینه گرفته خواهد شد، یا آیا موجودیشان دقیق است. با تضمین درستیِ قابلاثبات در مصرف، صورتحساب و موجودیها، سیستمی در اختیار کاربران میگذاریم که حواس آنها را از تجربهٔ کاربریشان پرت نمیکند. همین رویکرد است که به ما امکان میدهد بهجای توقفهای ناگهانی، دسترسی پیوسته فراهم کنیم—و باعث میشود اعتبارها در میانهٔ کار واقعی و نه صرفاً در قالب یک صورتحساب، قابلاستفاده باشند.
اصل راهنمای رویکرد ما، حفظ تداوم حرکت کاربر است. هر تصمیم معماری به یک نتیجهٔ قابلمشاهده برای کاربر بازمیگردد: موجودیهای بهروزرسانیشده در زمان واقعی از وقفههای غیرضروری جلوگیری میکنند، مصرف اتمی مانع دوبار هزینهگرفتن میشود، و منطق دسترسی یکپارچه رفتار قابلپیشبینی را تضمین میکند. در نتیجه، افراد میتوانند مدتزمان بیشتری کار کنند، عمیقتر کاوش کنند و پروژهها را جلوتر ببرند، بیآنکه با توقفهای ناگهانی یا تغییر زودهنگام طرح روبهرو شوند.
هنگامی که کاربران مشغول هستند، سیستم باید به آنها کمک کند تا ادامه دهند و مانع آنها نشود. محدودیتها و اعتبارها در پسزمینه محو میشوند.
ساختن چنین تجربهای مستلزم این بود که دسترسی، مصرف و صورتحساب را بهعنوان یک سامانهٔ واحد دوباره تعریف کنیم و زیرساختی بسازیم که درستی را یک ویژگی اصلیِ محصول بداند. همان پایهٔ فنی میتواند به مرور به محصولات بیشتری گسترش یابد؛ Codex و Sora فقط آغاز راه هستند.
