مِخبارMIKHBAR
الويب

Cloudflare تستعيد أكثر من 100 تيرابايت من الذاكرة

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

Cloudflare تستعيد أكثر من 100 تيرابايت من الذاكرة

تحسين صغير على شبكة بحجم Cloudflare

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

تقول الشركة إن تعديل خوارزمية واحدة خفّض بصمة الذاكرة لإحدى خدماتها المبنية على Pingora بدرجة كبيرة، ومكّنها من استعادة أكثر من 100 تيرابايت من الذاكرة على مستوى الشبكة. وتأتي هذه النتيجة فوق نحو 100 تيرابايت أخرى تمكّن فريق DNS من توفيرها في الشهر السابق، وفق ما ذكرته Cloudflare.

بلاغ عن استهلاك زائد في Pingora

بدأت القصة بتذكرة سجّلها موظف يُدعى Ivan، بعد رصد استهلاك مفرط للذاكرة في مكتبة pingora-ketama ضمن خدمة Pingora Backend Router، التي تختصرها Cloudflare إلى PBR. وكانت الملاحظة الأساسية أن الخدمة تستهلك ذاكرة أكثر بكثير مما كان متوقعاً، ولا سيما في البنى المرتبطة بالمكتبة.

تستخدم pingora-ketama، وهي مكتبة مفتوحة المصدر، أسلوب التجزئة المتسقة. وتحتاج Cloudflare إلى هذا الأسلوب في PBR لتوجيه الطلبات القابلة للتخزين المؤقت إلى الخوادم اعتماداً على عناوين URL. وبهذه الطريقة يمكن الاحتفاظ بنسخة واحدة فقط من الملف داخل مركز البيانات، مع توفير طريقة مستقرة للعثور على موقعه عند وصول الطلبات.

كيف توزّع التجزئة المتسقة الطلبات؟

تقبل دوال التجزئة أنواعاً مختلفة من المدخلات، لكنها تنتج قيمة عددية محدودة، قد تكون بعرض 32 أو 64 أو 128 بتاً بحسب الدالة المستخدمة. ويمكن وضع هذه القيم على خط أعداد أو على حلقة متصلة تعود من القيمة القصوى إلى الصفر. في نموذج مبسط، تُحوَّل هوية كل خادم، مثل عنوان IP، وكل مهمة، مثل مفتاح التخزين المؤقت، إلى قيمة على هذا النطاق.

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

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

الإحصاء يشرح مصدر التفاوت

لتقدير مقدار عدم اليقين في أحجام المناطق، لجأت Cloudflare إلى مفهومين إحصائيين: القيمة المتوقعة والانحراف المعياري. تمثل القيمة المتوقعة النقطة التي تتمركز حولها القياسات الناتجة عن توزيع معين، بينما يوضح الانحراف المعياري مدى قرب معظم القياسات من ذلك المركز.

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

المزيد من التجزئات، وذاكرة أقل

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

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

المصادر