পাঁচটি Rust বদলে ১০০ TB RAM মুক্ত—Cloudflare-এর DNS cache পাঠ

Cloudflare ২৭ আগস্ট ২০২৬-এ জানায়, 1.1.1.1 ও কয়েকটি DNS সেবার cache platform Big Pineapple-এ পাঁচটি Rust-level layout পরিবর্তন করেছে। কোম্পানির engineering deep dive অনুযায়ী, benchmark-এ সাধারণ cache entry-র footprint ৯৫৩ byte থেকে ৪২০ byte হয়েছে এবং rollout স্থিতিশীল হওয়ার পর fleet-এর aggregate working-set memory প্রায় ১০০ TB কমেছে।

একই ২৭ আগস্টের প্রকাশনায় Cloudflare বলেছে, insert throughput প্রতি সেকেন্ডে ৬২৫,০০০ থেকে ৮৯৩,০০০ entry হয়েছে এবং lookup latency ৮২৮ থেকে ৬৭০ nanosecond-এ নেমেছে। ২৯ আগস্টের TechSpot প্রতিবেদন একই ফল ও পরিবর্তনগুলো তুলে ধরে; সেখানে rollout-এর সময়কাল মে মাসের মাঝামাঝি থেকে জুলাইয়ের শুরু এবং প্রতি instance-এর p99 resident memory ৯.৩ GB থেকে ৫.৩ GB হওয়ার কথাও উল্লেখ করা হয়েছে।

পাঁচ পরিবর্তনে entry যেভাবে ছোট হলো

Big Pineapple যেকোনো সময়ে ২৫০ বিলিয়নের বেশি DNS cache entry ধরে। এই মাপে entry-পিছু একটি অপ্রয়োজনীয় byte-ও fleet জুড়ে ২৫০ GB-এর বেশি memory নেয়। তাই বড় সাশ্রয়টি কোনো নতুন caching algorithm থেকে নয়; capacity field, pointer, পুনরাবৃত্ত data, padding এবং বিচ্ছিন্ন allocation একে একে সরানো থেকে এসেছে।

1. Growable container থেকে fixed-size allocation: cache-এ ঢোকার পর response আর বড় হয় না, অথচ Rust-এর Vec ও String pointer ও length-এর পাশাপাশি ভবিষ্যৎ বৃদ্ধির capacity রাখে। আটটি Vec ও String field-কে Box<[T]> এবং Box<str>-এ বদলে প্রতি entry-তে ৬৪ byte metadata ও অব্যবহৃত reserved space বাদ দেওয়া হয়েছে। ২৫০ বিলিয়নের বেশি entry-তে এই ধাপের হিসাব করা সাশ্রয় ১৫ TB-এর বেশি।
2. তিনটি record list থেকে একটি buffer: answer, authority ও additional section আলাদা allocation-এ না রেখে একটি contiguous list-এ রাখা হয়েছে। দুটি 2-byte u16 offset section boundary চিহ্নিত করে; দুটি pointer-length জোড়া সরে যাওয়ায় প্রতি entry-তে ২৮ byte কমেছে।
3. পুনরাবৃত্ত owner name বাদ: অধিকাংশ record-এর owner query করা domain-এর সমান। এমন ক্ষেত্রে পূর্ণ নাম আর value-তে রাখা হয় না; response তৈরির সময় cache key থেকে ফেরানো হয়। CNAME chain-এর মতো ক্ষেত্রে owner আলাদা হলে নামটি এখনও সংরক্ষিত থাকে।
4. বড় enum variant heap-এ সরানো: Rust enum তার বৃহত্তম variant-এর সমান জায়গা নেয়। বিরল NAPTR payload ১৩৬ byte হওয়ায় tag ও padding-সহ enum ছিল ১৪৪ byte—ফলে 4-byte IPv4 A record-ও একই slot নিত। মধ্যবর্তী পরিবর্তনে A ও AAAA inline রেখে বড় variant box করা হয়; common record ছোট হলেও এতে নতুন allocation ও pointer chasing তৈরি হয়েছিল।
5. Boxed variant থেকে wire-format bytes: চূড়ান্ত layout-এ parsed enum-এর বদলে record data একটি Box<[u8]>-এ রাখা হয়েছে। প্রতিটি record-এর আগে 2-byte length এবং পরে raw DNS wire-format bytes থাকে। এতে enum padding ও record-পিছু heap allocation দুটিই সরে যায়, আর data পাশাপাশি থাকে।

RAM কমার সঙ্গে latency-ও কেন কমল

এই optimization-এ memory ও speed পরস্পরের বিপরীতে যায়নি, কারণ পুরোনো layout-এর বহু ছোট allocation processor-কে বারবার pointer অনুসরণ করাত। pointer অন্য cache line-এ গেলে data আনতে অপেক্ষা করতে হয়। নতুন contiguous buffer allocation pressure কমায় এবং lookup-এর প্রয়োজনীয় bytes কাছাকাছি রাখে—তাই locality উন্নত হওয়ার সঙ্গে latency-ও কমেছে।

Wire-format storage-এর বিনিময়মূল্য আছে। record আর সরাসরি index করা যায় না; buffer ক্রমানুসারে পড়তে হয়, ফলে A ও AAAA record-এর round-robin rotation-এর মতো কাজ কিছুটা জটিল হয়েছে। তবে entry-পিছু record অল্প হওয়ায় প্রকাশিত পরীক্ষায় scan-এর খরচ সামান্য ছিল। A, AAAA, TXT ও DNSSEC record response-এ সরাসরি copy করা যায়; domain name থাকা CNAME, NS, MX ও SOA record-এ name compression-এর জন্য parsing এখনও প্রয়োজন।

Benchmark production traffic-এর হুবহু replay নয়। Cache ভরতে আনুমানিক traffic mix হিসেবে ৫৬% A, ২৫% AAAA ও ১৯% TXT record ব্যবহার করা হয়েছিল; প্রতি entry-তে ছিল এক থেকে চারটি record। Process memory-তে cache ছাড়াও allocator state, occupancy ও অন্য data থাকে—এ কারণেই ৫৬% benchmark entry reduction আর production process-এর ৪৩% p99 reduction একই metric নয়।

ছোট cache-এ কোন শিক্ষা কাজে লাগতে পারে

সবচেয়ে বহনযোগ্য নীতি হলো, insert-এর পর immutable data-কে growable container-এ রাখার খরচ মাপা। Vec থেকে boxed slice, আলাদা list থেকে offset-সহ একটি buffer, অথবা key-তে থাকা data value-তে পুনরায় না রাখা—এসব কৌশল অন্য systems language ও storage engine-এও প্রযোজ্য হতে পারে। কিন্তু প্রায় ১০০ TB ফলটি ২৫০ বিলিয়নের বেশি live entry-র গুণিতক; ছোট service-এ একই পরিবর্তনের absolute সাশ্রয় অনেক কম হবে।

বড় enum variant box করাও একা চূড়ান্ত সমাধান নয়। এতে inline padding কমলেও allocation count, allocator-এর size-class rounding এবং pointer chasing বাড়তে পারে। Cloudflare-এর পঞ্চম পরিবর্তন চতুর্থ ধাপের সেই খরচ সরিয়েছে। অর্থাৎ intermediate struct ছোট দেখালেই optimization সফল নয়; সম্পূর্ণ representation এবং বাস্তব workload একসঙ্গে মাপতে হবে।

নিজস্ব cache profile করার সংক্ষিপ্ত checklist:

• object size-এর সঙ্গে requested ও allocator-rounded size এবং allocation count মাপা;
• live entry count দিয়ে field-পিছু সম্ভাব্য সাশ্রয়ের fleet-level সীমা হিসাব করা;
• insert-এর পর কোন field immutable এবং কোন reserved capacity অব্যবহৃত থাকে, তা দেখা;
• duplicate key-value data ও common বনাম rare enum variant-এর বাস্তব অনুপাত মাপা;
• memory-এর পাশাপাশি insert throughput, lookup latency ও production RSS তুলনা করা।

মুক্ত memory এখন কোথায় যাবে

Cloudflare কম RAM-যুক্ত server configuration ঘোষণা করেনি। ২৮ আগস্টের Tom’s Hardware প্রতিবেদনে প্রায় ১০০ TB-কে ৭৬৮ GB RAM-যুক্ত ১৩০টি Gen 13 server-এর সম্মিলিত memory-র সমতুল্য বলা হয়েছে; মুক্ত capacity বড় DNS cache-এ পুনর্বিনিয়োগ করে hit rate বাড়ানো ও authoritative server-এ upstream query কমানো Cloudflare-এর পরিকল্পনা।

এখন পর্যন্ত নিশ্চিত ফল দুটি স্তরে সীমিত: controlled benchmark-এ entry footprint ও latency কমেছে, আর ১৮ মে থেকে ৬ জুলাই পর্যন্ত production rollout-এর পর fleet-এর aggregate working set নিচে নেমেছে। বড় cache চালুর ফলে বাস্তব hit rate ও upstream query volume কতটা বদলাবে, সেই production ফল এখনও প্রকাশিত হয়নি।

আরও পড়ুন:

• Hugging Face মডেল লোকাল চালাবেন? RAM সীমাই প্রথম সিদ্ধান্ত
• Gemini Enterprise-এ খালি আসনের খরচ নেই: Google বদলাল AI বিলিং
• Salesforce ২২.৬% লাফাল: AI কি SaaS ধ্বংসের বদলে আয় বাড়াচ্ছে?