celld: میزبانی شخصی اشیاء بادوام با حذف لایه‌ی اجماع

اگر توسعه‌دهنده هستید و از پرداخت هزینه‌های سنگین سرویس‌های ابری برای مدیریت وضعیت (State) خسته شده‌اید، اکنون راهی برای بازگرداندن کنترل زیرساخت به دست خود دارید. طبق اعلام تیم denoland در ۵ اوت ۲۰۲۶، ابزار celld این امکان را فراهم می‌کند تا قابلیت‌های پیشرفته‌ی Cloudflare Workers را بدون نیاز به وابستگی به یک شرکت خاص، روی سخت‌افزار شخصی اجرا کنید.

مدیریت داده‌ها در مقیاس جهانی معمولاً به سرویس‌های مدیریت‌شده‌ی گران‌قیمت یا خوشه‌های پیچیده‌ی اجماع (Consensus) نیاز دارد. اما celld بازی را تغییر می‌دهد. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن و تمرکززدایی از زیرساخت‌ها اشاره کردیم، میل بهOwnership کامل داده‌ها در حال تبدیل شدن به یک استاندارد فنی است. در سیستم‌های توزیع‌شده‌ی رایج، یک «لایه کنترل» یا پروتکل‌های سنگینی مثل Raft تصمیم می‌گیرند کدام گره (Node) مالک کدام قطعه از داده باشد. این پیچیدگی اغلب باعث ایجاد گلوگاه‌های عملکردی می‌شود. تصور کنید پایگاه‌داده شما یک دفترچه یادداشت بزرگ مشترک باشد که همه برای نوشتن در آن با هم می‌جنگند؛ اما celld به جای آن، به هر شیء یک دفترچه یادداشت کوچک و خصوصی می‌دهد.

بر اساس مستندات رسمی در گیت‌هب، این ابزار هر شیء بادوام (Durable Object) را به عنوان یک پایگاه‌داده مستقل SQLite راه‌اندازی می‌کند. این پایگاه‌داده‌ها در یک فضای ذخیره‌سازی سازگار با S3 که متعلق به کاربر است، تکثیر می‌شوند. از آنجا که خودِ S3 منبع حقیقت (Source of Truth) است، گره‌ها می‌توانند با عملیات‌های ساده‌ی «مقایسه و جایگزینی» (Compare-and-swap) هماهنگ شوند. این معماری تضمین می‌کند که در هر لحظه فقط یک گره مالک یک سلول خاص باشد، بدون اینکه نیازی به پروتکل‌های تشخیص شکست یا سرویس‌های اجماع باشد.

منطق عملیاتی و زمینه

گره‌های celld به‌گونه‌ای طراحی شده‌اند که به‌سادگی قابل جایگزینی باشند. هر گره موتور V8 را در دل خود دارد و بسته‌های ساخته‌شده با Wrangler را اجرا می‌کند. کل این ناوگان از یک S3 مشترک برای ذخیره فایل‌های استقرار، وضعیت سلول‌ها و سوابق مالکیت استفاده می‌کنند.

وقتی یک سلول جابه‌جا می‌شود یا بیدار می‌شود، مالک جدید پایگاه‌داده SQLite را از S3 بازیابی کرده و اجرا را از سر می‌گیرد. سلول‌های غیرفعال برای صرفه‌جویی در منابع به حالت خواب می‌روند. این رویکرد «تکه-تکه شده از ابتدا» (Sharded by construction) باعث می‌شود که شکست یک بخش، کل سیستم را مختل نکند.

جزئیات فنی و معماری

• زمان اجرا: هر گره موتور V8 را جای‌گذاری کرده و بسته‌های Wrangler را اجرا می‌کند.

• مدیریت وضعیت: تمام وضعیت‌ها و سوابق مالکیت در S3 ذخیره می‌شوند و S3 تنها مرجع نهایی است.

• استقرار: ابزار از esbuild برای پردازش کد Worker استفاده کرده و اشیاء را مستقیماً در S3 می‌نویسد.

• امنیت: تمام درخواست‌های بین گره‌ها با نسخه پروتکل، امضای HMAC، محدودیت زمانی و محافظت در برابر حملات بازپخش (Replay) تأمین شده‌اند.

• ایمنی شبکه: ترافیک HTTP بین گره‌ها TLS را پایان نمی‌دهد. بنابراین آدرس‌ها باید در یک شبکه خصوصی امن یا لایه‌های رمزنگاری‌شده‌ای مثل WireGuard یا Tailscale باشند.

برای جلوگیری از فروپاشی سیستم در بار زیاد، celld مکانیزم «تخلیه فشار» دارد. اپراتورها می‌توانند حد نصاب سلول‌های مقیم را تعیین کنند (مثلاً CELLD_MAX_RESIDENT_CELLS=1000).

در شرایط فشار زیاد، celld سلول‌های غیرفعال را که کمتر از بقیه استفاده شده‌اند (LRU)، بازپس گرفته و در S3 ذخیره می‌کند تا فضا برای سلول‌های فعال‌تر باز شود. ध्यान داشته باشید که سلول‌هایی با کارهای فعال یا وب‌سوکت‌های باز هرگز تخلیه نمی‌شوند.

نصب و پیاده‌سازی

این پروژه از تصاویر Docker برای لینوکس x86-64 و ARM64 پشتیبانی می‌کند. کاربران باید اعتبارنامه‌های AWS و یک اندپوینت S3 (مثل Cloudflare R2) را برای ایجاد لایه ذخیره‌سازی دائمی فراهم کنند.

نصب از طریق اسکریپت شل امکان‌پذیر است: curl -fsSL celld.dev/install.sh | sh. این نصب‌کننده نسخه‌های تأییدشده را در مسیر ~/.local/lib/celld/releases نگه می‌دارد و برای تغییر نسخه از اشاره‌گرهای اتمیک استفاده می‌کند.

مدیر سیستم می‌تواند با دستور celld diagnose کل ناوگان را مانیتور کند. این ابزار هر اجاره گره را بررسی کرده و گزارش دقیقی از مصرف RAM (RSS)، CPU و تعداد توصیف‌کننده‌های فایل (File Descriptors) ارائه می‌دهد.

این چرخش به سمت معماری‌های «تکه-تکه شده»، شعاع تخریب یک شکست را به یک شیء واحد محدود می‌کند، نه کل پایگاه‌داده. با حذف سرویس اجماع از مسیر بحرانی، denoland مانع ورود توسعه‌دهندگان به دنیای اپلیکیشن‌های stateful و در دسترس (Highly Available) را بدون پرداخت «مالیات ابری» یا درگیر شدن با پیچیدگی‌های کوبرنتیز (Kubernetes) از بین برده است.

برای توسعه‌دهنده، این یعنی حرکت از یک «جعبه سیاه مدیریت‌شده» به یک سیستم شفاف و قابل تأیید. حتی نصب‌کننده از تأییدیه‌های گیت‌هاب (gh attestation verify) پشتیبانی می‌کند تا کاربر مطمئن شود فایل باینری دست‌کاری نشده است.

توسعه‌دهندگانی که می‌خواهند بیشتر بدانند، می‌توانند نمونه‌های کد را در پوشه examples یا مشخصات کامل پروتکل را در فایل protocol.rs در گیت‌هب بررسی کنند. کسانی که از سورس می‌سازند، می‌توانند با cargo test --locked شبیه‌سازی‌های قطعی پروتکل توزیع‌شده را زیر فشار تزریق خطا (Fault Injection) آزمایش کنند.

گام بعدی شما

• اگر پروژه‌ای دارید که نیاز به ذخیره‌سازی وضعیت در لبه (Edge) دارد، celld را روی یک سرور کوچک با Tailscale تست کنید.
• مستندات S3-compatible storage مورد نیاز خود (مثل MinIO یا R2) را بررسی کنید تا لایه ذخیره‌سازی را آماده کنید.
• برای اطمینان از سلامت باینری، حتماً از دستور gh attestation verify در هنگام نصب استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell برای بهینه‌سازی استنتاج توزیع‌شده مراجعه کنید.