تمكنت Cloudflare من استعادة أكثر من 100 تيرابايت من ذاكرة RAM على مستوى شبكتها العالمية بعد إعادة تصميم جزء من خوارزمية توزيع الطلبات في خدمة Pingora Backend Router (PBR). وجاء التحسن من مزيج من ضغط تمثيل نقاط التجزئة، وتقليل عددها استناداً إلى تحليل إحصائي، وتنفيذ انتقال تدريجي حافظ على استقرار التخزين المؤقت وحركة المرور إلى الخوادم الأصلية.
المشكلة في توزيع الطلبات
تستخدم Cloudflare مكتبة pingora-ketama لتطبيق consistent hashing، وهي طريقة تساعد على توجيه الطلبات القابلة للتخزين المؤقت إلى الخادم نفسه ما أمكن. ويتيح ذلك الاحتفاظ بنسخة واحدة من الملف داخل مركز البيانات وتوفير مسار ثابت للوصول إليه.
لكن استخدام نقطة تجزئة واحدة لكل خادم قد يؤدي إلى تفاوت كبير في أحجام النطاقات التي تملكها الخوادم على حلقة التجزئة، وبالتالي تفاوت في أعباء العمل. لذلك يستخدم Pingora عدداً كبيراً من التجزئات الافتراضية لكل خادم، مع أوزان مرتبطة بسعة التخزين، كما تُنشأ حلقات منفصلة لمجموعات مختلفة من الخصائص والقيود. أدى تراكم هذه الحلقات إلى استهلاك يصل في بعض الحالات إلى 6 غيغابايت لكل عملية.
تحسين تمثيل البيانات وتقليل التجزئات
كان كل عنصر يمثل نقطة في الحلقة يتكون من قيمة تجزئة بحجم 32 بت ومؤشر بحجم 32 بت إلى الخادم، أي ثمانية بايتات في الذاكرة. رأى فريق Cloudflare أن المؤشر لا يحتاج عملياً إلى أكثر من 16 بت، لأن الخدمة لن تنسق أكثر من نحو 65 ألف خادم في الوقت نفسه.
لم يكن تقليص نوع المؤشر كافياً وحده بسبب قواعد المحاذاة في Rust، إذ كانت البنية ستظل بحجم ثمانية بايتات. لذلك أعادت Cloudflare تخزين القيمة والمؤشر داخل مصفوفة خام من ستة بايتات، مع دوال للوصول إلى كل منهما. خفّض هذا التغيير استهلاك الذاكرة الخاص بالتجزئة بنسبة 25%.
أما المكسب الأكبر فجاء من مراجعة عدد التجزئات. كانت الخدمة تستخدم قيمة أساسية قدرها 160 نقطة لكل خادم، تُضرب في وزن الخادم المرتبط بسعة التخزين. وأظهر التحليل أن الزيادات الكبيرة في عدد التجزئات تمنح تحسناً متناقصاً في هامش الخطأ؛ ففي المثال الذي ناقشته Cloudflare، لم تؤد إضافة آخر 90 ألف تجزئة إلى خفض الخطأ إلا بنحو 0.7%.
كما أن استخدام قيم تجزئة بحجم 32 بت يجعل التصادمات أكثر احتمالاً كلما ارتفع عدد النقاط، ما قد يضيف خطأ غير متوقع إلى التوزيع. وبناءً على الحسابات والمحاكاة، خفضت Cloudflare عدد التجزئات لكل خادم بنسبة 90% من دون زيادة ملحوظة في الخطأ، وهو ما ساهم في الوفورات النهائية.
ما الذي يتغير عملياً؟
لم يكن تبديل حلقة التجزئة على مستوى الشبكة دفعة واحدة خياراً آمناً، لأنه كان سيعيد توزيع الطلبات ويؤدي فعلياً إلى فقدان جزء كبير من فعالية التخزين المؤقت، مع احتمال رفع حركة المرور نحو الخوادم الأصلية. لذلك احتفظ PBR مؤقتاً بالحلقتين القديمة والجديدة في الذاكرة، واختار بينهما لكل طلب، ما وفر مساراً واضحاً للتراجع.
نُفذ الانتقال على مراحل، بدءاً من مواقع تحقق صغيرة ثم مراكز بيانات أكبر. كما فُصل التحكم في نسبة الطلبات التي تستخدم الحلقة الجديدة عن تحديد مراكز البيانات المسموح لها بالمشاركة. وراقبت Cloudflare آثار اختيار الخادم، وإصدارات الحلقة، وأخطاء الاتصالات، واستهلاك الذاكرة، وزمن بدء التشغيل، وسلوك التخزين المؤقت، وحركة المرور إلى الخوادم الأصلية قبل إزالة المسار القديم.
الدلالة الهندسية
تُظهر التجربة أن تحسينات منخفضة المستوى، مثل اختيار حجم حقل داخل بنية بيانات أو تحديد عدد مناسب من نقاط التجزئة، يمكن أن تتضخم آثارها عند تطبيقها على شبكة تضم آلاف الخوادم. وفي الوقت نفسه، لا تعني النتيجة أن تقليل الذاكرة آمن في كل نظام؛ فدقة التوزيع، واحتمالات التصادم، وأوزان الخوادم، وقيود الميزات، وطريقة تنفيذ الانتقال كلها عوامل يجب قياسها قبل التغيير.
أصبحت التعديلات متاحة في حزمة pingora-ketama عبر ميزة Cargo غير معلنة حالياً. وتدعم النسخة v2 صيغة التخزين المضغوطة، وطريقة فرز أسرع، وإمكانية ضبط العدد الأساسي للتجزئات، مع إبقاء النسخة v1 وإتاحة تشغيل الحلقتين معاً واتخاذ القرار على مستوى الطلب.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.