الويب

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

بعد سنوات من التحسينات، نجحت كلاودفلير في تجاوز عقبة إعادة بناء النطاقات الضخمة بالكامل، مما سمح بتسريع نشر التغييرات وتقليل العبء على البنية التحتية.

رضوان عبدالهاديمحرر وكاتب تقني

نُشر: 2 نوفمبر 2026 · آخر تحديث: 2 نوفمبر 2026 · 5 دقائق قراءة

كلاودفلير تقلص زمن بناء DNS وتخفض استهلاك الذاكرة بنسبة 85% — الصورة: Cloudflare Blog

الخلاصة

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

تطور حجم البيانات وتحديات البنية التحتية

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

يعمل النظام على تحويل كل تغيير في قاعدة البيانات إلى بيانات يمكن لخوادم DNS الرسمية استخدامها، وهو عملية تسمى "البناء". في عام 2022، كانت عمليات البناء لكل سجل أسرع بـ 150 مرة من البناء الكامل في المتوسط، وبنسبة 4250 مرة في نطاق اختباري يحتوي على مليون سجل. هذا الفارق الهائل دفع الفريق إلى تطبيق نفس المنطق على تغييرات إعدادات النطاق، التي كانت تتطلب سابقاً إعادة بناء النطاق كاملاً حتى لو كان التغيير بسيطاً.

لماذا كانت إعادة البناء الكاملة ضرورية سابقاً؟

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

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

آلية عمل المخطط الجديد وتصنيف البناء

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

أصبحت إعدادات النطاق تجعل الاستهداف أكثر صعوبة. على سبيل المثال، تفعيل أو تعطيل Universal SSL يحدّث البيانات الوصفية ويمكن أن يغير سجلات CAA في قمة النطاق. سجلات CAA تخبر سلطات الشهادات ما إذا كان مسموحاً لها بإصدار شهادة للمجال. بينما كان البناء الكامل يحتاج فقط لمعرفة أن النطاق تغير، يجب على البناء المستهدف الإجابة عن ثلاثة أسئلة: هل يمكن أن تتغير البيانات الوصفية المشتركة أو قائمة النطاقات المنشورة؟ وما هي الحالة السابقة التي يجب إزالتها من Quicksilver؟

فئات البناء الخمس ومعايير الأمان

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

يقوم المخطط باختيار واحد من خمس فئات بناء: الموارد فقط (إعادة بناء السجلات لأسماء DNS محددة دون تغيير البيانات الوصفية)، الموارد والبيانات الوصفية (إعادة بناء أسماء محددة وبيانات وصفية مشتركة)، القمة والبيانات الوصفية (إعادة بناء قمة النطاق والبيانات الوصفية)، التطهير (إزالة نطاق يجب عدم نشره)، والبناء الكامل (إعادة بناء كل سجل عندما لا يمكن إثبات أمان عمل أصغر). القاعدة بسيطة: كل مفتاح يكتبه البناء المستهدف يجب أن يكون مطابقاً حرفياً لما كان سيكتبه البناء الكامل. إذا تعذر إثبات ذلك، يتم تنفيذ بناء كامل.

إزالة الحالة القديمة ومعالجة البيانات المشتركة

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

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