توسعه Sprites Block Device؛ چرا تیم Fly.io سیستم فایل سفارشی خود را کنار گذاشت؟

زمینه و ایده اولیه

توسعه زیرساخت در شرکت‌ها گاهی اوقات ما را به سمت ساخت راه‌حل‌های پیچیده و سفارشی سوق می‌دهد. تیم Fly.io در پروژه Sprites برای مدیریت ذخیره‌سازی، ابتدا سراغ یک سیستم فایل سفارشی رفته بود؛ ساختاری که روی کاغذ هوشمندانه به نظر می‌رسید اما در عمل مشکلات نگهداری زیادی ایجاد کرد. در مقاله اخیر، تیم معرفی می‌کند که چگونه این «پاستای خانگی» پیچیده کنار گذاشته شده و با یک راه‌حل سرراست‌تر به نام Sprites Block Device (SBD) جایگزین شده است.

معماری قبلی و چالش‌های آن

بنیان ذخیره‌سازی در Sprites بر پایه Object Storage بنا شده است؛ به این دلیل که اسپریت‌ها بتوانند به خواب بروند، روی سرور دیگری بیدار شوند و همچنان به فایل‌های خود دسترسی داشته باشند. اما مشکل اینجاست که Object Storage امکان تغییر یک بایت منفرد را به صورت مستقیم ندارد و برای ویرایش فایل‌ها به لایه‌ای واسط نیاز است.

در نسخه اولیه، تیم از نسخه‌ای به شدت بهینه‌سازی‌شده از JuiceFS همراه با دیتابیس SQLite (محافظت‌شده با Litestream) برای نگهداری متادیتا استفاده می‌کرد. روی این لایه هم یک تصویر دیسک ۱۰۰ گیگابایتی قرار داشت که توسط ext4 فرمت و روی یک loop device مانت می‌شد. معماری کلی شامل سه بخش مجزا بود:

• بلوک‌های داده در Object Storage
• دیتابیس متادیتای JuiceFS
• دیتابیس جداگانه برای مدیریت Checkpointها

این سه لایه به صورت جداگانه پایدارسازی (Durable) می‌شدند و همگام نگه داشتن آن‌ها کار دشواری بود. اگر سرور در بازه زمانی بین ثبت متادیتا و آپلود واقعی بایت‌ها در حالت writeback متوقف می‌شد، متادیتا به بلوکی اشاره می‌کرد که وجود خارجی نداشت و خطای 404 رخ می‌داد. در نتیجه، فایل‌سیستم ext4 به حالت read-only می‌رفت و کل ساختار دچار مشکل می‌شد.

تست‌های سخت‌گیرانه و سگ‌خواری (Dogfooding)

تیم Fly.io برای سنجش پایداری، یک ابزار تست خودکار ساخت که ناوگانی متشکل از ۴۰۰ اسپریت را تحت عملیات مداوم نوشتن، Checkpoint گرفتن، خواباندن و بیدار کردن قرار داد. پس از ۵ هزار چرخه، مشخص شد که برخی از اسپریت‌ها توانایی خود برای Checkpointگیری را برای همیشه از دست داده‌اند. تلاش برای نوشتن کدهای تعمیری بیشتر نیز راه به جایی نبرد؛ زیرا ساختاری که برای کارکردن به ابزارهای تعمیر پیچیده نیاز داشته باشد، از ریشه مشکل دارد.

راه حل جدید: Sprites Block Device (SBD)

ایده پشت SBD بسیار ساده است: بازگشت به اصول اولیه و استفاده از مکانیزم‌های استاندارد لینوکس. SBD با استفاده از پروتکل NBD یک Object Storage را به شکل یک Block Device به هسته لینوکس معرفی می‌کند. اسپریت‌ها می‌توانند این دیسک را با ext4 فرمت کرده و مستقیماً مانت کنند.

جزئیات فنی کلیدی در SBD:

• متادیتا و داده در کنار هم: متادیتا در همان Bucket همراه با بلوک‌ها ذخیره می‌شود و دیتابیس مجزایی برای همگام‌سازی وجود ندارد.
• دیمون محلی (sbd serve): این دیمون درخواست‌های خواندن و نوشتن کرنل را از طریق یک کش محلی پاسخ می‌دهد، بلوک‌های کثیف (dirty blocks) را در پس‌زمینه آپلود می‌کند و در مواقع نیاز عملیات Flush را انجام می‌دهد.
• Checkpointهای ساده‌تر: به جای سیستم‌های پیچیده کپی روی نوشتن (Copy-on-Write)، یک Checkpoint در SBD در واقع یک اسنپ‌شات بلوکی از کل ولوم همراه با یک شماره نسخه است.

چرا این موضوع برای مهندسان اهمیت دارد؟

این مقاله درس مهمی درباره طراحی زیرساخت دارد: پیچیدگی فنی لزوماً به معنای عملکرد بهتر نیست. تست‌های مداوم نشان داد که معماری مبتنی بر SBD و فایل‌سیستم استاندارد ext4 پایداری به مراتب بالاتری نسبت به ساختارهای سفارشیِ پیچیده دارد. گاهی اوقات بهترین کار این است که از ابزارهایی که لینوکس از قبل برای ما فراهم کرده است استفاده کنیم و از بازآفرینی چرخ پرهیز کنیم.

در بحث‌های هکرنیوز نیز کاربران به نکات جالبی اشاره کردند؛ از جمله تحسین سبک نگارش صمیمی مقالات Fly.io، هرچند برخی با شوخ‌طبعی به لحن خاص متن اشاره داشتند. با این حال، ارزش فنی و درس‌های معماری این تجربه برای توسعه‌دهندگان زیرساخت کاملاً مشهود است.