Scaling¶

Vertical, horizontal, auto-scaling, scaling predictif et scale-to-zero.

Vertical vs horizontal¶

Deux philosophies fondamentales pour augmenter la capacité.

Arbre de décision¶

graph TD
    A["Besoin de plus\nde capacite"] --> B{"Application\nstateless ?"}
    B -->|Non| C["Scaling vertical\nou refactorisation"]
    B -->|Oui| D{"Limite instance\natteinte ?"}
    D -->|Non| E{"Pic court\nou permanent ?"}
    D -->|Oui| F["Scaling horizontal\nobligatoire"]
    E -->|Court| G["Auto-scaling\n(scale out/in)"]
    E -->|Permanent| H["Scaling horizontal\n+ revue baseline"]
    C --> I{"Migration\npossible ?"}
    I -->|Oui| F
    I -->|Non| J["Vertical seul\n(accepter la limite)"]

Auto-scaling¶

L'auto-scaling ajuste automatiquement le nombre d'instances ou les ressources selon la charge.

Mécanismes principaux¶

Parametres critiques d'un auto-scaler¶

• Métrique de déclenchement : CPU moyen, requêtes en attente, latence p95
• Seuil de scale-out : ex. CPU > 70 % pendant 3 minutes
• Seuil de scale-in : ex. CPU < 30 % pendant 10 minutes (cool-down plus long)
• Min/Max instances : bornes absolues — le max est un garde-fou budgetaire
• Cool-down period : temps de stabilisation entre deux décisions d'auto-scaling

Scaling predictif¶

Le scaling predictif anticipe les besoins avant que la charge n'augmente.

Approches¶

Scheduled scaling — exemple de logique¶

• Identifier les patterns recurents dans la baseline (heures de pointe par jour de semaine)
• Configurer le scale-out 15 minutes avant le pic prévu (latence de démarrage instance)
• Configurer le scale-in 30 minutes après la fin du pic (amortir les queues residuelles)

Limites du scaling predictif¶

• Un modèle ML nécessité plusieurs mois de données d'entrainement
• Les événements non historiques (viralite soudaine) ne sont pas predictibles
• Le coût du sur-provisionnement predictif doit être compare au coût d'un incident

Scale-to-zero¶

Le scale-to-zero descend à zero instance quand il n'y a pas de trafic, éliminant les coûts d'attente.

Cold start : le compromis¶

• Avantage : zero coût quand inactif, idéal pour charges intermittentes
• Inconvénient : première requête après silence = latence élevée (cold start)
• Mitigation : provisioned concurrency (Lambda), min-instances = 1 (Cloud Run), warm-up requests

Limites et quotas¶

Tout environnement cloud impose des limites qu'il faut intégrer dans le capacity planning.

Points clés¶

• Scaling vertical pour les composants avec état (databases), horizontal pour les services stateless
• L'auto-scaler sans borne supérieure est un risque financier — toujours fixer un max
• Le scaling predictif (schedule + ML) complement l'auto-scaling reactif sur les pics prévisibles
• Scale-to-zero convient aux charges intermittentes, pas aux SLA stricts
• Anticiper les quotas cloud et en demander l'augmentation avant d'en avoir besoin