قد لا تكون مشكلة التوسعة التلقائية في أحمال GPU هي فشل Kubernetes في اتخاذ القرار، بل وصول القرار بعد فوات الأوان. يصف Ramkumar Nagaraj وBingi Narasimha Karthik من Adobe حادثة تعرضت فيها خدمة إنتاجية حرجة لموجة طلب رفعت معدلات الخطأ لدى المستخدمين إلى 15–20%، رغم أن Horizontal Pod Autoscaler بدأ التوسعة. السبب أن مئات الحاويات بقيت قيد الانتظار، بينما احتاجت عقد GPU الجديدة إلى وقت طويل حتى تصبح جاهزة.
في التسلسل الذي وثقه الكاتبان، وصلت موجة الطلب عند الساعة 06:00، وتجاوزت مؤشرات HPA العتبة عند 06:05، ثم بدأت جدولة الحاويات عند 06:15. لكن أول عقد GPU لم تكتمل عملية تجهيزها إلا عند 06:45، أي بعد انتهاء موجة الارتفاع. ويستغرق تجهيز عقد GPU عادة ثلاثة إلى خمسة أضعاف زمن تجهيز خدمات تعتمد على CPU، بسبب تحميل البرمجيات الثابتة وتهيئة التعريفات وتجهيز CUDA.
من التفاعل مع الطلب إلى الاستعداد له
اقترح الفريق تشغيل وحدة تحكم داخل Kubernetes كل 60 ثانية، تقرأ ساعة من المقاييس السابقة وتتنبأ بالطلب بعد عشر دقائق. الهدف ليس التنبؤ المثالي، بل بدء تجهيز السعة قبل وصول الموجة بما يكفي لتكون العقد والحاويات جاهزة عند الحاجة.
استفاد التصميم من البيانات التي يجمعها Prometheus، بما في ذلك استخدام CPU والذاكرة، وزمن الاستجابة، ومعدل الطلبات، واستخدام GPU. واختبر الفريق نماذج ARIMA، والتنعيم الأسي، ومكتبة Prophet، وLSTM، قبل اختيار نموذج Bi-LSTM مكوّن من طبقتين بعدد 64 ثم 32 وحدة. وجاء الاختيار، وفق المادة، استجابة لأنماط بيانات تضمنت ارتفاعات قصيرة، وفترات تعافٍ، وقيماً ثابتة شاذة، وليس لأنه الخيار النظري الأفضل في كل حالة.
يُعاد تدريب النموذج أسبوعياً، بينما يعمل النموذج المنشور في وضع الاستدلال فقط داخل ملف ثنائي لوحدة تحكم مكتوبة بلغة Go، باستخدام TensorFlow Lite. وبهذا لا يحتاج التصميم إلى منصة تعلم آلي خارجية أو طبقة لخدمة النماذج.
ثلاث طبقات لضبط التوسعة
يقوم التصميم على ثلاث وظائف مترابطة: التنبؤ، والتجهيز، والامتصاص. يتنبأ النموذج بالطلب، ثم تبدأ وحدة التحكم في زيادة النسخ تدريجياً، فيما توفر السعة المجهزة مسبقاً مساحة لاستيعاب الموجة الفعلية.
ولأن التنبؤ لا يستطيع التعامل مع كل مفاجأة، أضاف الفريق كاشفاً للارتفاعات المفاجئة يعمل بالتوازي. يقارن هذا المكوّن الطلب الفعلي بالتوقعات باستخدام عتبة متكيفة مبنية على الانحراف المعياري المتحرك. وإذا تجاوز الطلب التوقع بفارق يحقق مستوى الثقة المحدد، يزيد الكاشف سرعة التوسعة. ويصف الكاتبان هذا المكوّن بأنه شبكة أمان استدلالية، لا نموذجاً تنبؤياً ثانياً.
أما الموسّع التدريجي فيحد الزيادة إلى 20 حاوية في الدقيقة. ويهدف ذلك إلى منع موجة جدولة ضخمة تضع ضغطاً على المجدول وetcd، وتؤدي إلى تزاحم عمليات سحب الصور وتشغيل الحاويات وتهيئة الحاويات الابتدائية وحقن الوحدات الجانبية. كما حُدد الاستخدام المستهدف عند 70% بدلاً من 100%، لترك هامش يسمح بامتصاص الارتفاعات وبقاء النموذج غير دقيق أحياناً دون تحول الخطأ إلى سلسلة من الأعطال.
ما الذي أثبتته الاختبارات؟
شغّل الفريق النظام أولاً في وضع الظل، بحيث تُسجل التنبؤات من دون تنفيذ توسعة فعلية، وجمع أكثر من 500 ساعة من البيانات. أظهرت النتائج دقة بلغت 85% عندما كان التنبؤ بالطلب بعد عشر دقائق ضمن هامش ±10% من الطلب الفعلي. كما التقط كاشف الارتفاعات تسع موجات من أصل عشر، مع إنذارين كاذبين، بينما لم تظهر اختبارات الموسّع التدريجي حالات فشل متسلسل أو تذبذب في التوسعة.
كما عمل النظام إلى جانب HPA v2 من دون تعارض. وخلال أسبوع من التحقق في بيئة تطوير مضبوطة، اجتاز 23 اختباراً من أصل 23. وفي محاكاة لأنماط الارتفاع التي سببت الحادثة الأصلية، تمكن النظام من اكتشاف الموجة قبل نحو 11 دقيقة.
متى يكون هذا النهج مناسباً؟
تظهر قيمة التوسعة التنبؤية عندما يستغرق تجهيز العقد أكثر من دقيقتين أو ثلاث، وعندما يكون الطلب قابلاً للتنبؤ جزئياً، مثل الأنماط اليومية أو الأسبوعية أو الأحداث المعروفة. كما تحتاج إلى بيانات مراقبة جيدة، مع أسبوع على الأقل من مقاييس Prometheus. في المقابل، تصبح الفكرة أقل جدوى إذا كانت العقد تُجهز خلال 30 ثانية، أو كان الطلب عشوائياً تماماً، أو كانت أولوية الفريق هي خفض التكلفة قبل كل شيء؛ فالإبقاء على عقد دافئة يعني دفع تكلفة سعة احتياطية.
القراءة التحريرية: التغيير العملي هنا ليس استبدال HPA، بل إضافة زمن تنبؤ إلى منظومة تتعامل عادة مع الطلب بعد ظهوره. وتكمن أهميته في أحمال GPU تحديداً، حيث لا تكفي سرعة قرار التوسعة إذا كانت البنية التحتية تحتاج عشرات الدقائق قبل تشغيل الحاويات. لكن الدليل المعروض ما زال ناتجاً عن تحقق مضبوط، وليس قياساً مستقلاً واسع النطاق في بيئات إنتاج متعددة.
وتشير تجربة الفريق نفسها إلى قيود مهمة: قد يحقق نموذج ARIMA مضبوط نتيجة قريبة مع بنية أبسط، وقد يصبح النموذج قديماً خلال أيام عند تغير أنماط الطلب. كما بقي تفسير سبب توقع عدد معين من النسخ صعباً، ولم تُحسم بعد أسئلة حجم البيانات الأمثل، ودورية إعادة التدريب، وقدرة كاشف الارتفاعات الاستدلالي على التقاط الأحداث غير المسبوقة.
لذلك تقترح المادة البدء بجمع أسبوع من المقاييس، وتدريب نموذج بسيط، وتشغيله في وضع الظل، ثم قياس الدقة قبل تفعيل التوسعة. وعند الانتقال إلى الإنتاج، ينبغي فرض حد أقصى للنسخ، وتوفير إجراء تعطيل واضح، ويفضل المرور بمرحلة توسعة مقيدة قبل فتح المجال الكامل. الخلاصة التي يكررها الكاتبان عملية: تعقيد النموذج ليس ميزة بحد ذاته، وإذا نجح الحل الأبسط فمن الأفضل تشغيله.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.