التوسّع وموازنة الأحمال

التوسع التلقائي والمرونة

18 دقيقة الدرس 9 من 10

التوسع التلقائي والمرونة

لا يكون حجم الحركة ثابتًا أبدًا. موقع تجارة إلكترونية قد يستقبل 200 طلبًا في الثانية في صباح يوم الثلاثاء الهادئ، لكنه يتلقى 20,000 طلب في الثانية في ذروة موسم التخفيضات. منصة إخبارية تشهد ارتفاعًا مفاجئًا بمقدار 50 ضعفًا فور انتشار خبر ما. تطبيق SaaS ينشط بشكل حاد كل صباح من أيام العمل حين يبدأ المستخدمون يومهم، ثم يهدأ تمامًا في الليل.

تشغيل عدد كافٍ من الخوادم للتحمل عند أعلى ذروة في جميع الأوقات يُعدّ مكلفًا — فأنت تدفع مقابل طاقة عاطلة 90% من الوقت. أما تشغيل ما يكفي فقط للأحمال المتوسطة فيعرّض خدمتك للانهيار عند أي ارتفاع مفاجئ في الطلب. التوسع التلقائي (Auto-Scaling) هو الحل: السماح للبنية التحتية بالتمدد والانكماش تلقائيًا، لمطابقة الطاقة الاستيعابية مع الطلب الفعلي في الوقت الحقيقي.

المرونة مقابل التوسع اليدوي

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

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

آلية عمل التوسع التلقائي: حلقة التحكم

كل نظام توسع تلقائي يتبع حلقة تغذية راجعة بنفس الأسلوب:

جمع المقاييس — استخدام المعالج، الذاكرة، معدل الطلبات، عمق قائمة الانتظار، زمن الاستجابة، مقاييس التطبيق المخصصة.
تقييم السياسات — مقارنة المقاييس الحالية بالحدود المحددة (مثلًا: "قم بالتوسع إذا تجاوز متوسط المعالج 70% لمدة دقيقتين").
اتخاذ قرار التوسع — إضافة N نسخة (توسع خارجي) أو إزالة N نسخة (تقليص).
تقارب الأسطول — تشغيل النسخ الجديدة أو إيقاف القديمة وتحديث مجموعة أهداف موزع الحمل.
الاستقرار — فترة هدوء (عادةً 120–300 ثانية) تمنع التذبذب قبل دورة القرار التالية.

حلقة التحكم التي تُشغّل التوسع التلقائي: جمع المقاييس، تقييم السياسات، اتخاذ القرار، التقارب، ثم الانتظار لدورة القرار التالية.

سياسات التوسع

توفر مزودو الحوسبة السحابية (AWS Auto Scaling Groups وGoogle Cloud Managed Instance Groups وAzure VMSS) عدة أنواع من السياسات:

تتبع الهدف (Target Tracking) — الأكثر شيوعًا. تحدد هدفًا (مثلًا: "أبقِ متوسط استخدام المعالج عند 60%") وتحسب لوحة التحكم عدد النسخ اللازمة للوصول إليه. بسيط، ذاتي الضبط، ويُنصح به كخيار افتراضي.
التوسع المتدرج (Step Scaling) — استجابة طبقية بناءً على حدود الإنذار: "إذا تجاوز المعالج 70% أضف 2، وإذا تجاوز 90% أضف 5". مفيد عندما تكون العلاقة بين الحمل والطاقة غير خطية.
التوسع المجدول (Scheduled Scaling) — استباقي. إذا كنت تعلم أن الحركة ترتفع كل صباح اثنين في الساعة التاسعة، فجدوِل زيادة الطاقة في الساعة الثامنة والنصف. هذا يتجنب التأخير الكامن في السياسات التفاعلية.
التوسع التنبؤي (Predictive Scaling) (قائم على تعلم الآلة في AWS وGCP) — تحلّل المنصة أنماط الحركة التاريخية وتوفر الطاقة قبل وصول الطلب. الأكثر فعالية عند وجود موسمية أسبوعية أو يومية واضحة.

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

مشكلة الإحماء عند بدء تشغيل النسخة

من أصعب جوانب التوسع التلقائي أن النسخ الجديدة ليست جاهزة فورًا. يحتاج الخادم الجديد للإقلاع وتهيئة نظام التشغيل وبدء التطبيق وتحميل إعداداته وتسخين ذاكرته المؤقتة وإنشاء اتصالات قاعدة البيانات. عمليًا، تتراوح نافذة الإحماء هذه بين 30 ثانية (حاوية خفيفة على Kubernetes) و5–10 دقائق (تطبيق Java ضخم ذو بدء تشغيل ثقيل). خلال هذه الفترة لا ينبغي أن تصل حركة الإنتاج إلى النسخة بعد.

تتعامل المنصات السحابية مع ذلك عبر فحوصات الصحة وفترات الإحماء. لا يوجّه موزع الحمل الطلبات إلا إلى نسخة اجتازت فحص الصحة. لدى مجموعة التوسع التلقائي وقت إحماء قابل للتهيئة لا تُحسب خلاله النسخة الجديدة في المقاييس الإجمالية — هذا يمنع وحدة التحكم من رؤية ارتفاع مؤقت في استخدام المعالج لآلة تقلع ويقودها إلى تشغيل مزيد من النسخ.

فخ التأخر في التوسع: التوسع التفاعلي دائمًا يتأخر عن الطلب بمقدار زمن الإقلاع على الأقل إضافةً إلى فترة الهدوء. إذا استغرق تطبيقك 4 دقائق للبدء وكانت حركتك قادرة على الارتفاع إلى 10 أضعاف في 60 ثانية (كما يحدث عند انتشار تغريدة)، فالتوسع التفاعلي وحده لن يحميك. ادمجه مع التسخين المسبق المجدول أو أسطول دنيا ثابت بحجم كافٍ لاستيعاب الصدمة الأولية.

التقليص: النصف المُهمَل

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

يستلزم التقليص أيضًا أن تكون نسخك قابلة للاستهلاك والاستبدال — الخدمات عديمة الحالة التي يمكن إنهاؤها في منتصف الطلب ستسقط الاتصالات. للتعامل مع ذلك بلطف:

فعّل تصريف الاتصالات (Connection Draining) في AWS أو الإنهاء الرشيق (Graceful Termination) في Kubernetes: يوقف موزع الحمل توجيه الطلبات الجديدة إلى النسخة المُنهاة بينما تكمل الطلبات الجارية، عادةً خلال نافذة تصريف مدتها 30–60 ثانية.
تأكد أن تطبيقك يعالج SIGTERM بإنهاء العمل الحالي قبل الخروج.
لا تخزّن حالة الجلسة أو بيانات المستخدم على النسخة ذاتها — استخدم ذاكرة مؤقتة مشتركة (Redis) أو قاعدة بيانات.

أبعاد التوسع التلقائي

التوسع التلقائي ليس حكرًا على الآلات الافتراضية. الأنظمة الحديثة تتوسع تلقائيًا على عدة مستويات في آنٍ واحد:

يسار: الحالة المستقرة ذات الحركة المنخفضة بخادمَي تطبيق وعامل قائمة انتظار واحد. يمين: تهيئة موسّعة — 4 خوادم تطبيقات، نسخ قراءة مضافة، 4 عمال قوائم انتظار.

مستوى الآلات الافتراضية — AWS Auto Scaling Groups وGCP Managed Instance Groups وAzure VMSS. النموذج الكلاسيكي.
مستوى الحاويات والـ Pods — Horizontal Pod Autoscaler في Kubernetes يوسّع عدد الـ pods؛ ويضيف Cluster Autoscaler عُقدًا إلى المجموعة حين تصبح الـ pods غير قابلة للجدولة.
مستوى Serverless — AWS Lambda وGoogle Cloud Functions وAzure Functions تتوسع من صفر إلى آلاف الاستدعاءات المتزامنة تلقائيًا. لا أسطول للإدارة؛ تدفع لكل استدعاء فحسب.
توسع العمال القائم على قوائم الانتظار — توسيع عدد عمال المعالجة الخلفية بناءً على عمق القائمة. AWS SQS مع Lambda، أو Kubernetes KEDA، أو مجموعة Auto Scaling Group مُشغَّلة بمقياس SQS من CloudWatch. فعّال جدًا لأعباء المعالجة الدفعية.
نسخ قراءة قاعدة البيانات — بعض قواعد البيانات المُدارة (Aurora Serverless وPlanetScale) يمكنها إضافة نسخ قراءة تلقائيًا مع نمو إنتاجية القراءة.

Horizontal Pod Autoscaler في Kubernetes

في بيئة Kubernetes، يستعلم HPA باستمرار عن Metrics Server (أو محوّل مقاييس مخصص لمقاييس العمل) ويضبط حقل replicas للـ Deployment. إعداد HPA بسيط يستهدف 50% من استخدام المعالج يبدو هكذا:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-deployment
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

بهذا الإعداد، يحافظ Kubernetes على ما بين 2 و20 pod، يضيف أو يزيل pods للحفاظ على متوسط استخدام المعالج قرب 50%. يمدّد KEDA (Kubernetes Event-Driven Autoscaling) هذا الأمر للتوسع بناءً على إشارات خارجية كعمق قائمة SQS أو تأخر Kafka أو مقاييس Prometheus.

تحسين التكلفة والتصحيح

التوسع التلقائي هو أساسًا أداة موثوقية، لكن له تداعيات تكلفة كبيرة. الاستراتيجيات الرئيسية:

اضبط حدًّا أدنى ذا معنى — يبدو الصفر مغريًا للتكلفة، لكن زمن الإقلاع البارد (Lambda تُشغّل حاوية جديدة) قد يبلغ 500ms–2s. للخدمات الحساسة للزمن، احتفظ بحد أدنى دائم من 1 إلى 2 نسخة.
استخدم نسخ Spot أو Preemptible للأسطول المتوسّع. يمكن أن تكون Spot في AWS أرخص بنسبة 70–90% من On-Demand. لأنها قابلة للاستعادة بإشعار دقيقتين، صمّم تطبيقك للتعامل مع الإغلاق الرشيق — نفس المرونة التي تحتاجها للتقليص.
راقب كفاءة التقليص — إذا كان أسطولك لا يتقلص أبدًا، فإعداداتك أو فترات الهدوء غير صحيحة. النظام المرن الصحي يُحرّر الطاقة بانتظام خلال ساعات الذروة المنخفضة.
احذر من التذبذب — الإضافة والإزالة السريعة المتكررة تُبدد المال وتُنشئ عدم استقرار. زِد فترات الهدوء أو وسّع النطاق الميت بين حدود التوسع والتقليص.

رؤية جوهرية: التوسع التلقائي لا يُعوّض الأداء الجيد للتطبيق. نظام يعالج 1,000 طلب في الثانية لكل نسخة يحتاج 10 خوادم لمعالجة 10,000 طلب في الثانية. نظام سيئ التحسين يعالج 100 طلب فقط في الثانية يحتاج 100 خادم للحمل ذاته — وهذه الخوادم الـ100 تستغرق وقتًا أطول بكثير للتوفير وتكلّف أكثر بكثير. حسّن الأداء أولًا، ثم اعتمد التوسع التلقائي.

الصورة الكاملة

استراتيجية التوسع التلقائي الجاهزة للإنتاج لخدمة ويب نموذجية تبدو هكذا: احتفظ بـأسطول حدٍّ أدنى مُهيّأ لاستيعاب متوسط حركة الذروة المنخفضة مع احتياطي يعادل خادمًا إضافيًا؛ استخدم تتبع الهدف (60% معالج، أو مقياس RPS مخصص) كسياسة تفاعلية أساسية؛ أضف التوسع المجدول للتسخين المسبق قبل الأحداث المعروفة؛ هيّئ تصريف الاتصالات عند التقليص؛ ضع الأسطول المتوسّع على نسخ Spot خلف نسخ On-Demand؛ وأنشئ تنبيهات تأخر التوسع لتعلم إذا كان الأسطول أبطأ من المتوقع في الاستجابة.

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