وقتی یک سرویس اینترنتی در مقیاس چند میلیارد درخواست فعالیت میکند، حتی چند بایت اضافه برای هر داده میتواند در نهایت به دهها ترابایت حافظه تبدیل شود. اتفاقی که اخیراً در زیرساخت DNS شرکت Cloudflare رخ داده، نمونه روشنی از همین موضوع است: مهندسان شرکت با بازطراحی نحوه ذخیرهسازی رکوردهای DNS توانستند حدود ۱۰۰ ترابایت RAM آزاد کنند؛ بدون افزودن سرور یا افزایش ظرفیت سختافزاری.
این تغییر در سامانهای با نام Big Pineapple انجام شده؛ زیرساختی که پشت سرویس DNS عمومی 1.1.1.1 و بخشی از سرویسهای DNS کلادفلر قرار دارد. این سامانه در هر لحظه بیش از ۲۵۰ میلیارد رکورد DNS را در حافظه نگهداری میکند. در چنین مقیاسی، کوچکترین بهینهسازی در اندازه هر رکورد میتواند نتیجهای بسیار بزرگ داشته باشد.
مشکل از کجا شروع میشد؟
#در طراحی قبلی، اندازه معمول هر رکورد کش DNS حدود ۹۵۳ بایت بود. مهندسان Cloudflare پس از بررسی نحوه استفاده واقعی از این دادهها دریافتند بخش قابل توجهی از این فضای حافظه ضرورتی ندارد.
آنها با پنج تغییر در کد نوشتهشده با Rust توانستند اندازه معمول هر رکورد را به حدود ۴۲۰ بایت برسانند؛ یعنی بیش از نیمی از فضای مصرفشده برای هر رکورد حذف شد. این تفاوت وقتی روی صدها میلیارد رکورد اعمال شود، دیگر یک بهینهسازی کوچک نیست و به دهها ترابایت حافظه آزاد تبدیل میشود.
چرا ساختار داده مهمتر از قدرت RAM بود؟
#یکی از نکات فنی مهم این پروژه به استفاده از ساختارهایی مانند Vec و String در Rust مربوط میشد. این ساختارها برای دادههایی مناسباند که ممکن است در طول عمر خود رشد کنند؛ اما یک رکورد DNS پس از قرار گرفتن در کش معمولاً قرار نیست مرتباً بزرگتر شود.
Cloudflare در نتیجه، برای برخی از این دادهها از ساختارهای ثابتتر استفاده کرد. همین تغییر بهتنهایی بیش از ۱۵ ترابایت RAM صرفهجویی ایجاد کرد.
به زبان ساده، مشکل این نبود که Cloudflare RAM کافی نداشت؛ مشکل این بود که هر رکورد بیش از مقدار مورد نیازش از RAM استفاده میکرد.
یک رکورد کوچک، در مقیاس بزرگ چه بلایی سر حافظه میآورد؟
#برای درک بهتر موضوع، فرض کنید فقط یک بایت از هر رکورد DNS اضافی مصرف شود. با بیش از ۲۵۰ میلیارد رکورد، همین یک بایت اضافه میتواند بیش از ۲۵۰ گیگابایت حافظه مصرف کند.
حالا اگر به جای یک بایت، دهها یا صدها بایت فضای اضافی در ساختار هر رکورد وجود داشته باشد، مشخص است که چرا بهینهسازی ساختار داده میتواند نتیجهای در مقیاس ترابایت داشته باشد. این دقیقاً همان جایی است که مهندسی نرمافزار با اقتصاد زیرساخت گره میخورد.
Cloudflare فقط RAM ذخیره نکرد
#اهمیت پروژه فقط در کاهش مصرف حافظه نیست. طبق گزارش منتشرشده، نرخ درج رکوردها از حدود ۶۲۵ هزار ورودی در ثانیه به ۸۹۳ هزار ورودی در ثانیه افزایش پیدا کرده و تأخیر جستوجو نیز از ۸۲۸ به ۶۷۰ نانوثانیه کاهش یافته است.
این بخش از ماجرا از نظر معماری سیستم بسیار مهم است. کاهش مصرف حافظه لزوماً نباید به معنای کاهش کارایی باشد. اگر دادهها فشردهتر و با الگوی دسترسی مناسبتری در حافظه قرار بگیرند، CPU میتواند داده مورد نیاز را سریعتر پیدا کند و فشار روی زیرسیستم حافظه نیز کاهش یابد.
چرا Cloudflare به جای خرید RAM، کد را تغییر داد؟
#در مقیاس دیتاسنتر، خرید سختافزار همیشه سادهترین راهحل نیست. اضافه کردن RAM یعنی خرید ماژولهای جدید، احتمالاً سرورهای بیشتر، فضای رک، مصرف برق، سیستم خنککننده، شبکه و هزینه نگهداری.
در مقابل، اگر نرمافزار بتواند همان حجم کاری را با منابع کمتری انجام دهد، ظرفیت موجود عملاً افزایش پیدا میکند.
Cloudflare حالا قصد دارد بخشی از حافظه آزادشده را برای بزرگتر کردن کش DNS استفاده کند. کش بزرگتر میتواند رکوردهای بیشتری را محلی نگه دارد و در نتیجه تعداد درخواستهایی که باید به سرورهای DNS authoritative ارسال شوند کاهش پیدا کند.
این رویکرد با معماری کلی Cloudflare نیز هماهنگ است. این شرکت سالها روی کاهش بار سرورهای مبدأ از طریق کش، پردازش در لبه شبکه و بهینهسازی مسیرهای ارتباطی کار کرده است. در مستندات فعلی Cloudflare نیز افزایش Cache Hit Ratio یکی از روشهای اصلی کاهش مصرف منابع و هزینه معرفی شده است.
این اتفاق چه ارتباطی با سرورهای جدید Cloudflare دارد؟
#نکته جالب اینجاست که Cloudflare همزمان در حال حرکت به سمت نسل جدید سرورهای خود است. این شرکت در مارس ۲۰۲۶ از Gen 13 با پردازنده ۱۹۲ هستهای AMD EPYC Turin، حافظه ۷۶۸ گیگابایتی DDR5-6400، فضای ذخیرهسازی ۲۴ ترابایت NVMe و شبکه دوگانه 100GbE رونمایی کرد. این نسل در برخی بارهای کاری تا دو برابر توان عملیاتی Gen 12 را ارائه میدهد.
اما نکته مهم این است که Cloudflare برای رسیدن به این عملکرد فقط CPU قدرتمندتر نخریده است. این شرکت ابتدا لایه پردازش درخواست خود را با پروژه FL2 از نو و با Rust بازنویسی کرد. طبق توضیح مهندسان Cloudflare، معماری جدید با الگوهای دسترسی بهتر به حافظه و تخصیص کمتر پویا، وابستگی نرمافزار به حافظه کش بزرگ CPU را کاهش داده است.
بنابراین درس اصلی Cloudflare را میتوان اینطور خلاصه کرد: سختافزار سریعتر زمانی بیشترین ارزش را دارد که نرمافزار واقعاً بتواند از آن استفاده کند.
آیا این روش برای هر سروری جواب میدهد؟
#خیر. نمیتوان نتیجه گرفت که هر شرکت با بهینهسازی نرمافزار میتواند صدها ترابایت RAM آزاد کند. دستاورد Cloudflare نتیجه مقیاس بسیار بزرگ زیرساخت، حجم عظیم داده، الگوی مشخص دسترسی به رکوردهای DNS و بررسی دقیق نحوه مصرف حافظه است.
اما اصل مهندسی آن برای بسیاری از سیستمها قابل استفاده است: قبل از افزایش CPU یا RAM باید مشخص شود گلوگاه واقعی کجاست.
ممکن است مشکل از الگوریتم باشد، ممکن است ساختار داده فضای زیادی مصرف کند، ممکن است Cache Hit پایین باشد، یا ممکن است برنامه تعداد زیادی آبجکت موقت ایجاد کند. در چنین شرایطی خرید سختافزار میتواند فقط هزینه مشکل را بیشتر کند، نه اینکه ریشه آن را برطرف کند.
| رویکرد | اثر مستقیم | هزینه احتمالی | مزیت بلندمدت |
| افزایش RAM | افزایش ظرفیت حافظه بدون تغییر نرمافزار | خرید سختافزار، برق و نگهداری | سریع، اما وابسته به ظرفیت سختافزار |
| افزایش CPU | افزایش توان پردازشی | خرید یا ارتقای سرور | مناسب برای بارهای CPU-bound |
| بهینهسازی ساختار داده | کاهش مصرف حافظه و گاهی افزایش سرعت | هزینه مهندسی و تست نرمافزار | کاهش دائمی مصرف منابع در مقیاس بالا |
| بهینهسازی Cache | کاهش درخواست به سرورهای مبدأ | نیازمند طراحی و پایش دقیق | کاهش بار، تأخیر و هزینه زیرساخت |
| بازنویسی بخشهای حساس نرمافزار | استفاده مؤثرتر از CPU و RAM | هزینه توسعه و ریسک مهاجرت | امکان بهرهگیری بهتر از نسل جدید سختافزار |
در نهایت، داستان Cloudflare یک نکته بسیار مهم برای مهندسان زیرساخت دارد: وقتی سیستم به اندازه کافی بزرگ شده باشد، حتی یک بایت اضافه هم میتواند هزینهای واقعی داشته باشد. در چنین مقیاسی، بهینهسازی نرمافزار دیگر صرفاً کاری برای سریعتر شدن برنامه نیست؛ مستقیماً روی تعداد سرورها، میزان RAM، مصرف انرژی و هزینه عملیاتی اثر میگذارد.
