سياسات التوسع
أنواع السياسات
نظرة عامة
┌─────────────────────────────────────────────────────────────┐
│ أنواع السياسات │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ TARGET TRACKING (موصى به) │ │
│ │ ──────────────────────────── │ │
│ │ "الحفاظ على CPU عند 50%" │ │
│ │ AWS تدير كل شيء تلقائيًا │ │
│ │ ✅ بسيط ✅ فعال ✅ موصى به │ │
│ │ │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ │ │
│ │ STEP SCALING │ │
│ │ ──────────── │ │
│ │ "إذا كان CPU 60-80% → +1، إذا كان CPU 80%+ → +3" │ │
│ │ استجابة تناسبية للفارق │ │
│ │ ⚠️ أكثر تعقيدًا ✅ تحكم دقيق │ │
│ │ │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ │ │
│ │ SIMPLE SCALING (قديم) │ │
│ │ ─────────────────────── │ │
│ │ "إذا كان CPU > 70% → +1" │ │
│ │ فترة تهدئة إلزامية بين الإجراءات │ │
│ │ ❌ قديم ❌ أقل تفاعلاً │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Target Tracking - تفاصيل
مقاييس محددة مسبقًا
┌─────────────────────────────────────────────────────────────┐
│ مقاييس TARGET TRACKING │
├─────────────────────────────────────────────────────────────┤
│ │
│ المقياس الهدف الموصى به │
│ ──────── ───────────────── │
│ │
│ ASGAverageCPUUtilization 40-70% │
│ (متوسط CPU للمجموعة) │
│ │
│ ASGAverageNetworkIn حسب التطبيق │
│ (حركة الشبكة الواردة) │
│ │
│ ASGAverageNetworkOut حسب التطبيق │
│ (حركة الشبكة الصادرة) │
│ │
│ ALBRequestCountPerTarget 1000-5000 طلب/هدف │
│ (الطلبات لكل مثيل عبر ALB) │
│ │
│ ──────────────────────────────────────────────────────── │
│ │
│ اختيار المقياس: │
│ │
│ • تطبيق يعتمد على CPU (حسابي) → ASGAverageCPUUtilization │
│ • تطبيق يعتمد على I/O (شبكة) → ASGAverageNetworkIn/Out │
│ • ويب/API → ALBRequestCountPerTarget │
│ │
└─────────────────────────────────────────────────────────────┘
تكوين Target Tracking
# سياسة تعتمد على CPU
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name cpu-tracking \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"TargetValue": 50.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
},
"ScaleOutCooldown": 60,
"ScaleInCooldown": 300
}'
# سياسة تعتمد على طلبات ALB
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name request-tracking \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"TargetValue": 1000.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ALBRequestCountPerTarget",
"ResourceLabel": "app/my-alb/xxx/targetgroup/my-tg/yyy"
}
}'
مقاييس مخصصة
للاحتياجات الخاصة، يمكنك إنشاء مقياس CloudWatch مخصص:
# نشر مقياس مخصص من التطبيق
aws cloudwatch put-metric-data \
--namespace "MyApp" \
--metric-name "QueueDepth" \
--value 150 \
--unit Count
# سياسة Target Tracking على مقياس مخصص
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name queue-tracking \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"TargetValue": 100.0,
"CustomizedMetricSpecification": {
"MetricName": "QueueDepth",
"Namespace": "MyApp",
"Statistic": "Average"
}
}'
Step Scaling - تفاصيل
تكوين حسب المراحل
┌─────────────────────────────────────────────────────────────┐
│ STEP SCALING - مثال │
├─────────────────────────────────────────────────────────────┤
│ │
│ إنذار: CPUUtilization > 60% │
│ │
│ المراحل: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ الفارق عن العتبة الإجراء │ │
│ │ ───────────────── ────── │ │
│ │ │ │
│ │ 60% ──► 70% (+0 إلى +10) +1 مثيل │ │
│ │ 70% ──► 80% (+10 إلى +20) +2 مثيلات │ │
│ │ 80% ──► ∞ (+20 إلى +∞) +3 مثيلات │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ مثال ملموس: │
│ • CPU عند 65% → الفارق = +5 → +1 مثيل │
│ • CPU عند 75% → الفارق = +15 → +2 مثيلات │
│ • CPU عند 90% → الفارق = +30 → +3 مثيلات │
│ │
│ الميزة: استجابة تناسبية للطوارئ │
│ │
└─────────────────────────────────────────────────────────────┘
تكوين CLI
# 1. إنشاء إنذار CloudWatch
aws cloudwatch put-metric-alarm \
--alarm-name cpu-high \
--metric-name CPUUtilization \
--namespace AWS/EC2 \
--statistic Average \
--period 60 \
--threshold 60 \
--comparison-operator GreaterThanOrEqualToThreshold \
--dimensions Name=AutoScalingGroupName,Value=my-asg \
--evaluation-periods 2 \
--alarm-actions arn:aws:autoscaling:...:scalingPolicy:...:policyName/step-scale-out
# 2. إنشاء سياسة Step Scaling
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name step-scale-out \
--policy-type StepScaling \
--adjustment-type ChangeInCapacity \
--step-adjustments '[
{
"MetricIntervalLowerBound": 0,
"MetricIntervalUpperBound": 10,
"ScalingAdjustment": 1
},
{
"MetricIntervalLowerBound": 10,
"MetricIntervalUpperBound": 20,
"ScalingAdjustment": 2
},
{
"MetricIntervalLowerBound": 20,
"ScalingAdjustment": 3
}
]'
Scheduled Scaling
الأنماط الشائعة
┌─────────────────────────────────────────────────────────────┐
│ SCHEDULED SCALING - الأنماط │
├─────────────────────────────────────────────────────────────┤
│ │
│ النمط 1 : ساعات العمل (9ص-6م) │
│ ────────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ الإثنين-الجمعة 9ص : min=5، max=20، desired=5 │ │
│ │ الإثنين-الجمعة 6م : min=2، max=5، desired=2 │ │
│ │ السبت-الأحد : min=1، max=3 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ النمط 2 : التجارة الإلكترونية (الذروات والتخفيضات) │
│ ──────────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ عادي : min=3، max=10 │ │
│ │ الجمعة السوداء: min=20، max=50 (من 28 إلى 30 نوفمبر) │ │
│ │ عيد الميلاد : min=15، max=40 (15-26 ديسمبر) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ النمط 3 : معالجة الدفعات (ليلاً) │
│ ──────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ النهار (8ص-8م) : min=2، max=5 │ │
│ │ الليل (8م-8ص) : min=10، max=30 (وظائف الدفعات) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
التكوين
# زيادة التوسع في الصباح (الإثنين-الجمعة الساعة 8:30 صباحًا بتوقيت UTC)
aws autoscaling put-scheduled-update-group-action \
--auto-scaling-group-name my-asg \
--scheduled-action-name morning-scale-up \
--recurrence "30 8 * * MON-FRI" \
--min-size 5 \
--max-size 20 \
--desired-capacity 5
# تقليل التوسع في المساء (الإثنين-الجمعة الساعة 6 مساءً بتوقيت UTC)
aws autoscaling put-scheduled-update-group-action \
--auto-scaling-group-name my-asg \
--scheduled-action-name evening-scale-down \
--recurrence "0 18 * * MON-FRI" \
--min-size 2 \
--max-size 5 \
--desired-capacity 2
# عطلة نهاية الأسبوع (السبت الساعة 0 صباحًا)
aws autoscaling put-scheduled-update-group-action \
--auto-scaling-group-name my-asg \
--scheduled-action-name weekend-scale-down \
--recurrence "0 0 * * SAT" \
--min-size 1 \
--max-size 3
# حدث خاص (الجمعة السوداء)
aws autoscaling put-scheduled-update-group-action \
--auto-scaling-group-name my-asg \
--scheduled-action-name black-friday \
--start-time "2024-11-28T00:00:00Z" \
--end-time "2024-12-01T00:00:00Z" \
--min-size 20 \
--max-size 50
دمج السياسات
الاستراتيجية الموصى بها
┌─────────────────────────────────────────────────────────────┐
│ دمج السياسات │
├─────────────────────────────────────────────────────────────┤
│ │
│ أفضل ممارسة: دمج أنواع متعددة │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. SCHEDULED (أساسي) │ │
│ │ ───────────────── │ │
│ │ يحدد الحد الأدنى/الأقصى حسب الأنماط المعروفة │ │
│ │ مثال: زيادة السعة في ساعات العمل │ │
│ │ │ │
│ │ + │ │
│ │ │ │
│ │ 2. TARGET TRACKING (تعديل دقيق) │ │
│ │ ─────────────────────────────── │ │
│ │ تعديل ضمن الحدود الدنيا/العليا │ │
│ │ مثال: الحفاظ على CPU عند 50% │ │
│ │ │ │
│ │ = │ │
│ │ │ │
│ │ بنية مثالية! │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ مثال: │
│ • Scheduled : 9ص → min:5، max:20 │
│ • Target Tracking : CPU 50% │
│ • النتيجة : بين 9ص و 6م، يتراوح عدد المثيلات بين 5 و 20 │
│ للحفاظ على CPU عند 50% │
│ │
└─────────────────────────────────────────────────────────────┘
أفضل الممارسات
قائمة التحقق من التكوين
┌─────────────────────────────────────────────────────────────┐
│ قائمة التحقق من أفضل الممارسات │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✅ عام │
│ ──────── │
│ ☐ Min >= 2 (توفر عالي) │
│ ☐ مثيلات في 2+ AZ │
│ ☐ فحوصات الصحة EC2 و ELB مفعلة │
│ ☐ سياسة الإنهاء المناسبة │
│ │
│ ✅ TARGET TRACKING │
│ ───────────────── │
│ ☐ قيمة الهدف ليست عدوانية جدًا (50-70% CPU) │
│ ☐ فترة تهدئة قصيرة للتوسع (60 ثانية) │
│ ☐ فترة تهدئة أطول للتقليص (300 ثانية) │
│ ☐ تسخين كافٍ للتطبيق │
│ │
│ ✅ المثيلات │
│ ─────────── │
│ ☐ بيانات المستخدم متكررة وسريعة │
│ ☐ AMI مهيأة مسبقًا (تقليل وقت بدء التشغيل) │
│ ☐ تطبيق عديم الحالة │
│ ☐ إيقاف تشغيل سلس (خطافات دورة الحياة) │
│ │
│ ❌ لتجنبها │
│ ───────── │
│ ☐ Min = Max = 1 (لا يوجد توفر عالي) │
│ ☐ عتبات حساسة جدًا (تذبذبات) │
│ ☐ فترة تهدئة قصيرة جدًا (توسع متكرر جدًا) │
│ ☐ عدم مراقبة المقاييس │
│ │
└─────────────────────────────────────────────────────────────┘
استكشاف الأخطاء وإصلاحها
| المشكلة | السبب المحتمل | الحل |
|---|---|---|
| التوسع بطيء جدًا | فترة التهدئة طويلة جدًا | تقليل فترة التهدئة للتوسع |
| تذبذبات | العتبات قريبة جدًا | زيادة الفارق بين العتبات |
| لا يتوسع | لم يتم استلام المقاييس | تحقق من CloudWatch Agent |
| تقليص يقتل المثيلات النشطة | لا توجد فترة سماح | إضافة خطافات دورة الحياة |
ملخص
| النوع | حالة الاستخدام | التعقيد |
|---|---|---|
| Target Tracking | 90% من الحالات، موصى به | ⭐ سهل |
| Scheduled | أنماط متوقعة | ⭐⭐ متوسط |
| Step | استجابة تناسبية | ⭐⭐⭐ متقدم |
| Combiné | إنتاجية مثالية | ⭐⭐ متوسط |
القسم التالي : مختبر التوسع التلقائي