التوسع التلقائي في السحابة خارج Kubernetes
التوسع التلقائي في السحابة خارج Kubernetes
تُعدّ أدوات HPA وCluster Autoscaler في Kubernetes قوية للغاية، غير أن جزءاً كبيراً من أعباء الإنتاج — من دوال بلا خادم، وقواعد بيانات مُدارة، وأسطول EC2 قديمة، وخدمات App Engine وAzure App Service — تتوسع بالكامل خارج مستوى Kubernetes. فهم آليات التوسع التلقائي الأصيلة في السحابة على مستوى البنية التحتية أمرٌ لا غنى عنه للمهندسين الكبار الذين يصمّمون أنظمة مرنة وفعّالة التكلفة تمتد عبر الخدمات المُدارة والأجهزة الافتراضية المجرّدة وتنسيق الحاويات في آنٍ واحد.
يتناول هذا الدرس الركائز الثلاث للتوسع التلقائي السحابي المستقل عن Kubernetes: سياسات التوسع الديناميكي (تفاعلية تعتمد على المقاييس)، والتوسع المُجدوَل (زمني لأعباء العمل المتوقعة)، والتوسع التنبؤي (يعتمد على التعلم الآلي واستباق الحمل). نستخدم مجموعات التوسع التلقائي AWS (ASG) كمرجعٍ أساسي — إذ تتبع مجموعات الجهاز المُدار في GCP ومجموعات توسع الأجهزة الافتراضية في Azure النموذج ذاته مع صياغة مختلفة لكل مزوّد.
مجموعات التوسع التلقائي: التشريح الداخلي
تُغلّف مجموعة ASG أسطولاً من أجهزة EC2 ضمن مظروف من القدرة الدنيا والمرغوبة والقصوى، مع مجموعة من سياسات التوسع. كل إجراء توسع — سواء صدر من تنبيه CloudWatch أو جدولة زمنية أو نموذج تنبؤي — يكتب في نهاية المطاف إلى حقل DesiredCapacity ذاته. يقوم متحكم ASG بعد ذلك بمزامنة الأجهزة العاملة الفعلية نحو هذا الهدف، بإطلاق الأجهزة أو إنهائها عبر مناطق التوفر المُعرَّفة.
على نطاق الشركات الكبرى، تجلس مجموعات ASG عادةً خلف موازن تحميل شبكي (NLB) أو موازن تحميل تطبيقي (ALB). عند اجتياز جهازٍ جديد لفحوصات الصحة، تُسجّله المجموعة في مجموعة الهدف. ووقت الاحماء — النافذة الزمنية بين "بدء تشغيل الجهاز" و"قبول الجهاز للحركة المرورية" — معامل حرج تُخطئ في ضبطه معظم الفرق في المرة الأولى.
سياسات التوسع الديناميكي
تقدم AWS ثلاثة أنواع من السياسات التفاعلية؛ وتتكامل الأنظمة الإنتاجية عادةً بين الأنواع الثلاثة معاً للحصول على طبقات دفاعية متعددة.
التوسع بتتبع الهدف (Target Tracking)
أبسط السياسات وأكثرها توصية. تحدد قيمة مستهدفة لمقياس معين — مثل نسبة CPU عند 60%، أو عدد الطلبات لكل هدف بمعدل 1000 طلب/ثانية، أو عمق قائمة انتظار SQS لكل جهاز — وتضبط المجموعة سعتها باستمرار للحفاظ على هذا الهدف. تشغّل AWS داخلياً حلقة تحكم مشابهة لنظام PID.
التوسع بالخطوات (Step Scaling)
يتيح لك التوسع بالخطوات تعريف دالة مجزّأة: إذا تخطى CPU 70%، أضف جهازَين؛ إذا تخطى 85%، أضف خمسة؛ إذا تخطى 95%، أضف عشرة. هذه هي السياسة المناسبة عندما يكون نمط حمولتك متقطعاً وتعلم من التجربة أن تعديلات تتبع الهدف التدريجية أبطأ مما ينبغي. تُطلَق من تنبيه CloudWatch لا من المقياس مباشرة.
التوسع المُجدوَل
للأعباء ذات الدورات المتوقعة — حركة API في ساعات العمل، ووظائف الدُفعات اليومية، وإرسال البريد التسويقي الأسبوعي، وطفرات فتح السوق اليومية — يُعدّ التوسع المُجدوَل أكثر موثوقية وأوفر تكلفة من التوسع التفاعلي. تضبط السعة المرغوبة والدنيا والقصوى في وقت محدد باستخدام تعبيرات cron؛ دون حاجة لمقياس أو تنبيه أو تأخير.
تفصيل جوهري: الإجراء المُجدوَل يغيّر DesiredCapacity فحسب عند لحظة الجدولة. إذا وسّعت سياساتك التفاعلية أسطولك بالفعل فوق القيمة المرغوبة الجديدة، سيُقلّص الإجراء المُجدوَل أسطولك في تلك اللحظة. تأمّل دائماً في التفاعل بين الإجراءات المُجدوَلة وحالة السياسة الحية — خصوصاً في شقّ التقليص.
التوسع التنبؤي
يستخدم AWS Predictive Scaling، الذي أصبح متاحاً بشكل عام عام 2021، تعلماً آلياً مدرَّباً على ما يصل إلى 14 يوماً من المقاييس التاريخية لمجموعة ASG في CloudWatch للتنبؤ بالحمل المستقبلي وضبط السعة استباقياً قبل وصول الحمل. الفارق الجوهري عن التوسع المُجدوَل أنه يتعلم ويتكيف — لا حاجة لصيانة جدول حين يتغير نمط حمولتك.
يعمل التوسع التنبؤي في وضعَين. في وضع التنبؤ فقط، يولّد تنبؤات ويعرضها في لوحة التحكم دون اتخاذ أي إجراء — مفيد لبناء الثقة قبل تفعيل الأتمتة. في وضع التنبؤ والتوسع، ينشئ إجراءات مُجدوَلة آلياً، عادةً قبل ساعة من الزيادة المتوقعة في الحمل.
قيمة scheduling_buffer_time البالغة 300 ثانية تخبر النظام بجدولة التوسع للخارج قبل 5 دقائق من الذروة المتوقعة — وهو أمر حيوي عندما يستغرق إطلاق الجهاز والإحماء من 3 إلى 4 دقائق. أما ضبط max_capacity_breach_behavior على IncreaseMaxCapacity فيتيح للتوسع التنبؤي تجاوز حدك الأقصى المُعرَّف مؤقتاً خلال الطفرات غير المتوقعة، متجنباً سقفاً صلباً قد يحجب التوسع في أسوأ اللحظات.
الجمع بين الأنواع الثلاثة: النمط الإنتاجي
في الشركات التي تعالج حركة مرور ضخمة، تعمل الآليات الثلاثة في آنٍ واحد ضمن تسلسل هرمي. يتولى التوسع التنبؤي إدارة الخط الأساسي للتنبؤ، مبقياً أسطولك مُسخَّناً مسبقاً. يغطي التوسع المُجدوَل الأحداث الجسيمة المعروفة — إطلاق منتجات، وحملات تسويقية، ونوافذ فتح السوق — التي تكون أكثر حدةً وتخصصاً مما يستطيع نموذج التعلم الآلي استيعابه. يستوعب التوسع الديناميكي بتتبع الهدف التباين المتبقي الذي لم يتوقعه التوسع المُجدوَل ولا التنبؤي. ويعمل التوسع بالخطوات كقاطع دائرة للطفرات المفاجئة الشديدة.
DefaultInstanceWarmup على هذه القيمة المقاسة الفعلية، لا القيمة الافتراضية 300 ثانية. أخطأ في ذلك، وستتضمن مقاييس CloudWatch أجهزة لم تُسخَّن بعد، مما يُضوّش إشارات التوسع ويتسبب في تقليص مبكر متسرع.
الخدمات المكافئة على السحابات الأخرى
تستخدم مجموعات الجهاز المُدار في GCP موارد Autoscaler مع كتل autoscalingPolicy — الثلاثية المفاهيمية ذاتها من هدف cpuUtilization وloadBalancingUtilization وschedules. تستخدم مجموعات توسع الأجهزة الافتراضية في Azure إعدادات Autoscale مع rules (قائمة على المقاييس) وملفات fixedDate أو recurrence للتوسع المُجدوَل. لا تمتلك Azure حتى الآن مكافئاً أصيلاً لـ AWS Predictive Scaling؛ إذ لا يزال Azure Monitor Predictive Autoscale في مرحلة المعاينة اعتباراً من 2025. لأساطيل متعددة السحاب، يجرّد Terraform الفوارق بين المزودين في سير عمل IaC ذاته، رغم اختلاف دلالات فترات التبريد ونوافذ التقييم بما يكفي لتبرير الضبط الدقيق لكل سحابة على حدة.