خودمان سرویس‌های خودمان را محدود می‌کردیم

API مجاز Mythex در هر دقیقه ۳۰۰ درخواست از یک آدرس شبکه را می‌پذیرد. این محدودیت برای محافظت از ما در برابر یک آدم یا اسکریپت واحد است که API را بمباران کند. در production، شروع کرد به رد کردن سرویس‌های خودمان — بخشی از edge ما که اپ‌های منتشرشده را سرو می‌کند و سرویسی که عامل هوش مصنوعی را اجرا می‌کند — چون هرکدام فقط از چند آدرس محدود به API درخواست می‌دهند. درخواست‌هایی که اعتبارنامه‌ی داخلی ما را دارند الان معاف‌اند، و بقیه دقیقاً مثل قبل محدود می‌شوند.

علامت

API شروع کرد به پاسخ دادن به بعضی از درخواست‌های داخلی خودمان با 429 Too Many Requests. سه نوع فراخوانی تحت تأثیر قرار گرفتند، و هرکدام برای کسی که از Mythex استفاده می‌کند اهمیت دارد:

• پیدا کردن اینکه کدام اپ روی یک دامنه‌ی سفارشی زندگی می‌کند. وقتی بازدیدکننده یک اپ منتشرشده را روی دامنه‌ی خودش باز می‌کند، edge ما از API می‌پرسد آن سایت کجاست. یک 429 آنجا یعنی بازدیدکننده‌ای که نمی‌تواند به سایتی برسد.
• ذخیره‌ی یک نوبت زنده‌ی عامل. وقتی عامل کار می‌کند، پیشرفتش در حین کار ذخیره می‌شود، تا پاسخ از رفرش یا قطع اتصال جان سالم به در ببرد. یک 429 آنجا یعنی پیشرفتی که ذخیره نشده.
• بررسی دسترسی به پیش‌نمایش. پیش‌نمایش اپی که می‌سازید دروازه دارد و دروازه از API می‌پرسد. یک 429 آنجا یعنی پیش‌نمایشی که باز نمی‌شود.

هیچ‌کدام از اینها آدم‌هایی که API را صدا بزنند نبودند. همه‌شان خودمان بودیم.

چرا پیش آمد

یک محدودیت نرخ به ازای هر آدرس یک فرض دارد: یک آدرس تقریباً یک فراخوان‌کننده است. برای آدم‌ها این تقریباً درست است. برای زیرساخت خودمان کاملاً اشتباه است.

• سرویس edge که اپ‌های منتشرشده و پیش‌نمایش‌ها را سرو می‌کند، از چند آدرس خروجی مشترک به API درخواست می‌دهد. هر بازدیدکننده‌ی هر اپ منتشرشده، و هر بررسی پیش‌نمایش، طوری می‌رسد که انگار از یکی از همان چند آدرس آمده است.
• ارکستراتور — سرویسی که نوبت‌های عامل را اجرا می‌کند — از یک آدرس کانتینر به API درخواست می‌دهد. هر نوبت در حال اجرا، برای هر کاربر، آن آدرس را شریک است.

پس بودجه‌ای که برای یک آدم در نظر گرفته شده بود، بین تمام ترافیک یک سرویس کامل تقسیم می‌شد. آن سرویس‌ها بینشان آن را تمام کردند، و محدودکننده کاری را کرد که به آن گفته شده بود: آن‌ها را رد کرد.

رفع

سرویس‌های خودمان از قبل ثابت می‌کنند که کی هستند. هر فراخوان داخلی یک توکن داخلی همراه دارد، و هر مسیر زیر بخش داخلی API پیش از انجام هر کاری این توکن را بررسی می‌کند.

محدودکننده‌ی نرخ حالا از همان بررسی استفاده می‌کند. درخواستی که توکنش با توکن داخلی برابر باشد در فهرست مجاز است و از بودجه‌ی ۳۰۰ درخواست در دقیقه به ازای هر آدرس کم نمی‌شود. بقیه دقیقاً مثل قبل شمرده می‌شوند: ۳۰۰ درخواست در دقیقه به ازای هر آدرس.

دو جزئیات باعث شد این به یک سوراخ تبدیل نشود:

1. توکن اشتباه هیچ معافیتی نمی‌گیرد. فهرست مجاز فقط با توکن داخلی واقعی تطابق دارد. درخواستی با توکن جعلی شمرده و محدود می‌شود، و مسیرهای داخلی آن را با 401 Unauthorized رد می‌کنند.
2. خود محدودیت تغییر نکرد. عدد را بالا نبردیم تا جا باز شود. بالا بردنش مشکل را برای مدتی پنهان می‌کرد، با رشد دوباره‌ی ترافیک دوباره خراب می‌شد، و محافظت را برای موردی که محدودیت برایش وجود دارد ضعیف می‌کرد.

تنظیمات محدودکننده را در یک تابع کوچک گذاشتیم و تست‌هایی برایش نوشتیم. یکی ۲۰ درخواست با توکن داخلی به یک محدودکننده که فقط ۵ مجاز می‌کند می‌فرستد، و انتظار دارد هر ۲۰ تا موفق شوند. دیگری درخواست‌های ساده از یک آدرس می‌فرستد و انتظار دارد پنج تای اول موفق شوند و بقیه رد شوند. سومی درخواست‌هایی با توکن جعلی می‌فرستد و انتظار دارد به همان شکل رد شوند.

آنچه از آن برداشتیم

• محدودیت‌ها فرض‌هایی دارند. «یک آدرس، یک فراخوان‌کننده» در یک محدودیت نرخ به ازای هر آدرس تعبیه شده است. وقتی سرویس‌های خودتان پشت آدرس‌های مشترک قرار می‌گیرند، این دیگر درست نیست — و بسیاری از سرویس‌ها این‌طورند: load balancerها، شبکه‌های edge، کانتینرها، شبکه‌های اداری.
• ترافیک خودتان را با هویت تشخیص دهید، نه با آدرس. آدرس‌ها راه رسیدن ترافیک‌اند، نه اینکه چه کسی آن را فرستاده. ما از قبل اعتبارنامه‌ای داشتیم که ثابت می‌کند فراخوان مال ماست؛ محدودکننده فقط به آن نگاه نمی‌کرد.
• با بالا بردن عدد آن را رفع نکنید. یک حد بزرگ‌تر خطاهای 429 را برای مدتی ناپدید می‌کرد، محافظت کمتری می‌داد، و دیرتر دوباره خراب می‌شد.
• ببینید چه کسی محدود می‌شود. یک 429 که به سرویس خودتان می‌خورد گزارش باگ درباره‌ی محدودیت‌های شماست، نه نشانه‌ای از اینکه محدودکننده کار می‌کند.

اگر روی Mythex می‌سازید چه معنایی دارد

کاری از طرف شما لازم نیست. اپ‌های منتشرشده روی دامنه‌های سفارشی، نوبت‌های عامل و پیش‌نمایش‌ها دیگر به شلوغی بقیه‌ی Mythex وابسته نیستند. ترافیک خود اپ شما مال خود اپ شماست: محدودیتی که اینجا توضیح داده شد روی API ماست، نه روی اپ‌هایی که منتشر می‌کنید.

اگر بک‌اند خودتان را اجرا می‌کنید، همان تله برای هر محدودیت نرخی که اضافه می‌کنید صدق می‌کند. راهنماهای ما درباره‌ی API چیست و چک‌لیست امنیتی برای اپ‌های ساخته‌شده با هوش مصنوعی نقطه‌ی شروع خوبی‌اند. و برای نمونه‌ی دیگری از زیرساخت خودمان که جلوی خودش را می‌گیرد، چطور استقرارها را به صفر خطای ۵۰۲ رساندیم را ببینید.