Politiques de Scaling
Types de Politiques
Vue d'Ensemble
┌─────────────────────────────────────────────────────────────┐
│ TYPES DE POLITIQUES │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ TARGET TRACKING (recommandé) │ │
│ │ ──────────────────────────── │ │
│ │ "Maintenir CPU à 50%" │ │
│ │ AWS gère tout automatiquement │ │
│ │ ✅ Simple ✅ Efficace ✅ Recommandé │ │
│ │ │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ │ │
│ │ STEP SCALING │ │
│ │ ──────────── │ │
│ │ "Si CPU 60-80% → +1, Si CPU 80%+ → +3" │ │
│ │ Réponse proportionnelle à l'écart │ │
│ │ ⚠️ Plus complexe ✅ Contrôle fin │ │
│ │ │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ │ │
│ │ SIMPLE SCALING (legacy) │ │
│ │ ─────────────────────── │ │
│ │ "Si CPU > 70% → +1" │ │
│ │ Cooldown obligatoire entre actions │ │
│ │ ❌ Ancien ❌ Moins réactif │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Target Tracking - Détails
Métriques Prédéfinies
┌─────────────────────────────────────────────────────────────┐
│ MÉTRIQUES TARGET TRACKING │
├─────────────────────────────────────────────────────────────┤
│ │
│ MÉTRIQUE CIBLE RECOMMANDÉE │
│ ──────── ───────────────── │
│ │
│ ASGAverageCPUUtilization 40-70% │
│ (CPU moyen du groupe) │
│ │
│ ASGAverageNetworkIn Selon app │
│ (Trafic réseau entrant) │
│ │
│ ASGAverageNetworkOut Selon app │
│ (Trafic réseau sortant) │
│ │
│ ALBRequestCountPerTarget 1000-5000 req/target │
│ (Requêtes par instance via ALB) │
│ │
│ ──────────────────────────────────────────────────────── │
│ │
│ Choix de la métrique : │
│ │
│ • App CPU-bound (calcul) → ASGAverageCPUUtilization │
│ • App I/O-bound (réseau) → ASGAverageNetworkIn/Out │
│ • Web/API → ALBRequestCountPerTarget │
│ │
└─────────────────────────────────────────────────────────────┘
Configuration Target Tracking
# Politique basée sur 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
}'
# Politique basée sur requêtes 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"
}
}'
Métriques Personnalisées
Pour des besoins spécifiques, vous pouvez créer une métrique CloudWatch personnalisée :
# Publier une métrique custom depuis l'application
aws cloudwatch put-metric-data \
--namespace "MyApp" \
--metric-name "QueueDepth" \
--value 150 \
--unit Count
# Politique Target Tracking sur métrique custom
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 - Détails
Configuration par Paliers
┌─────────────────────────────────────────────────────────────┐
│ STEP SCALING - EXEMPLE │
├─────────────────────────────────────────────────────────────┤
│ │
│ Alarm : CPUUtilization > 60% │
│ │
│ Steps : │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Écart par rapport au seuil Action │ │
│ │ ────────────────────────── ────── │ │
│ │ │ │
│ │ 60% ──► 70% (+0 à +10) +1 instance │ │
│ │ 70% ──► 80% (+10 à +20) +2 instances │ │
│ │ 80% ──► ∞ (+20 à +∞) +3 instances │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Exemple concret : │
│ • CPU à 65% → écart = +5 → +1 instance │
│ • CPU à 75% → écart = +15 → +2 instances │
│ • CPU à 90% → écart = +30 → +3 instances │
│ │
│ Avantage : Réponse proportionnelle à l'urgence │
│ │
└─────────────────────────────────────────────────────────────┘
Configuration CLI
# 1. Créer l'alarme 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. Créer la politique 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
Patterns Communs
┌─────────────────────────────────────────────────────────────┐
│ SCHEDULED SCALING - PATTERNS │
├─────────────────────────────────────────────────────────────┤
│ │
│ PATTERN 1 : Heures de bureau (9h-18h) │
│ ────────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Lun-Ven 9h : min=5, max=20, desired=5 │ │
│ │ Lun-Ven 18h : min=2, max=5, desired=2 │ │
│ │ Sam-Dim : min=1, max=3 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ PATTERN 2 : E-commerce (pics et soldes) │
│ ──────────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Normal : min=3, max=10 │ │
│ │ Black Friday: min=20, max=50 (du 28 au 30 nov) │ │
│ │ Noël : min=15, max=40 (15-26 déc) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ PATTERN 3 : Traitement batch (nuit) │
│ ──────────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Jour (8h-20h) : min=2, max=5 │ │
│ │ Nuit (20h-8h) : min=10, max=30 (batch jobs) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Configuration
# Scale up le matin (Lun-Ven à 8h30 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
# Scale down le soir (Lun-Ven à 18h 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
# Week-end (Samedi à 0h)
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
# Événement ponctuel (Black Friday)
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
Combiner les Politiques
Stratégie Recommandée
┌─────────────────────────────────────────────────────────────┐
│ COMBINAISON DE POLITIQUES │
├─────────────────────────────────────────────────────────────┤
│ │
│ Meilleure pratique : Combiner plusieurs types │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. SCHEDULED (base) │ │
│ │ ───────────────── │ │
│ │ Définit les min/max selon patterns connus │ │
│ │ Ex: Plus de capacité aux heures de bureau │ │
│ │ │ │
│ │ + │ │
│ │ │ │
│ │ 2. TARGET TRACKING (ajustement fin) │ │
│ │ ─────────────────────────────── │ │
│ │ Ajuste dans les limites min/max │ │
│ │ Ex: Maintenir CPU à 50% │ │
│ │ │ │
│ │ = │ │
│ │ │ │
│ │ Architecture optimale ! │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Exemple : │
│ • Scheduled : 9h → min:5, max:20 │
│ • Target Tracking : CPU 50% │
│ • Résultat : Entre 9h et 18h, le nombre d'instances │
│ varie entre 5 et 20 pour maintenir CPU à 50% │
│ │
└─────────────────────────────────────────────────────────────┘
Bonnes Pratiques
Checklist Configuration
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST BONNES PRATIQUES │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✅ GÉNÉRAL │
│ ──────── │
│ ☐ Min >= 2 (haute disponibilité) │
│ ☐ Instances dans 2+ AZ │
│ ☐ Health checks EC2 ET ELB activés │
│ ☐ Termination policy appropriée │
│ │
│ ✅ TARGET TRACKING │
│ ───────────────── │
│ ☐ Target value pas trop agressive (50-70% CPU) │
│ ☐ Scale out cooldown court (60s) │
│ ☐ Scale in cooldown plus long (300s) │
│ ☐ Warmup suffisant pour l'application │
│ │
│ ✅ INSTANCES │
│ ─────────── │
│ ☐ User data idempotent et rapide │
│ ☐ AMI pré-configurée (réduire startup time) │
│ ☐ Application stateless │
│ ☐ Graceful shutdown (lifecycle hooks) │
│ │
│ ❌ À ÉVITER │
│ ───────── │
│ ☐ Min = Max = 1 (pas de HA) │
│ ☐ Seuils trop sensibles (oscillations) │
│ ☐ Cooldown trop court (scaling trop fréquent) │
│ ☐ Pas de monitoring des métriques │
│ │
└─────────────────────────────────────────────────────────────┘
Troubleshooting
| Problème | Cause Probable | Solution |
|---|---|---|
| Scaling trop lent | Cooldown trop long | Réduire scale out cooldown |
| Oscillations | Seuils trop proches | Augmenter l'écart entre seuils |
| Ne scale pas | Métriques pas reçues | Vérifier CloudWatch Agent |
| Scale in tue instances actives | Pas de grace period | Ajouter lifecycle hooks |
Résumé
| Type | Cas d'usage | Complexité |
|---|---|---|
| Target Tracking | 90% des cas, recommandé | ⭐ Facile |
| Scheduled | Patterns prévisibles | ⭐⭐ Moyen |
| Step | Réponse proportionnelle | ⭐⭐⭐ Avancé |
| Combiné | Production optimale | ⭐⭐ Moyen |
Prochaine section : Lab Auto Scaling