كلاودفلير تقلّص زمن بناء بيانات DNS إلى النصف وتخفض استهلاك الذاكرة 85%

كشفت كلاودفلير أنها أعادت تصميم مسار نشر تغييرات DNS داخل مكوّن Zone Builder، فخفّضت ذروة استهلاك الذاكرة 85% وقلّصت إلى النصف الزمن بين إجراء التغيير وكتابة بياناته في Quicksilver، مخزن المفاتيح والقيم الموزّع لديها.

بحسب الشركة، ارتفع عدد تغييرات سجلات DNS التي يستقبلها Zone Builder من نحو 250 تغييرًا في الثانية عام 2022 إلى نحو 700 اليوم، إضافة إلى نحو 100 حدث آخر مثل تغيير إعدادات المنطقة. غير أن المشكلة، كما توضح، لم تكن عدد الأحداث، بل نوع العمل الذي يتطلبه بعضها وكيف يكبر مع حجم المنطقة. وتضم بعض المناطق اليوم أكثر من 20 مليون سجل، وتتوقع الشركة أن تصل إلى مئات الملايين.

ما الذي تغيّر؟#

كان تغيير إعداد في المنطقة يستدعي سابقًا بناءً كاملًا يقرأ كل السجلات ويحوّلها ويقارنها بما هو مخزّن. بنت كلاودفلير الآن مخطِّطًا يختار أصغر بناء يمكن إثبات سلامته، ومجدولًا موحّدًا يدمج الأعمال المتعلقة بالمنطقة نفسها. فلم تعد تغييرات الإعدادات تعيد بناء مناطق تضم عشرات الملايين من السجلات. ويختار المخطِّط بين خمسة أنواع من البناء:

• بناء الموارد فقط، أي سجلات أسماء محددة دون تغيير بيانات المنطقة الوصفية.
• بناء الموارد مع البيانات الوصفية، ويُستخدم لتغييرات خوادم الأسماء والنطاقات البديلة (wildcard).
• بناء الجذر (apex) مع البيانات الوصفية، كما في بعض إعدادات Universal SSL.
• الإزالة (purge) لمنطقة لم تعد منشورة.
• البناء الكامل عند تعذّر إثبات أمان عمل أصغر.

والقاعدة التي تحكم ذلك أن كل مفتاح يكتبه البناء المستهدف يجب أن يطابق بايتًا ببايت ما يكتبه البناء الكامل، وإلا يُنفَّذ البناء الكامل. وتعالج الشركة حالات البيانات المشتركة بين مناطق تحمل الاسم نفسه، وتتحقق من حالة قاعدة البيانات قبل الكتابة لأن الحدث قد يسبق وصول التغيير إلى النسخ المقروءة. وللمناطق الضخمة استثناء مقصود: فوق حدّ معيّن لعدد السجلات لا يلجأ النظام إلى البناء الكامل لأنه لا يكتمل أصلًا ويؤخّر بقية التغييرات.

أما المجدول فيدمج أحداث المنطقة الواحدة قبل بدء البناء، ويحافظ على رسائل Kafka المنتظرة حتى تُكتب النتيجة بأمان، فلا يضيع تغيير عند إعادة التشغيل. كما يفرض فاصلًا زمنيًا لإعادة البناء لكل منطقة يختلف بحسب خطة كلاودفلير. وأتاحت الذاكرة الفائضة تقصير فترات انتظار كان المسار يحتاجها للمرونة، وهو ما أدى إلى خفض الزمن إلى النصف.

وللتحقق، أجرت الشركة اختبارات تكافؤ تقارن البناء الكامل بالمستهدف من حالة قاعدة البيانات نفسها، ثم شغّلت بناءً كاملًا بجانب كل بناء مستهدف أثناء الإطلاق للمقارنة.

ماذا يعني هذا لك؟#

• إن كنت تدير نطاقاتك على كلاودفلير، فإن وصول تغييرات السجلات والإعدادات إلى الخوادم الموثوقة لديها يصبح أسرع، بحسب ما أعلنته الشركة من تقليص الزمن إلى النصف.
• لا تتطلب هذه التحسينات أي إجراء منك، فهي تغييرات داخل بنية الشركة.
• إن كنت تصمّم نظامًا يعالج أحداثًا على بيانات ضخمة، فالدرس العملي هو تقدير أصغر عمل آمن لكل حدث، مع الرجوع إلى العمل الكامل عند أي غموض بدل افتراض الأقل.

المصدر: Cloudflare — How we halved DNS build delay and cut memory use by 85%