أساسيات السحابة: خدمات AWS الأساسية

مجموعات الضبط التلقائي وموازن الأحمال

18 دقيقة الدرس 7 من 30

مجموعات الضبط التلقائي وموازن الأحمال

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

يغطي هذا الدرس الصورة الكاملة: كيف تصف قوالب الإطلاق ما يجب تشغيله، وكيف تقرر مجموعات ASG متى تُطلق الخوادم وكم عددها، وكيف تضمن مجموعات الهدف مع فحوصات الصحة وصول الطلبات فقط إلى الخوادم السليمة — مع التركيز على حالات الفشل الإنتاجي الحقيقية في كل مرحلة.

قوالب الإطلاق: المخطط الثابت

قالب الإطلاق (LT) هو مواصفة منسوخة وغير قابلة للتعديل لكل ما يلزم لتشغيل خادم EC2: معرّف AMI، ونوع الخادم، وزوج المفاتيح، ومجموعات الأمان، وملف تعريف IAM، وبيانات المستخدم، وأقراص EBS، والإعدادات الشبكية. يحل محل إعداد الإطلاق القديم (مهمل الآن — لا تستخدمه في أحمال العمل الجديدة).

الميزة الأبرز لقوالب الإطلاق على إعدادات الإطلاق هي إصدار النسخ. يمكنك امتلاك نسخة $Default ونسخة $Latest، ويمكن لمجموعة ASG تثبيت نسخة محددة حتى لا يؤدي تحديث AMI معطوب إلى الطرح التلقائي على الإنتاج. هذا بالغ الأهمية على النطاق الواسع: في كبرى الشركات، تتحكم أنابيب CI/CD في إصدار قالب الإطلاق وتُرقيه عبر بوابات dev ← staging ← production.

## إنشاء قالب إطلاق عبر AWS CLI aws ec2 create-launch-template \ --launch-template-name "myapp-prod-lt" \ --version-description "v1.0 — الخبز الأول للصورة الذهبية" \ --launch-template-data '{ "ImageId": "ami-0a1b2c3d4e5f67890", "InstanceType": "m7g.large", "IamInstanceProfile": { "Arn": "arn:aws:iam::123456789012:instance-profile/myapp-ec2-profile" }, "SecurityGroupIds": ["sg-0abc123def456"], "UserData": "IyEvYmluL2Jhc2gKc2V0IC1ldW8gcGlwZWZhaWw=", "BlockDeviceMappings": [ { "DeviceName": "/dev/xvda", "Ebs": { "VolumeSize": 30, "VolumeType": "gp3", "Iops": 3000, "Encrypted": true, "DeleteOnTermination": true } } ], "MetadataOptions": { "HttpTokens": "required", "HttpPutResponseHopLimit": 1 }, "TagSpecifications": [ { "ResourceType": "instance", "Tags": [ {"Key": "Name", "Value": "myapp-prod"}, {"Key": "Environment", "Value": "production"}, {"Key": "ManagedBy", "Value": "ASG"} ] } ] }'
IMDSv2 إلزامي في الإنتاج. إعداد MetadataOptions.HttpTokens: required يفرض IMDSv2 (الوصول إلى البيانات الوصفية عبر رمز جلسة). إصدار IMDSv1 قابل للاستغلال عبر ثغرات SSRF — إذا تمكّن مهاجم من جعل تطبيقك يرسل طلب HTTP إلى 169.254.169.254، يمكنه سرقة بيانات اعتماد دور الخادم. يشترط IMDSv2 إرسال طلب PUT أولًا للحصول على رمز جلسة، وهو ما لا تستطيع SSRF تنفيذه. اضبط هذا الإعداد في كل قالب إطلاق تنشئه دون استثناء.

مجموعات الضبط التلقائي: أساطيل تصحح نفسها

مجموعة الضبط التلقائي تحافظ على أسطول من خوادم EC2 بين عدد أدنى وأقصى محددين. تستخدم قالب الإطلاق لتشغيل خوادم جديدة وتوقف القديمة بناءً على سياسات الضبط ونتائج فحوصات الصحة. مجموعة ASG هي الكيان الذي يربط قالب الإطلاق (ما يجب تشغيله) بمجموعة الهدف (أين يسجّل) ومقاييس CloudWatch (متى يضبط).

معاملات الضبط الرئيسية لمجموعة ASG:

  • MinSize / MaxSize / DesiredCapacity — الحد الأدنى والأقصى والعدد المستهدف الحالي. في الإنتاج، لا تضبط MinSize على صفر ما لم يكن الحمل مجدولًا تمامًا في أوقات غير الذروة.
  • التوزيع متعدد AZ — يجب دائمًا أن تمتد على منطقتَي توفر على الأقل. تتحكم قائمة AvailabilityZones أو VPCZoneIdentifier (معرّفات الشبكات الفرعية) في ذلك. عند فشل AZ-a، تطلق مجموعة ASG تلقائيًا بدائل في AZ-b.
  • نوع فحص الصحة — إما EC2 (فحوصات حالة الخادم فقط) أو ELB (نتيجة فحص صحة موازن الأحمال). استخدم دائمًا ELB في الإنتاج: قد ينجح الخادم في فحوصات EC2 بينما تطبيقك معطوب تمامًا.
  • وقت الإحماء / فترة التبريد — DefaultInstanceWarmup يخبر مجموعة ASG بالمدة التي يحتاجها الخادم الجديد ليصبح جاهزًا قبل احتساب مقاييسه في قرارات الضبط. بدونه، ترى CloudWatch متوسط حمل مرتفعًا مؤقتًا أثناء التشغيل الأولي فتُوفّر أكثر من اللازم.
## إنشاء مجموعة ASG مرتبطة بقالب الإطلاق ومجموعة هدف aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name "myapp-prod-asg" \ --launch-template "LaunchTemplateName=myapp-prod-lt,Version=1" \ --min-size 2 \ --max-size 20 \ --desired-capacity 4 \ --vpc-zone-identifier "subnet-aaa111,subnet-bbb222,subnet-ccc333" \ --target-group-arns "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/myapp-prod-tg/abc123" \ --health-check-type ELB \ --health-check-grace-period 120 \ --default-instance-warmup 90 \ --termination-policies "OldestLaunchTemplate" "AllocationStrategy" \ --capacity-rebalance ## إرفاق سياسة ضبط بتتبع الهدف (ضبط عند 60% متوسط CPU) aws autoscaling put-scaling-policy \ --auto-scaling-group-name "myapp-prod-asg" \ --policy-name "myapp-cpu-tracking" \ --policy-type TargetTrackingScaling \ --target-tracking-configuration '{ "TargetValue": 60.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" }, "ScaleInCooldown": 300, "ScaleOutCooldown": 60 }'
استخدم سياسات تتبع الهدف بدلًا من الضبط المتدرج لمعظم الخدمات — فهي تضبط نفسها تلقائيًا وأسهل بكثير في الاستيعاب. احتفظ بالضبط المتدرج للأحمال التي لديك فيها آراء محددة بشأن أحجام الخطوات. للخدمات الحساسة للتأخير، تتبّع RequestCountPerTarget على ALB بدلًا من CPU — فهو يتفاعل أسرع ويرتبط مباشرةً بتجربة المستخدم.

مجموعات الهدف وفحوصات الصحة: العقد بين ALB وASG

مجموعة الهدف (TG) هي الآلية التي يعرف من خلالها موازن الأحمال التطبيقي (ALB) أو موازن أحمال الشبكة (NLB) أيّ الخوادم (أو عناوين IP، أو وظائف Lambda) يوجّه إليها الطلبات. عند ربط مجموعة هدف بمجموعة ASG، يُسجَّل كل خادم تُطلقه مجموعة ASG تلقائيًا في مجموعة الهدف؛ وكل خادم توقفه يُلغى تسجيله. هذا يتم بسلاسة — لكن فحوصات الصحة هي ما يجعله آمنًا.

يستطلع فحص صحة مجموعة الهدف باستمرار كل هدف مسجّل على مسار ومنفذ محددين. النتائج:

  • سليم (Healthy) — الهدف في دورة التوزيع ويستقبل الطلبات.
  • غير سليم (Unhealthy) — يُخرج الهدف من الدورة. بعد عدد محدد من الإخفاقات المتتالية، تستقبل مجموعة ASG إشعار الفشل وتوقف الخادم وتستبدله.
  • أولي (Initial) — الهدف تسجّل للتو وهو في فترة السماح قبل بدء فحوصات الصحة.
  • استنزاف (Draining) — عند تحديد خادم للإيقاف، تنتظر مجموعة الهدف حتى deregistration_delay ثانية لإتمام الطلبات الجارية قبل قطع الاتصالات. القيمة الافتراضية 300 ثانية — طويلة جدًا لمعظم التطبيقات؛ اضبطها بين 30 و60 ثانية لتسريع عمليات النشر المتجددة.
## إنشاء مجموعة هدف مع فحص صحة هادف aws elbv2 create-target-group \ --name "myapp-prod-tg" \ --protocol HTTP \ --port 8080 \ --vpc-id vpc-0abc1234 \ --target-type instance \ --health-check-protocol HTTP \ --health-check-path /health \ --health-check-interval-seconds 15 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 3 \ --matcher HttpCode=200 ## تقليل تأخير إلغاء التسجيل لتسريع النشر المتجدد aws elbv2 modify-target-group-attributes \ --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/myapp-prod-tg/abc123 \ --attributes Key=deregistration_delay.timeout_seconds,Value=30 ## إنشاء مستمع ALB يوجّه إلى مجموعة الهدف aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/myapp-alb/xyz \ --protocol HTTPS \ --port 443 \ --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \ --certificates CertificateArn=arn:aws:acm:us-east-1:123456789012:certificate/abc \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/myapp-prod-tg/abc123
مسار فحص صحة سطحي قنبلة موقوتة في الإنتاج. إذا كان مسار /health يُعيد HTTP 200 دون التحقق فعليًا مما إذا كان تطبيقك متصلًا بقاعدة البيانات أو بالخدمات المعتمدة أو قارئًا لإعداداته، فإن ALB سيوجّه الطلبات بسعادة إلى خادم معطوب يُعيد 200 عند فحص الصحة و500 عند الطلبات الحقيقية. ابنِ فحص صحة عميقًا يتحقق من كل التبعيات الحرجة — واجعله سريعًا (أقل من ثانيتين). افصل الفحص العميق عن فحص الحياة إذا كان تطبيقك يحتاج وقتًا طويلًا للبدء.

الثلاثي: كيف يعمل قالب الإطلاق وASG ومجموعة الهدف معًا

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

Launch Template, ASG, and Target Group trio — request path and scaling loop User Browser HTTPS ALB Listener :443 Listener Rules SSL Termination forward Target Group Health checks GET /health → 200 Draining delay Instance 1 AZ-a :8080 Instance 2 AZ-b :8080 Instance 3 AZ-c :8080 Auto Scaling Group Launch Template AMI + type + IAM + SG uses CloudWatch CPU / RPS alarm Scale out / in signal Launch Template + ASG + Target Group Trio Request path (blue) and scaling control loop (red/green)
الثلاثي في الإنتاج: يوجّه ALB الطلبات إلى الخوادم السليمة المسجّلة في مجموعة الهدف؛ تستخدم مجموعة ASG قالب الإطلاق لتزويد بدائل وتضبط الأسطول بناءً على إنذارات CloudWatch.

تحديث الخوادم: طرح تحديثات AMI بدون توقف

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

## تشغيل تحديث خوادم لطرح نسخة جديدة من قالب الإطلاق aws autoscaling start-instance-refresh \ --auto-scaling-group-name "myapp-prod-asg" \ --preferences '{ "MinHealthyPercentage": 90, "InstanceWarmup": 120, "CheckpointPercentages": [33, 66, 100], "CheckpointDelay": 600, "SkipMatching": false }' \ --desired-configuration '{ "LaunchTemplate": { "LaunchTemplateName": "myapp-prod-lt", "Version": "2" } }' ## مراقبة حالة التحديث aws autoscaling describe-instance-refreshes \ --auto-scaling-group-name "myapp-prod-asg" \ --query 'InstanceRefreshes[0].{Status:Status,Percentage:PercentageComplete}' \ --output table
استخدم التحديثات المبنية على نقاط تفتيش للأساطيل الكبيرة. ضبط CheckpointPercentages على [33, 66, 100] مع CheckpointDelay 600 ثانية يعني توقف التحديث عند 33% و66%. يمنح هذا منظومة المراقبة وقتًا لاكتشاف الانحدارات قبل تحديث الأسطول بأكمله. مقترنًا بفحوصات Canary الآلية في أنبوب النشر، يمنحك هذا النمط أمان مشابه للتوزيع الأزرق/الأخضر بإعدادية أبسط بكثير.

أنماط الفشل الإنتاجية التي يجب معرفتها

هذه هي أكثر سيناريوهات الفشل شيوعًا في مجموعات ASG وELB في بيئات الإنتاج الحقيقية:

  • فترة سماح فحص الصحة قصيرة جدًا — إذا كانت HealthCheckGracePeriod أقصر من وقت بدء تشغيل تطبيقك، ستصنّف مجموعة ASG الخوادم الجديدة كغير سليمة وتوقفها فورًا. يدخل الأسطول بعدها في حلقة إطلاق/إيقاف مستمرة. اضبط فترة السماح على 1.5x من وقت البدء عند النسبة المئوية p99.
  • تأخير إلغاء التسجيل طويل جدًا — التأخير الافتراضي 300 ثانية يعيق عمليات النشر المتجددة. تبقى الخوادم في حالة draining خمس دقائق حتى مع غياب أي اتصالات جارية. اضبطه بين 30 و60 ثانية للخدمات HTTP عديمة الحالة.
  • سياسة الإنهاء تستهدف الخادم الخطأ — تزيل سياسة الإنهاء الافتراضية الخوادم من منطقة التوفر الأكثر عددًا، ثم الأقدم نسخة، ثم الأقرب لإعادة الفوترة. هذا صحيح عادةً، لكن إن كانت لديك خوادم ذات حالة (مثل وسيط Kafka)، أضف خطاف دورة حياة (lifecycle hook) عند الإنهاء لاستنزاف الوسيط بسلاسة قبل إيقاف الخادم.
  • إعادة التوازن للخوادم المؤقتة (Spot) غير مفعّلة — عند استخدام Spot Instances في سياسة مثيلات مختلطة، فعّل capacityRebalance: true على مجموعة ASG. بدونه، تُوقف AWS خوادم Spot بإشعار مدته دقيقتان فقط مما يسبب فقدانًا مفاجئًا. بتفعيله، تطلق مجموعة ASG بديلًا بشكل استباقي عند وصول إشعار توقف Spot.
الدرس السابق RDS وقواعد البيانات المُدارة
الدرس التالي أساسيات CloudWatch
العودة للدورة