التوسّع التلقائي وبناء تطبيق كامل

في الجزء السادس وزّعنا الزوار على سيرفرين، وشفنا الموقع يكمل لو تعطّل واحد. بس بقيت مشكلتين: السيرفر المعطّل يبقى معطّل لين تتدخل بنفسك، وعدد السيرفرات ثابت مهما زاد الضغط أو قل.

موقع متجر مثلاً، زواره في الليل غير زواره وقت العروض. لو جهزت سيرفرات لأعلى ضغط، تدفع على سيرفرات فاضية أغلب الوقت. ولو جهزت أقل، يوقف الموقع في أهم لحظة. الحل: مجموعة التوسّع التلقائي.

مجموعة التوسّع التلقائي (ASG) #

Auto Scaling Group تدير مجموعة سيرفرات بدالك. تعطيها وصفة وثلاثة أرقام، وهي تتكفّل بالباقي:

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

قالب التشغيل (Launch Template) #

عشان تقدر تشغّل سيرفرات لحالها، تحتاج وصفة: صورة النظام، ونوع السيرفر، ومجموعة الأمان، ودور IAM، وUser Data. كل اللي اخترته بيدك في الجزء الثالث يصير محفوظ في قالب.

هنا تبان فايدة صور AMI الجاهزة: كل ما قام السيرفر أسرع، زادت سرعة استجابة المجموعة للضغط.

فحص الصحة: لا تنسَ هذا الخيار #

افتراضياً، المجموعة تفحص السيرفر نفسه فقط. فلو السيرفر شغّال لكن التطبيق داخله واقف، ما تستبدله. فعّل خيار ELB health checks عشان تعتمد على فحص موزّع الحمل، فيُستبدل السيرفر لما يتعطّل التطبيق نفسه.

متى تزيد ومتى تنقص؟ #

والمقياس اللي تختاره مهم. المعالج بداية جيدة، لكن لمواقع الويب غالباً عدد الطلبات لكل سيرفر (RequestCountPerTarget) أصدق، لأنه يعبّر عن الزوار مباشرة.

وعشان تعطي السيرفرات الجديدة وقت تأثر على الأرقام، سياسات Target Tracking وStep تنتظر فترة Instance Warmup. ولو ما حددتها، تستخدم فترة التهدئة الافتراضية 300 ثانية.

مجموعة Auto Scaling توسّع السيرفرات. ولو عند تطبيقك كمان خدمات ECS أو جداول DynamoDB أو نسخ Aurora، فخدمة AWS Auto Scaling تقدر تدير خطة توسع لها كلها في مكان واحد.

عملي: شوف المجموعة تكبر وتعالج نفسها #

بنكمل على موزّع الحمل والـ Target Group من الجزء السادس.

1. القالب: من EC2 افتح Launch Templates ثم Create launch template. سمّه web-template، واختر Amazon Linux 2023 وt3.micro ومجموعة أمان السيرفرات، والصق User Data من الجزء الثالث.
2. المجموعة: من Auto Scaling Groups أنشئ web-asg من هذا القالب، واختر شبكتين فرعيتين في منطقتي توفر مختلفتين.
3. الموزّع: اختر Attach to an existing load balancer، وحدد الـ Target Group، وفعّل ELB health checks.
4. الأرقام: Desired 1 وMinimum 1 وMaximum 3.
5. السياسة: اختر Target tracking على متوسط المعالج بهدف 40%.

ادخل على السيرفر من EC2 Instance Connect، وولّد ضغط على المعالج. وسيرفر t3.micro فيه معالجين افتراضيين، فنشغّل عمليتين:

yes > /dev/null &
yes > /dev/null &

وبعد دقائق، شوف وش صار من CloudShell:

# وش سوّت المجموعة ولماذا
aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name web-asg --max-items 5 \
  --query "Activities[].[StatusCode,Description]" --output table

# السيرفرات الحالية ومناطقها وحالتها
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names web-asg \
  --query "AutoScalingGroups[0].Instances[].[InstanceId,AvailabilityZone,HealthStatus]" \
  --output table

بتشوف سيرفرات جديدة تقوم وتدخل الموزّع بدون ما تلمس شي. أوقف الضغط، وبعد حوالي ربع ساعة تنقص المجموعة لحالها:

pkill yes

والآن الجزء الممتع: احذف سيرفر بنفسك وشوف وش يصير:

aws ec2 terminate-instances --instance-ids i-0123456789abcdef0

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

نجمع القطع: تطبيق كامل #

الحين عندك كل قطع طبقة الخوادم. هذا التصميم الشائع لتطبيق ويب يتحمل الأعطال:

القاعدة الأهم: السيرفر قابل للاستبدال #

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

بعض هذي الخدمات ما وصلناها بعد، وبنغطيها في الأقسام الجاية. المهم الحين الفكرة: لما تصمم أي شي، اسأل "وش يصير لو اختفى هذا السيرفر الحين؟". لو الجواب "ولا شي"، فأنت على الطريق الصح.

ونفس الفكرة توصلك لـ البنية غير القابلة للتعديل (Immutable Infrastructure): ما تحدّث سيرفر شغال. تبني صورة جديدة، وتحطها في Launch Template جديد، وتخلي Instance Refresh يستبدل سيرفرات المجموعة بالتدريج. فكل سيرفر يطابق اللي اختبرته، والرجوع يعني ترجع للصورة السابقة.

التكلفة في هذا التصميم #

• غطّ الحد الأدنى بخطة توفير، فهو شغّال طول الوقت.
• خل الزيادات On-Demand أو Spot.
• راجع الحد الأدنى كل فترة، وكثير يبالغون فيه.

Elastic Beanstalk: الطريق المختصر #

تجميع كل هذا بيدك شغل. Elastic Beanstalk يسويه عنك: ترفع الكود وتختار اللغة، وهو ينشئ الموزّع ومجموعة التوسّع والسيرفرات والمراقبة. والخدمة نفسها مجانية، وتدفع على الموارد اللي تنشئها.

• بيئتين شائعتين: سيرفر واحد للتطوير بتكلفة قليلة، أو عدة سيرفرات خلف موزّع للإنتاج.
• نوعين من الطبقات: Web Server للطلبات المباشرة، وWorker لمعالجة المهام من طابور.
• الموارد عادية وظاهرة: تشوفها في حسابك وتقدر تعدّلها، ما هي صندوق مغلق.

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

الخلاصة #

• ASG تحافظ على عدد السيرفرات بين حد أدنى وأعلى، وتستبدل المعطّل، وتتكامل مع الموزّع.
• Launch Template وصفة السيرفر، وصورة AMI الجاهزة تسرّع الاستجابة.
• فعّل ELB health checks عشان يُستبدل السيرفر لما يتعطّل التطبيق نفسه.
• ابدأ بسياسة Target tracking، واختر المقياس اللي يعبّر عن الضغط فعلاً.
• خل السيرفرات عديمة الحالة: أي شي مهم يعيش خارجها.

اختبر نفسك #

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

بهذا نكمل قسم التوفر العالي. السؤال اللي بقى: وين تعيش البيانات لما تكون خارج السيرفر؟ هذا موضوع القسم الجاي، ونبدأه في الجزء الثامن بقواعد البيانات المُدارة RDS وAurora.