تصور کنید یک پرس‌وجوی (Query) اشتباه و سنگین، کل پایگاه‌داده عملیاتی شما را در چند ثانیه به زانو درآورد. این کابوس برای بسیاری از تیم‌های فنی عادی است، چرا که Postgres به‌صورت پیش‌فرض مکانیزمی برای مقابله با جهش‌های ناگهانی ترافیک ندارد. برای حل این مشکل، PlanetScale در ۳۰ ژوئن ۲۰۲۶ قابلیتی به نام Database Traffic Control را معرفی کرد تا پایگاه‌داده‌ها بتوانند با تعیین بودجه‌های سخت‌گیرانه برای منابع، از خود دفاع کنند. این ابزار مانند یک دماساز یا کنترل‌کننده ترافیک در اتوبان است که اجازه نمی‌دهد یک خودروی غول‌پیکر، تمام مسیر را برای بقیه مسدود کند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی پایداری زیرساخت‌های ابری اشاره کردیم، مدیریت هوشمند منابع تنها راه نجات در مقیاس‌های بزرگ است.
شکاف موجود در Postgres
طبق اعلام رسمی PlanetScale، این سیستم شکاف بنیادین Postgres را پر می‌کند. از لحاظ تاریخی، Postgres تمام پرس‌وجوهای ورودی را می‌پذیرد تا زمانی که یا عملکرد سیستم به‌شدت افت کند و یا در بدترین حالت، سرور به‌طور کامل سقوط کند. این مسئله یک نقطه ضعف بحرانی برای هر اپلیکیشنی ایجاد می‌کند که با جهش‌های ناگهانی بار (Load Spikes) مواجه می‌شود. این وضعیت را مانند اتوبانی بدون رمپ‌های ورودی تصور کنید؛ وقتی ترافیک متوقف شود، همه چیز می‌ایستد، فارغ از اینکه هر خودرو چقدر مهم یا ضروری است.
سیستم Database Traffic Control™ با ارائه یک مدیریت ترافیک داخلی در PlanetScale، این خلاء را پر می‌کند. این قابلیت به مدیران اجازه می‌دهد در لحظه تصمیم بگیرند هر بخش از بار کاری، چه مقدار از منابع دیتابیس را مصرف کند. بر اساس مستندات این شرکت، کاربران می‌توانند ترافیک را در چهار بُعد (Dimension) اصلی هدف‌گذاری کنند:
- الگوهای پرس‌وجو که از طریق اثرانگشت‌ها (Fingerprints) در بخش Insights شناسایی می‌شوند
- نام اپلیکیشن‌هایی که درخواست‌ها را ارسال می‌کنند
- کاربران خاص پایگاه‌داده Postgres
- تگ‌های سفارشی SQL (مانند نام قابلیت، سطح اولویت، منطقه جغرافیایی یا رتبه مشتری)
جزئیات اعمال محدودیت‌های منابع
پس از تعریف بودجه، PlanetScale محدودیت‌ها را بر روی سازوکارهای فنی زیر اعمال می‌کند:
- درصد مصرف CPU و محدودیت‌های Burst (جهش‌های کوتاه)
- میزان هم‌زمانی (Concurrency) پردازش‌های Backend
- زمان‌بندی (Timing) هر پرس‌وجو
این سیستم در دو حالت عمل می‌کند: حالت «هشدار» (Warn) برای مشاهده مواردی که قرار است محدود شوند (تا کاربر ببیند چه چیزی throttling می‌شود) و حالت «اجرا» (Enforce) برای مسدود کردن فعالانه پرس‌وجوهایی که از حد بودجه فراتر می‌روند. کاربران می‌توانند در هر زمان بین این دو حالت جابه‌جا شوند.
این مکانیزم به‌طور خاص مشکل «همسایه پرصدا» (Noisy Neighbor) را در اپلیکیشن‌های چندمشتری (Multi-tenant) حل می‌کند. با تگ‌گذاری ترافیک، شرکت‌ها می‌توانند تضمین کنند که مشتریان سازمانی (Enterprise) حتی زمانی که کاربران نسخه رایگان یا آزمایشی باعث جهش‌های عظیم ترافیک می‌شوند، محافظت شده و دسترسی بدون اختلال داشته باشند.
علاوه بر این، این ابزار یک حفاظ (Guardrail) میان کاربران انسانی و عامل‌های هوش مصنوعی (AI Agents) ایجاد می‌کند تا ربات‌های خودکار با اشغال تمام منابع، تجربه کاربری انسان‌ها را مختل نکنند و باعث گرسنگی منابع (Resource Starvation) برای کاربران واقعی نشوند. این چالش‌ها در مدیریت منابع، به‌ویژه زمانی که عامل‌های هوش مصنوعی باعث تورم هزینه‌های ابری می‌شوند، اهمیت دوچندانی پیدا می‌کنند. همچنین این سیستم شکل‌دهی ترافیک بر اساس اولویت (Priority-based Traffic Shaping) را ممکن می‌سازد. قابلیت‌های حیاتی مانند احراز هویت و جریان‌های اصلی کاربر می‌توانند محدودیت‌های بالاتری داشته باشند، در حالی که از اشغال منابع توسط کارهای پس‌زمینه (Background Jobs) با اولویت پایین جلوگیری می‌شود.
از دیدگاه توسعه‌دهندگان، این تغییر باعث می‌شود دیتابیس از یک پذیرنده غیرفعال به یک شرکت‌کننده فعال در شکل‌دهی ترافیک تبدیل شود. به‌جای سقوط سخت، سیستم یک «تضعیف تدریجی» (Graceful Degradation) را اجرا می‌کند؛ یعنی فقط بار کاری مشکل‌ساز را محدود می‌کند و بقیه اپلیکیشن را آنلاین نگه می‌دارد.
پیاده‌سازی و عملیات
برای پیاده‌سازی، توسعه‌دهندگان باید به تب Traffic Control در داشبورد PlanetScale بروند. این شرکت توصیه می‌کند برای کسب دید عمیق‌تر نسبت به دسته‌بندی پرس‌وجوها، از تگ‌های sqlcommenter استفاده شود. لازم به ذکر است که هنگام ایجاد بودجه، ممکن است نیاز به ری‌استارت دیتابیس باشد. این بودجه‌ها از طریق API و CLI نیز قابل اتومیشن هستند تا مستقیماً در خط لوله‌های استقرار (Deployment Pipelines) قرار گیرند.
تیم‌های عملیاتی اکنون می‌توانند با چند کلیک در Insights، مقصر را پیدا کرده، داده‌های دقیق مصرف را بررسی کرده و بودجه را اعمال کنند تا دیتابیس در حال جهش را تثبیت نمایند. این رویکرد، جایگزین روش ابتدایی و خطرناک kill -9 برای کشتن پردازش‌های سرکش شده و یک محدودیت جراحی‌گونه و سیاست‌محور را جایگزین آن می‌کند.
کاربران علاقه‌مند در حال حاضر می‌توانند این قابلیت‌ها را با کلون کردن ابزار دموی 'onramp' و اجرای دستور onramp create برای تولید خودکار شماماها و بودجه‌ها تست کنند. بررسی فنی کامل در مستندات PlanetScale موجود است.
گام بعدی شما
- اگر از Postgres در مقیاس بالا استفاده می‌کنید، ابتدا حالت Warn را فعال کنید تا بفهمید کدام کوئری‌ها بودجه شما را می‌بلعند.
- تگ‌های SQL را به استانداردهای کدنویسی تیم خود اضافه کنید تا تحلیل ترافیک از سطح کاربر به سطح قابلیت (Feature) برسد.
- برای تست سریع، ابزار دمو onramp را کلون کرده و دستور
onramp createرا اجرا کنید.
اما این مدیریت ترافیک تنها بخشی از پازل است؛ برای بهینه‌سازی لایه ذخیره‌سازی، تحلیل ما درباره استراتژی‌های Indexing جدید را بخوانید.
گفتگو