تصور کنید باید هر روز دهها بهروزرسانی حساس را روی ۱۰۰ خوشه دیتابیس مختلف اجرا کنید، اما حق ندارید برای امنیت بیشتر، حتی یک بار وارد حساب ابری مشتری شوید. این همان چالشی است که Turbopuffer با تبدیل هر عملیات به یک ماشین وضعیت بادوام، آن را حل کرده است. این رویکرد تضمین میکند که بهروزرسانیها حتی در صورت قطع اتصال با سرور مرکزی، به طور مستقل پیش بروند.
مدیریت دیتابیس در مقیاس بالا معمولاً یک موازنه بین سرعت و امنیت است. اکثر ارائهدهندگان خدمات ابری با مدلهای «ابر خودتان» (Bring Your Own Cloud یا BYOC) دست و پنجه نرم میکنند، زیرا نمیتوانند بدون ایجاد هزینههای عظیم نظارتی، انطباقی (Compliance) و صورتحسابی، از طریق SSH یا kubectl وارد محیط خصوصی مشتری شوند. طبق گزارش منتشر شده در ۱۴ اوت ۲۰۲۶، تاران پوتولاپاتی، مهندس این شرکت، توضیح داد که چگونه آنها با طراحی سیستمی که در آن هر خوشه عملیات خود را به پایان میرساند، گلوگاههای امنیتی را حذف کردند. در واقع آنها از مدل «کمترین مخرج مشترک» استفاده کردند تا نیاز به دسترسی مستقیم به زیرساخت را از بین ببرند.
چالش معماری BYOC
در یک مدل استاندارد SaaS، ارائهدهنده مالک کلیدهای دسترسی است. اما در مدل BYOC، مشتری مالک منابع است. Turbopuffer برای اینکه محدودیت ایجاد نکند و اجازه دهد مشتری سرویس را در هر جایی اجرا کند، سه مدل استقرار متمایز را پشتیبانی میکند:
- SaaS عمومی: منابع مشترک که روی AWS و GCP اجرا میشوند و اپراتور Turbopuffer به آنها دسترسی دارد.
- SaaS تکمستأجری: منابع اختصاصی روی AWS و GCP که همچنان دسترسی اپراتور Turbopuffer را دارند.
- BYOC (ابر خودتان): منابع اختصاصی مشتری روی AWS، GCP یا Azure که هیچ دسترسی مدیریتی برای اپراتور Turbopuffer وجود ندارد.
در حال حاضر آنها بیش از ۱۰۰ خوشه را مدیریت میکنند که نسبت به ۶ ماه پیش دو برابر شده است و با افزودن مناطق عمومی بیشتر و استقرارهای BYOC جدید، این تعداد در حال رشد است. برای جلوگیری از مدیریت چندین صفحه کنترل (Control Plane) متفاوت برای هر مدل، آنها یک عامل (Agent) محلی در هر استقرار پیادهسازی کردند.
مشکل دسترسی در مدل BYOC
خوشههای BYOC درون حسابهای ابری مشتریان زندگی میکنند. به طور پیشفرض، Turbopuffer هیچ اعتبارنامهای (Credential) برای این حسابها ندارد. این بدان معناست که مهندسان نمیتوانند به سادگی از SSH یا kubectl برای مدیریت محیط استفاده کنند.
برخی از فروشندگان سعی میکنند این مشکل را با درخواست از مشتری برای ایجاد یک حساب ابری اختصاصی و اعطای دسترسیهای ادمین دائمی حل کنند. با این حال، Turbopuffer از این روش پرهیز میکند زیرا هر حساب اختصاصی، نظارت امنیتی، انطباق قانونی و پیچیدگیهای صورتحسابی اضافی ایجاد میکند. برای حفظ یک صفحه کنترل واحد برای هر دو مدل BYOC و SaaS، آنها باید بتوانند هر خوشه را بدون نیاز به «ورود مستقیم» (Reach-in) مدیریت کنند. این رویکرد سختگیرانه در مدیریت دسترسیها، مشابه استراتژیهایی است که در سایر سیستمهای دادهمحور برای کنترل دقیق دسترسیها به کار میرود؛ برای مثال، شرکت Valv اخیراً دسترسی عاملهای هوش مصنوعی به دادهها را در سطح ردیف محدود کرد تا امنیت دادهها را در محیطهای پیچیده تضمین کند.
سازوکار عامل محلی (Local Agent)
این عامل محلی یک ماشین وضعیت ساده را با استفاده از یک «تعریف منبع سفارشی» (CRD) در کوبرنتیز به نام TurbopufferOperation پیاده میکند. بهجای اینکه سرور مرکزی دستورات را به خوشه «هل» (Push) کند، کنترلکننده محلی هر منبع را از طریق یک حلقه تطبیق (Reconciliation Loop) هدایت میکند تا زمانی که به یک وضعیت نهایی (موفقیت یا شکست) برسد.
این سازوکار تضمین میکند که خوشه میتواند به طور مستقل عملیات را به وضعیت نهایی برساند، حتی اگر اتصالش به صفحه کنترل مرکزی قطع شود. وضعیت عملیات به عنوان یک شیء بادوام در etcd خودِ خوشه ذخیره میشود؛ این یعنی عامل میتواند بلافاصله پس از یک کرش یا برقراری مجدد اتصال، کار را از همان نقطه ادامه دهد.
چرخه حیات عملیات
هر وظیفه — از ارتقای نسخه گرفته تا مرتبسازی (Tidying)، بازسازی ایندکس فضای نام (Namespace Reindexing)، فشردهسازی WAL یا جمعآوری زبالههای (Garbage Collection) LSM — از یک چرخه حیات سختگیرانه پیروی میکند. کلید کار در تعریف وضعیتهایی است که به اندازه کافی کلی باشند تا هر عملیات فعلی یا آینده را مدل کنند، اما به اندازه کافی محدود باشند تا کنترلکننده بتواند آنها را به پایان برساند:
- REQUIRES_APPROVAL: وضعیت اولیه که در آن عملیات منتظر یک تریگر دستی یا خودکار است. این وضعیت برای مشتریان BYOC که میخواهند روی عملیاتها نظارت داشته باشند، بسیار حیاتی است.
- PENDING: عملیات در صف قرار گرفته و آماده شروع است. پس از تایید، به این وضعیت منتقل میشود.
- RUNNING: عامل فعالانه در حال اجرای وظیفه از طریق تابع
start()است. - AWAITING_MAINTENANCE_WINDOW: یک وضعیت انتظار که در آن عملیات متوقف میشود تا یک پنجره زمانی خاص برای تعمیرات باز شود. این پنجرهها مستقیماً در CRD تعریف شدهاند.
- AWAITING_EXTERNAL_EXECUTION: وضعیتی برای وظایفی که به فرآیندهای خارجی وابسته هستند و سپس از طریق تابع
poll()رصد میشوند. - وضعیتهای نهایی: فرآیند در نهایت به SUCCESS (موفقیت) یا FAILURE (شکست) ختم میشود.
از آنجایی که وضعیت بادوام است، مشتریان BYOC میتوانند گیتهای تایید یا پنجرههای تعمیرات را مستقیماً در CRD بگنجانند و بدین ترتیب کنترل محیط خود را حفظ کنند، بدون اینکه نیاز باشد به فروشنده دسترسی ادمین دائمی بدهند.
چرا زیرساخت به عنوان کد (IaC) شکست خورد؟
شرکت Turbopuffer صراحتاً استفاده از Terraform یا Helm را به عنوان صفحه کنترل اصلی برای عملیات ناوگان رد کرد. اگرچه این ابزارها برای آمادهسازی اولیه (Provisioning) عالی هستند، اما صفهای کاری (Job Queues) مناسبی برای نگهداری دیتابیس نیستند.
اول اینکه، این شرکت فاقد یک واحد اختصاصی DevOps است و مهندسان دیتابیس خودشان کدها را مستقر میکنند. اکثر این مهندسان تجربه گستردهای در استفاده از ابزارهای IaC ندارند و قرار دادن آنها در مسیر بحرانی استقرار، سرعت ارسال کد را کاهش میداد. دوم اینکه، مدل پیشفرض Terraform مستلزم آن است که ارائهدهنده دستور terraform apply را از زیرساخت خود با هدف قرار دادن زیرساخت مشتری اجرا کند، که در یک محیط امن BYOC بدون اعطای دسترسیهای ادمین دائمی، غیرممکن است.
رویکرد GitOps نیز به دلایل زیر رد شد:
- تداخل در مالکیت: اگر ارائهدهنده مالک مخزن (Repo) باشد، مشتریان BYOC نمیتوانند ادغامها (Merges) را برای گیتهای تایید کنترل کنند. اگر مشتری مالک مخزن باشد، ارائهدهنده به دسترسی نوشتن نیاز دارد یا باید منتظر ادغامهای انسانی بماند.
- توصیفی در مقابل امری: بسیاری از عملیاتهای دیتابیس «وظایفی برای انجام» (مانند جمعآوری زبالههای LSM) هستند، نه «وضعیتهایی برای رسیدن».
- تورم مانیفستها: هر عملیات موردی (Ad hoc) نیاز به یک کامیت در گیت برای ایجاد شغل و کامیت دیگری برای پاکسازی شغل تکمیل شده داشت. فایلهای Terraform مانیفستهای توصیفی خوبی هستند، اما صفهای کاری افتضاحی میباشند.
صفحه کنترل سفارشی
برای حل این مشکل، Turbopuffer یک سرور API مرکزی ساخت که توسط یک دیتابیس MySQL از PlanetScale پشتیبانی میشود. گردش کار بر اساس مکانیزم «کشیدن-هل کردن» (Pull-Push) طراحی شده تا در برابر قطع اتصال کاملاً مقاوم باشد:
۱. Polling: به هر عامل خوشه یک کلید API اختصاصی داده شده است. عامل بهطور منظم از طریق درخواستهای GET احراز شده، سرور API را برای دریافت عملیاتهای در انتظار بررسی میکند.
۲. Idempotency (یکدستی): عملیاتها پس از دریافت به عنوان CR ذخیره میشوند. هر CR با شناسه عملیات نامگذاری میشود. اگر درخواست GET بعدی همان عملیات را برگرداند، عامل بهجای ایجاد یک مورد تکراری، کار را از وضعیتی که در etcd ذخیره شده ادامه میدهد.
۳. Status Mirroring: عامل بهطور دورهای تغییرات وضعیت بافر شده را از طریق POST به سرور API میفرستد. سرور این تغییرات را در یک جدول status_transitions در MySQL به صورت یک لاگ append-only ذخیره میکند.
اگر یک درخواست POST شکست بخورد، عامل تغییر وضعیت را بافر کرده و دوباره تلاش میکند. چون وضعیت فعلی صرفاً آخرین تغییر در لاگ است، درخواستهای POST تکراری مشکلی ایجاد نمیکنند. این امر تضمین میکند که صفحه کنترل میتواند وضعیت یک خوشه را از راه دور بازسازی کند، بدون اینکه هرگز نیاز به «ورود مستقیم» داشته باشد.
مهندسی تجربه کاربری (UX)
برای حفظ سرعت عملیاتی، تیم یک داشبورد سفارشی با Remix/React ساخت. این رابط کاربری با الهام از Linear، کاملاً کیبورد-محور است و برای هر عمل دارای کلیدهای میانبر (Hotkeys) است تا مهندسان بتوانند بدون استفاده از موس، ناوگان را مدیریت کنند.
ارتقای نسخهها رایجترین عملیات است و رابط کاربری برای آنها بهینه شده است. مهندسان میتوانند SHA کامیت مستقر شده در هر خوشه و میزان فاصله (Drift) آن را با آخرین SHA تایید شده مشاهده کنند. داشبورد متادادهها را از GitHub — شامل پیامهای کامیت، شماره PRها و تاریخها — میگیرد تا مهندسان مجبور به رمزگشایی SHAهای خام نباشند. آنها میتوانند چندین خوشه را در تمام مدلهای استقرار انتخاب کرده و ارتقا به یک SHA هدف را کاملاً از طریق کیبورد فعال کنند.
برای جلوگیری از «پرستاری» (Babysitting) استقرارها، تغییرات وضعیت به رشتهتویهای (Threads) اختصاصی در Slack ارسال میشود. اگر عملیاتی شکست بخورد، یک اعلان شدید در کانال فعال میشود. برای خوشههای BYOC، ادغام با Slack بهطور خودکار مشتری را از طریق کانال پشتیبانی اختصاصیشان مطلع میکند که تاییدیه لازم است.
عیبیابی و نظارت یکپارچه
برای عیبیابی، صفحه کنترل به عنوان یک پورتال به ابزارهای دیگر عمل میکند تا اصطکاک چرخشهای On-call کاهش یابد:
- Datadog: پرش مستقیم به لاگها، تریسها یا متریکهایی که از قبل روی خوشههای خاص درگیر در یک عملیات محدود شدهاند.
- Polar Signals: دسترسی سریع به پروفایلهای حافظه و CPU برای پادهای کوئری، زمانی که مشتریان تأخیر بالا را گزارش میکنند.
- مدیریت پیکربندی: توانایی بازرسی یک فضای نام و بهروزرسانی پیکربندی (مانند افزایش یک حد یا Limit) مستقیماً در رابط کاربری.
این داشبورد به عنوان یک نرمافزار درجه یک (First-class) در نظر گرفته شده است تا پیچیدگی عملیات خوشهها پشت یک رابط سریع و کیبورد-محور پنهان بماند.
مقیاسپذیری برای عملیات ناوگان
با رشد ناوگان به بیش از ۱۰۰ خوشه، انتخاب دستی به یک گلوگاه تبدیل شد. زحمت توالیبندی استقرارهایی که میتوانست ساعتها طول بکشد، منجر به ایجاد یک «کنترلکننده ناوگان» (Fleet Controller) شد.
اکنون هر عملیات میتواند به عنوان یک «عملیات ناوگان» ثبت شود. کنترلکننده، عملیات را در توالی «موجهایی» (Waves) که شامل یک یا چند خوشه هستند، اجرا میکند. بین این موجها، یک گیت (Gate) دو مورد را تایید میکند: اول اینکه تمام خوشههای موج قبلی با موفقیت ارتقا یافته باشند و دوم اینکه مانیتورها وضعیت پایداری را تایید کنند. اگر مانیتوری فعال شود یا خوشهای شکست بخورد، کنترلکننده ناوگان استقرار را متوقف کرده و تیم را از طریق Slack مطلع میکند تا اثر تخریبی (Blast Radius) یک استقرار بد محدود شود.
نکته مهم این است که عامل خوشه همچنان ساده باقی مانده است. عامل هیچ مفهومی از «ناوگان» یا «موجها» ندارد؛ او همچنان عملیاتهای در انتظار خود را از سرور API میگیرد و تغییرات را به MySQL میفرستد. ارکستراسیون صدها خوشه صرفاً یک حلقه روی همین ابزارهای اولیه است.
تحلیل: تغییر به سمت زیرساختهای خودمختار
رویکرد Turbopuffer نشاندهنده تغییری در نحوه مدیریت نرمافزارهای با دسترسیپذیری بالا (High-availability) در ابر است. با انتقال «هوش» استقرار به لبه (عامل خوشه) و نگه داشتن صفحه مرکزی به عنوان یک آینه ساده از وضعیت، آنها موازنه بین امنیت و سرعت را حذف کردند. این سیستم به آنها اجازه میدهد بیش از ۱ تریلیون سند، ۱۰ میلیون نوشتن در ثانیه و ۲۵ هزار کوئری در ثانیه را مدیریت کنند و در عین حال دهها ارتقای روزانه را ارسال نمایند.
برای صنعت، این ثابت میکند که BYOC نباید به یک کابوس انطباقی یا یک فرآیند دستی و خستهکننده تبدیل شود. استفاده از CRDهای کوبرنتیز به عنوان یک صف وظایف بادوام، سطحی از جزئیات — مانند پنجرههای تعمیرات برای هر خوشه — را فراهم میکند که دستیابی به آن با خط لولههای CI/CD استاندارد تقریباً غیرممکن است.
این معماری در واقع ناوگان دیتابیس را به یک سیستم توزیعشده از عاملهای خودمختار تبدیل میکند. نتیجه، تجربه توسعهدهندهای است که در آن زیرساخت نامرئی میشود و مهندسان میتوانند بهجای مانیفستهای YAML و کلیدهای SSH، بر روی طرحهای کوئری و ساختارهای ایندکس تمرکز کنند. این سادگی همان چیزی است که آنها معتقدند اجازه میدهد از صدها خوشه به هزاران خوشه مقیاس پیدا کنند بدون اینکه سرعت ارسال کد را فدا کنند.
گام بعدی شما
- بررسی معماری Agent-based برای مدیریت زیرساختهای توزیعشده در محیطهای محدود.
- مطالعه درباره استفاده از Kubernetes CRDها به عنوان صف وظایف (Job Queue) بادوام.
- تحلیل مدلهای استقرار BYOC برای کاهش هزینههای Compliance در محصولات SaaS.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو