مقدمة سريعة: لماذا نحتاج لاستراتيجية Autoscaling هجينة لخدمات Inference؟
خدمات الاستدلال (inference) في بيئات متعددة المستأجرين تواجه توازنًا صعبًا: الرغبة في تقليل التكلفة (خصوصًا عند استخدام موارد GPU/accelerators) من جهة، والحاجة للحفاظ على زمن استجابة منخفض وثابت وفق SLOs من جهة أخرى. استراتيجية هجينة تجمع بين Spot instances الرخيصة، طبقة Serverless للتعامل مع الذروة، ووحدات تنفيذ على الحافة (Edge Functions) للمستخدمين القريبين جغرافيًا يمكن أن تقلل التكلفة الإجمالية مع الحفاظ على تجربة مستخدم متسقة.
في هذا الدليل نشرح أنماط المعمارية، سياسات autoscaling العملية، آليات التعامل مع فقدان موارد Spot، وكيفية تطبيقها عمليًا في Kubernetes/Serverless/Edge. بعض الممارسات المذكورة مبنية على توصيات أدوات نشر حديثة مثل Karpenter وإرشادات مزوّدي شبكات الحافة والسيرفرليس.
نمط معماري مقترح (Overview)
الهيكل العام يقسم الخدمة إلى ثلاث طبقات تشغيلية يمكن توجيه الطلبات بينها بناءً على السياسة والضرورة:
- قاعدة ثابتة On‑Demand / Reserved: مجموعة أصغر من العقد المضمونة على الـcloud (CPU/GPU حسب الحاجة) تستضيف النماذج الحرجة والـcontrol plane وعمليات التدريب المصغّرة.
- طبقة Spot (Opportunistic): تجمع عقد Spot لتنفيذ كثيف لحالات inference الطويلة أو غير الحاسمة - مع تصميم للاستئناف عند انقطاع الموارد.
- طبقة Serverless + Edge Functions: تُستخدم لطلبات التسليم السريع والصغيرة، ولبنية توجيه سريعة للـcold requests أو كنقطة تجميع/تخزين مؤقت (cache) لإجابات متكررة، وتخفيف الذروة العاجلة.
هذا التقسيم يسمح باستراتيجية «قيمة مقابل موثوقية»: الطلبات الحساسة تُخدم على On‑Demand، الطلبات المتكررة أو القصيرة تُخدم على Edge/Serverless، بينما تُستغل Spot للتعامل مع الحمل الأساسي الكبير لتقليل التكلفة. ملاحظات تنفيذية وتفصيلية عن استخدام Karpenter مع Spot متاحة في توجيهات EKS وKarpenter.
توزيع الطلب (Routing) وإدخال نظام أسبقية
منهجية شائعة هي إدخال طبقة ذكية على مدخل الخدمة (API Gateway / Inference Router) تقوم بـ:
- فحص نوع الطلب (خدمة سريعة أمٍ batch أو heavy).
- توجيه الطلبات القصيرة إلى Edge/Serverless إذا كان النموذج مخزّنًا مصغرًا أو مخبّأً.
- إرسال الطلبات الأطول أو متعددة الوسائط إلى صفوف معالجة (queue) ويتم تفريغها إلى طبقة Spot/On‑Demand حسب سياسة السعة المتوفرة.
إضافة طبقة admission control وrate limiting لكل مستأجر (tenant) تحمي من تسلسل استهلاك موارد نتيجة لهجوم أو خطأ برمجي.
سياسات Autoscaling عملية ومقاييس يجب قياسها
لا يكفي الاعتماد على استخدام CPU/ GPU فقط؛ سياسات autoscaling الفعّالة لخدمات inference متعددة المستأجرين تعتمد على مزيج من المقاييس التالية:
- زمن الاستجابة (latency) — p95/p99: المقياس الأهم لSLOs. عند ارتفاع p95 إلى فوق الهدف، يجب التدرج الأفقي أو تبديل أي من مسارات الطلبات إلى موارد أكثر موثوقية.
- طول الصف (queue length) / عدد الطلبات المعلقة: إشارة مباشرة لضرورة توسيع القدرة (scale‑out) قبل أن تتأثر latency.
- معدل الوصول لكل مستأجر (RPS/tenant): يمنع إسراف واحد من المستأجرين على حساب الآخرين ويُستخدم بموازاة سياسات الـquotas.
- استهلاك الذاكرة/VRAM ونسب GPU utilization: مهم لوحدات inference الثقيلة.
- مؤشرات الحوسبة المتقطعة (preemption rate for Spot): لقياس مدى استقرار طبقة Spot وتفعيل fallback أسرع عند ارتفاع معدلات الاستدعاء.
الأبحاث والأنظمة الحديثة تقترح دمج نماذج توقعية مع Autoscaler (مثلاً استشراف ذروة الطلبات) لتحسين قرار التوسيع وتقليل التكاليف من خلال تجنّب provisioning زائد. هذا المجال متطور ويتم بحثه في الأدبيات الحديثة حول autoscaling المتزامن في السيرفرلس.
تعامل مع انقطاع Spot
- استخدم تباينًا (instance diversity) في قائمة Spot لتقليل احتمالية فقدان السعة بالكامل.
- ضع آليات checkpointing خفيفة (للـstateful pipelines) وخطط إعادة إرسال الطلبات عند preemption.
- خصص مجموعة On‑Demand صغيرة لتحمل الأحمال الحرجة عند فقدان Spot فجائيًا.
الأدوات مثل Karpenter تسمح بتعريف node pools مختلطة وتقنيات لاكتشاف وإدارة إخطارات انقطاع Spot عبر قوائم انتظار للتنبيه (SQS/Events).
خريطة تنفيذية سريعة: خطوات ونماذج جاهزة للتطبيق
قائمة تحقق لتطبيق استراتيجية هجينة على بيئة إنتاجية:
| الخطوة | التفصيل |
|---|---|
| 1. تحديد SLOs وSLA لكل مستأجر | حدد p95/p99 لكل نوع طلب وفئات الأولوية. |
| 2. تصميم طبقة التوجيه (Router) | API Gateway + rules لتوجيه الطلب إلى Edge/Serverless/Queue/Spot. |
| 3. إعداد طبقة On‑Demand صغيرة | تستضيف نماذج حرجة وتعمل كفشل احتياطي عند فقدان Spot. |
| 4. نشر Spot NodePool مع Karpenter | تمكين تنويع أنواع الـinstance وتمكين إخطار الانقطاع (interruption handling). |
| 5. تكامل Serverless/Edge | نشر إصدارات مخففة من النموذج أو أجزاء pre‑/post‑processing على Edge أو Functions. |
| 6. مراقبة وAutoscaling بسياسات SLO‑driven | قاعدة بيانات SLO، رصد p95 والـqueue length، واستخدام predictive scaling إن أمكن. |
مثال YAML بسيط (إيضاحي) لNodePool في Karpenter الذي يفضّل Spot مع تنويع:
# مثال توضيحي فقط
apiVersion: karpenter.sh/v1alpha5
kind: NodePool
metadata:
name: inference-spot
spec:
requirements:
- key: karpenter.k8s.aws/capacity-type
operator: In
values: ["spot","on-demand"]
provider:
instanceTypes: ["p4d","g5","g5g","g4dn"]
zone: ["us-east-1a","us-east-1b"]
ttlSecondsUntilExpired: 300
لا تنسَ تعديل القيم بما يتوافق مع مزود الخدمة والقيود التنظيمية لشركتك.
توثيق Karpenter وBest Practices الخاصة باستخدام Spot تقدّم إرشادات عملية حول تنويع الـinstance وإعداد طوابير إشعار الانقطاع.
نصائح ختامية للمراقبة والأمان
- عزل موارد كل مستأجر منطقيًا (namespaces/quotas) ومراقبة الunit economics لكل مستأجر.
- فعّل logging مفصّل لعمليات preemption وفشل الحاويات لتحسين استراتيجية fallback.
- اختبر سيناريوهات فقدان Spot بانتظام (chaos testing) للتأكد من أن fallback يعمل فعليًا دون انتهاك SLOs.
منهجيات تقليل الـcold starts في السيرفرلس وتحسين الأداء على الحافة ما زالت تشهد أبحاثًا وتطويرًا مستمرًا؛ توثيق ونماذج حديثة تقترح مشاركة الاعتمادات والـwarm pools لتحسين زمن الاستجابة.
الخلاصة: تصميمك يجب أن يبدأ من SLOs — ثم تبني طبقات تشغيلية (On‑Demand، Spot، Serverless/Edge) مع سياسات autoscaling مبنية على latency وqueue metrics مع آليات fallback واضحة.