مجموعات EC2 Auto Scaling

شركة إعلام تشغّل 12 خادم EC2 خلف Application Load Balancer. تصل ذروة الحركة نحو 3 ساعات في أمسيات أيام العمل. وبقية الأسبوع تكفي 3 خوادم وتزيد، لكن الأسطول يبقى عند 12 لأن لا أحد يريد أن يكون من قلّصه في الأسبوع السابق لإطلاق منتج. ثم في يوم سبت يمتلئ قرص أحد الخوادم فيتوقّف عن الردّ، ويظلّ ميتاً حتى صباح الإثنين لأن فحص الصحة لم يكن موصولاً بشيء قادر على التصرّف.

هذان عطلان مختلفان، وتعالجهما مجموعة Auto Scaling بالآلية نفسها. هي مجموعة من خوادم EC2 تُبقيها AWS عند حجم تعلنه أنت، فتطلق وتنهي خوادم للحفاظ على ذلك الحجم، وتستبدل كل خادم يكفّ عن الظهور بمظهر السليم. أما سياسات التوسّع التي تحرّك الحجم فموضوع الدرس التالي. وهذا الدرس عن الآلة التي تحتها، لأن معظم أخطاء التوسّع في الإنتاج تقع هنا لا في السياسة.

ثلاثة أرقام، والسياسة لا تحرّك إلا واحداً

تُعرَّف مجموعة Auto Scaling بثلاث قيم للسعة.

• السعة الدنيا (minimum capacity) أرضية. لا تشغّل المجموعة عدداً أقلّ منها أبداً.
• السعة القصوى (maximum capacity) سقف. لا تشغّل المجموعة عدداً أكبر منه أبداً.
• السعة المرغوبة (desired capacity) هي العدد الذي تحاول المجموعة تشغيله الآن فعلاً.

لنفترض أنك ضبطت الدنيا على 2 والمرغوبة على 6 والقصوى على 12. تطلق المجموعة 6 خوادم. فإن حسبت سياسة توسّع لاحقاً أن 15 خادماً لازمة لإبقاء المعالج عند الهدف، تصعد المجموعة إلى 12 وتتوقّف، لأن 15 فوق السقف. وإن قال حساب التقليص إن خادماً واحداً يكفي، تنزل المجموعة إلى 2 وتتوقّف.

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

وللمجموعة قيمة حتى بلا أي سياسة توسّع. فبسعة مرغوبة مثبّتة عند 6، تظلّ المجموعة تراقب تلك الخوادم الستة وتستبدل كل خادم يخفق في فحص الصحة. الحفاظ على السعة وتوسيع السعة ميزتان منفصلتان، والأولى وحدها سبب كافٍ لإنشاء مجموعة لأسطول لا يتغيّر حجمه إطلاقاً.

قالب الإطلاق هو المخطّط

تحتاج المجموعة معرفة ما تطلقه. وهذا يأتي من قالب الإطلاق (launch template): معرّف AMI، ونوع الخادم، ومفتاح الوصول، ومجموعات الأمان، وملف IAM، وربط أجهزة التخزين، وبيانات المستخدم، وبقية سطح إطلاق EC2.

وقوالب الإطلاق مُصدَّرة بإصدارات. تنشئ الإصدار 3 بصورة AMI جديدة وتوجّه المجموعة إليه، فيستخدم كل خادم يُطلق منذ تلك اللحظة الإصدار 3 بينما تواصل الخوادم القائمة العمل بما أُطلقت به. وتاريخ الإصدارات هذا هو ما يجعل سياسة الإنهاء الافتراضية وinstance refresh ممكنين، وكلاهما يظهر لاحقاً.

أما launch configuration الأقدم فما زال موجوداً في المواد القديمة والحسابات القديمة. ليس مُصدَّراً بإصدارات، ولا يمكن تحريره (تستبدله)، ولا تمدّه AWS بميزات EC2 الجديدة. عامل «انقل المجموعة من launch configuration إلى launch template» جواباً متوقّعاً كلما ذكر النصّ خوادم Spot وOn-Demand في مجموعة واحدة، أو أنواع خوادم متعدّدة، أو instance refresh، لأن أياً منها لا يعمل مع launch configuration.

فحوصات الصحة تقرّر ما يُستبدَل

يبدأ الخادم داخل المجموعة بحالة Healthy، ويبقى كذلك حتى يخبر شيءٌ المجموعةَ بغير ذلك. وتصغي المجموعة إلى عدة مصادر:

يخفي هذا الجدول أشيع خطأ إعداد في الموضوع، فلنقله صراحةً. افتراضياً لا تستخدم مجموعة Auto Scaling سوى فحوصات حالة EC2. والخادم الذي يعيد تطبيقه HTTP 500 لكل طلب ينجح في فحوصات حالة EC2، لأن المضيف الافتراضي (hypervisor) سليم ونظام التشغيل يعمل. وسيلاحظ ALB ذلك ويسم الهدف معطوباً ويكفّ عن إرسال الحركة إليه. أما مجموعة Auto Scaling فلن تستبدله، فتنتهي بمجموعة تبلّغ عن 6 خوادم سليمة خلف مجموعة أهداف تبلّغ عن 5 أهداف سليمة، إلى ما لا نهاية. وتفعيل فحص صحة Elastic Load Balancing على المجموعة هو ما يغلق تلك الفجوة.

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --health-check-type ELB \
  --health-check-grace-period 300

ومهلة السماح لفحص الصحة (health check grace period) في ذلك الأمر هي الأمر الثاني الذي يجب ضبطه جيداً. هي أقلّ مدة يُترك فيها الخادم الداخل إلى الخدمة حديثاً وشأنه قبل أن يستطيع حكمٌ بالعطب إنهاءه. وفحوصات Elastic Load Balancing تبدأ لحظة تسجيل الخادم، فالتطبيق الذي يحتاج 4 دقائق لتسخين ذاكرته المؤقتة سيخفق في فحوصه الأولى ويُقتَل بسببها. ومهلة السماح تشتري له ذلك الوقت.

والافتراضيات ليست واحدة في كل مكان، وهذه مصيدة حقيقية:

• الواجهة الرسومية: 300 ثانية
• AWS CLI أو SDK: 0 ثانية، أي إلغاء المهلة كلياً

فالمجموعة التي ينشئها قالب CloudFormation أو سكربت CLI دون تحديد مهلة صراحةً ستحكم على خوادمها من الثانية الأولى، وقد يقع أسطول بطيء الإقلاع في حلقة يُقتَل فيها كل بديل قبل أن يكمل إقلاعه. واستثناء واحد ينطبق أثناء مهلة السماح: إن غادر الخادم حالة running في EC2، لأن أحداً أوقفه مثلاً، تسمه المجموعة Unhealthy وتستبدله فوراً دون انتظار.

ولا تحلّ المشكلة برفع مهلة السماح إلى ساعة. فالمهلة العالية وقت ميت يبقى فيه خادم معطوب فعلاً داخل الخدمة. والعلاج الأفضل، ويأتي في درس دورة الحياة، هو lifecycle hook عند الإطلاق يُبقي الخادم خارج الخدمة حتى ينتهي تهيئته، فتستطيع خفض مهلة السماح.

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

التوازن بين مناطق التوفّر يسبق كل شيء

تعطي المجموعة شبكات فرعية، وكل شبكة فرعية تقع في منطقة توفّر واحدة بالضبط. وحين تطلق المجموعة خادماً، تختار المنطقة المفعّلة صاحبة أقلّ عدد خوادم، وداخلها الشبكة الفرعية صاحبة أكبر عدد عناوين IP حرّة. وحين تنهي خادماً، تنظر أولاً إلى المنطقة صاحبة أكبر عدد خوادم.

وهذا الترتيب أهمّ مما يبدو. فالتوازن بين المناطق يُقيَّم قبل سياسة الإنهاء، دائماً. فالمجموعة التي فيها 5 خوادم في us-east-1a و3 في us-east-1b ستنهي خادماً من us-east-1a حتى لو كان أقدم خادم في المجموعة كلها جالساً في us-east-1b. وحين يقول نصّ السؤال «أُنهي أحدث خادم ولا نفهم لماذا»، فالجواب عادةً اختلال التوازن بين المناطق.

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

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

أي خادم ينتهي عند التقليص

بعد اختيار المنطقة، تعمل سياسة الإنهاء الافتراضية على الخوادم غير المحميّة بهذا الترتيب:

1. الإعدادات القديمة أولاً. في مجموعة تعمل بقوالب الإطلاق، يعني ذلك الخوادم المُطلقة من launch configuration، ثم الخوادم المُطلقة من قالب إطلاق مختلف، ثم الخوادم على أقدم إصدار من القالب الحالي.
2. الأقرب إلى ساعة الفوترة التالية. إن بقي عدة مرشّحين، تختار المجموعة الأقرب إلى ساعة فوترته التالية، وتفضّ التعادل عشوائياً. وأهمية هذه الخطوة أقلّ كثيراً مما كانت، لأن معظم استخدام EC2 يُفوتَر بالثانية.

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

وتضيف مجموعات mixed instances خطوةً في المقدمة. تقرّر المجموعة أولاً هل ينبغي أن يذهب خادم Spot أم On-Demand، كي يميل الأسطول نحو النسبة التي ضبطتها، ثم تفحص هل يحسّن إنهاء خادم بعينه المواءمة مع استراتيجية التخصيص لديك، ثم تنزل بعد ذلك إلى الإعدادات القديمة وساعة الفوترة.

وتستطيع تجاوز السياسة حين لا يناسبك الافتراضي:

وأياً كان اختيارك، يبقى التوازن بين المناطق سابقاً. فسياسة الإنهاء لا تقرّر سوى أي خادم داخل المنطقة المختارة يذهب.

حماية الخادم من التقليص، وما لا تشتريه

بعض الخوادم لا ينبغي أن تُختار. مضيف حاويات في منتصف مهمة، أو وكيل بناء مضى 40 دقيقة في ترجمة، أو عقدة تحمل جلسة طويلة. وحماية الخادم من التقليص (instance scale-in protection) تسم الخادم غير مؤهّل للإنهاء بفعل حدث تقليص. وتستطيع ضبطها على المجموعة فيرثها كل خادم جديد، ثم تزيلها لكل خادم حين ينتهي عمله، وهذا ما تفعله مجدولات الحاويات.

والنصف المهم من هذه الميزة هو ما لا تفعله. حماية التقليص لا تمنع:

• الاستبدال بعد إخفاق في فحص الصحة
• مقاطعة خادم Spot
• انتهاء حجز Capacity Block
• الإنهاء اليدوي عبر terminate-instance-in-auto-scaling-group
• الإنهاء اليدوي من واجهة EC2 أو CLI أو API

والأخيرة تفاجئ الناس. فلمنع شخص من إنهاء الخادم في واجهة EC2 تحتاج EC2 termination protection، وهو إعداد منفصل على الخادم نفسه. الاسمان يبدوان ميزةً واحدة وليسا كذلك.

وحالة حدّية تظهر في حوادث حقيقية: إن كانت كل خوادم المجموعة محميّة ووقع حدث تقليص، تخفض المجموعة السعة المرغوبة لكنها لا تستطيع إنهاء شيء. ويسجّل تاريخ النشاط الرسالة Could not scale to desired capacity because all remaining instances are protected from scale in، وتظلّ المجموعة تعمل فوق سعتها المرغوبة بهدوء حتى تُزال الحماية من مكان ما.

إيقاف أجزاء من المجموعة أثناء العمل

حين تحتاج أن تكفّ المجموعة عن التصرّف فترةً، أوقف عمليات بعينها بدل حذف السياسات:

واختيار العملية الصحيحة سؤال تشخيصي. إيقاف Launch يوقف الدوّامة لكنه يمنع أيضاً توسّعاً مجدولاً قد تريده، أما إيقاف ReplaceUnhealthy فيوقف حلقة الاستبدال وحدها. وإن ظلّت مجموعة تخفق في إطلاق الخوادم أكثر من 24 ساعة تقريباً، تفرض AWS إيقافاً إدارياً من تلقاء نفسها. فحين يبلّغ أحدهم أن مجموعةً «توقّفت عن العمل فجأة»، افحص العمليات الموقوفة قبل أن تفحص السياسة.

نصائح للاختبار

• السيناريو الذي ترفض فيه المجموعة النمو بينما تبدو السياسة سليمة هو سؤال عن السعة القصوى. اقرأ الأرقام الثلاثة قبل أن تقرأ السياسة.
• «موازن الحمل يعرض الهدف معطوباً لكن الخادم لا يُستبدَل أبداً» هو نوع فحص الصحة دائماً. فالمجموعة تعتمد فحوصات حالة EC2 وحدها افتراضياً.
• «الخوادم تُنهى وتُعاد بحلقة فور إطلاقها» هي مهلة السماح لفحص الصحة، والدليل مجموعة أُنشئت بـ CLI أو CloudFormation، حيث الافتراضي 0 لا 300 كما في الواجهة.
• لا تخلط بين المؤقّتين. مهلة السماح لفحص الصحة هي كم يمرّ قبل أن تستطيع الفحوص قتل خادم جديد. ومهلة التهدئة الافتراضية، 300 ثانية، توقّف بين أنشطة simple scaling وتنتمي إلى الدرس التالي.
• «أُنهي خادم أحدث قبل خادم أقدم» يعني أن المناطق كانت غير متوازنة. فالتوازن بين المناطق يعلو سياسة الإنهاء.
• أي ذكر لـ Spot مع On-Demand في مجموعة واحدة، أو أنواع خوادم متعدّدة، أو instance refresh، يستبعد launch configurations. والجواب يحتاج قالب إطلاق.
• حماية التقليص تمنع التقليص وحده. فإن ذكر النصّ فحص صحة أو مقاطعة Spot أو شخصاً يضغط Terminate في الواجهة، فالحماية جواب خاطئ.

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