عزل الذكاء الاصطناعي في منصة .NET: توقف خدمة Python أعطى HTTP 503 بدلًا من انهيار الـ API بالكامل

تُظهر تجربة بسيطة بوضوح كيف ينبغي أن تتصرف المنصة التي تضم مكوّنًا للذكاء الاصطناعي. أوقف كاتب التحليل على Habr خدمة Python التي تستضيف نموذج تعلّم آلي، فظل .NET API قادرًا على العمل: إذ تلقّى الطلب الموجّه إلى وظيفة الذكاء الاصطناعي الرمز HTTP 503. وبعد استعادة Python انتهى الطلب نفسه بالرمز 200. ولم يُعِد أحد تشغيل التطبيق الرئيسي.

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

لماذا نفصل .NET عن Python

معظم منظومة تعلّم الآلة تعيش على Python: PyTorch ومكتبات الاستدلال (inference) والأغلفة الجاهزة للنماذج. أما منطق الأعمال والمصادقة والمعاملات والتكاملات في عالم المؤسسات، فغالبًا ما تُكتب بـ .NET. والإغراء بدمجهما في عملية واحدة مفهوم: بنية تحتية أقل ولا استدعاءات شبكية.

لكن ثمن هذا الخيار هو المصير المشترك. فتسرّب الذاكرة في مكتبة أصلية (native)، أو التجمّد بسبب GIL، أو الانهيار عند تحميل أوزان ضخمة، كل ذلك يطال العملية بأكملها. أما خدمة Python المنفصلة فتضع حدًّا للفشل: يمكنها أن تتعطل وتُعاد تشغيلها وتُحدَّث وفق جدولها الخاص، بينما يواصل بقية الـ API خدمة العملاء.

يعد عنوان المقال الأصلي بحل «دون خدمات مصغّرة زائدة». والمقصود خدمة واحدة مخصصة للنموذج، دون تفتيت النظام كله إلى عشرات العُقد.

ما الذي يجب توفيره عند نقطة الاتصال

الحدّ الشبكي وحده لا يضمن شيئًا. فإذا انتظر .NET ردًّا من Python غير المتاحة إلى ما لا نهاية، فسينتقل الفشل ببساطة إلى مجمّع الخيوط (thread pool). ولتحقيق عزل حقيقي، يحتاج الأمر عادةً إلى عدة آليات من جانب .NET:

• مهلات زمنية (timeouts) صارمة على كل استدعاء للنموذج؛
• فحوص حالة الخدمة (health checks) لمعرفة سريعة بأنها غير متاحة؛
• قاطع الدائرة (circuit breaker): بعد سلسلة من الأخطاء تتوقف الاستدعاءات مؤقتًا، فتتلقى الطلبات رفضًا فوريًا؛
• إعادة محاولات بفواصل زمنية متزايدة أُسّيًا مع jitter، ولكن للعمليات المتماثلة (idempotent) فقط؛
• تحديد عدد الاستدعاءات المتزامنة إلى النموذج (bulkhead) كي لا يستنزف الاستدلال البطيء كل موارد الـ API.

كما أن دلالة الاستجابة مهمة. فالرمز 503 يخبر العميل بأن الخدمة غير متاحة مؤقتًا، وهذا أكثر صدقًا من الخطأ العام 500. ويستطيع الواجهة الأمامية والأنظمة المستدعية التمييز بين تعطّل وظيفة الذكاء الاصطناعي وعطل المنصة. ووفق وصف التجربة، هكذا تصرف الـ API تمامًا: 503 طوال فترة التوقف، و200 فور عودة Python.

نتيجة التجربة

بحسب الوصف المنشور، تبدو الصورة كما يلي:

• خدمة Python متوقفة: يواصل .NET API العمل.
• الطلب إلى وظيفة الذكاء الاصطناعي في هذه الأثناء: HTTP 503.
• خدمة Python مستعادة: ينتهي الطلب نفسه بـ HTTP 200.
• إعادة تشغيل التطبيق الرئيسي: لم تكن مطلوبة.

لا يورد المؤلف هنا أرقامًا عن زمن الاستجابة أو الحمل، لذا فهذا عرض لمبدأ وليس اختبار أداء (benchmark). وتفاصيل التنفيذ متاحة في المقال الأصلي.

ما الذي ينبغي اعتماده

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

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