Auto-scaling pour site indépendant : absorber les pics de trafic, choisir sa stratégie, maîtriser les coûts et surveiller
1. À quoi ressemblent les pics de trafic d’un site indépendant
La courbe de trafic d’un site indépendant n’a rien à voir avec celle d’une application grand public. Sur une app grand public, le pic est aléatoire : une vidéo virale, une tendance, et le trafic est multiplié par 10 en 10 minutes. Sur un site indépendant, les pics sont presque toujours prévisibles : campagne lancée une semaine avant un salon professionnel, jour du lancement d’un produit, ou clients étrangers qui ouvrent leurs e-mails le matin en Europe et aux États-Unis et cliquent sur le site. Autrement dit, pas besoin d’auto-scaling 24 h/24 : il suffit d’ajouter des machines avant les événements connus.
Un critère de décision : si, sur les 3 derniers mois, les pics peuvent être marqués sur un calendrier, optez pour le scaling planifié. Si les pics sont totalement aléatoires et dépassent 5 fois le trafic habituel, ajoutez le scaling réactif en filet de sécurité. Dans la réalité d’un site B2B, le premier cas représente 90 % des situations. Le cache statique CDN absorbe 70 % du trafic de pointe, voir Accélération mondiale par CDN.
| Type de pic | Fréquence | Ordre de grandeur | Stratégie recommandée |
|---|---|---|---|
| Trafic salon | Prévisible 2 semaines à l’avance | 3 à 5 fois la normale | Scaling planifié, 2 heures avant |
| Lancement produit | Le jour de la mise en ligne | 2 à 4 fois la normale | Scaling planifié, 1 heure avant |
| Publicité | Selon le plan média | 5 à 10 fois la normale | Scaling planifié + réactif |
| Variations du trafic organique | Pic le matin en semaine | 1,5 à 2 fois la normale | Scaling planifié selon les plages en semaine |
| Média soudain | Totalement aléatoire | Plus de 10 fois la normale | Scaling réactif en filet de sécurité |
2. Scaling réactif : comment régler les seuils pour éviter les oscillations
Le problème le plus courant du scaling réactif, ce sont les oscillations : le CPU dépasse 60 %, on ajoute une machine, le trafic retombe 2 minutes plus tard et on la retire, puis il remonte 3 minutes après, et on ajoute et retire une dizaine de fois par jour. Trois paramètres règlent ce problème : le seuil de déclenchement, la durée et le temps de refroidissement. Les valeurs recommandées pour un site indépendant : ajouter une machine seulement si le CPU dépasse 60 % pendant 3 minutes, refroidissement de 5 minutes à la montée, 15 minutes à la descente.
L’autre point clé, c’est de plafonner le nombre maximal d’instances. Sans limite, l’autoscaling face à un crawler ou à une attaque DDoS fait grimper le nombre d’instances jusqu’à ce que la facture du cloud vous réveille. Fixez un maximum de 5 instances : au-delà, c’est le CDN et le WAF qui encaissent, pas des machines en plus. Pour l’articulation entre supervision, alertes et limitation de débit, voir Surveillance et alertes du site.
| Caractéristique | Valeur recommandée | Rôle | Conséquence d’un mauvais réglage |
|---|---|---|---|
| Seuil de scale-up | CPU>60% pendant 3 minutes | Éviter les faux positifs sur les pics instantanés | Seuil trop bas = oscillations fréquentes |
| Délai de refroidissement au scale-up | 5 minutes | Laisser le temps à la nouvelle machine de démarrer | Trop court = scale-up répétés |
| Seuil de scale-down | CPU<30% pendant 10 minutes | Éviter de réduire dès que le trafic retombe | Trop court = utilisateurs qui subissent des ralentissements |
| Délai de refroidissement au scale-down | 15 minutes | Période d’observation | Trop courte = va-et-vient |
| Nombre minimal d’instances | 1 | Assurer la disponibilité de secours | 0 = démarrage à froid lent |
| Nombre maximal d’instances | 5 (selon le budget) | Éviter une facture incontrôlée | Sans limite = facture qui explose |
III. Scaling planifié : la stratégie la plus rentable pour une boutique indépendante
La veille d’un salon, programmez un cron pour passer de 1 à 3 instances 2 heures avant, puis revenir à 1 instance 2 heures après la fin. Cette approche coûte moins cher que le scaling réactif pour deux raisons : une nouvelle machine met 5 minutes à passer du démarrage à froid à la prise en charge du trafic, et le scaling réactif ne se déclenche qu’après l’alerte CPU, si bien que la moitié du pic est déjà passée quand la machine est prête ; le scaling planifié prépare les machines avant l’arrivée du pic, sans aucune attente pour l’utilisateur.
Un planning applicable : du lundi au vendredi à 8h (heure de Paris, quand les clients européens arrivent au travail), passer à 2 instances, puis revenir à 1 à 17h ; les jours de salon, passer à 3 instances 2 heures avant ; le week-end, rester à 1 instance. Ces règles planifiées couvrent 80% des pics prévisibles d’une boutique indépendante, pour un surcoût mensuel contenu sous 300 yuans. Pour les écarts de plages horaires sur un site multilingue, voir GEO multilingue.
| Plage horaire | Créneau client correspondant | Nombre d’instances | Action |
|---|---|---|---|
| Jours ouvrés 08:00-17:00 (Pékin) | Matinée des clients européens | 2 instances | Scale-up à 8h, scale-down à 17h |
| Jours ouvrés 20:00-24:00 (Pékin) | Matinée de la côte Est américaine | 2 instances | Scale-up à 20h, scale-down à minuit |
| Week-end toute la journée | Trafic faible | 1 instance | Rester au minimum |
| Jour de salon, 2 heures avant | Début de l’afflux du salon | 3 instances | Déclenchement planifié |
| Jour de lancement produit | Toute la journée du lancement | 3 instances | Scale-up 1 heure avant |
IV. Maîtrise des coûts : comment calculer si le scaling fait vraiment économiser
Le modèle de coût de l’autoscaling est simple : facturation à l’heure, une instance VPS 4 cœurs 8 Go coûte environ 0,5 yuan par heure. Passer à 3 instances le jour et revenir à 1 la nuit coûte environ 4 yuan de plus par jour, soit 120 yuan de plus par mois. Sans scaling, il faudrait garder 3 instances en permanence pour absorber les pics, soit 600 yuan de plus par mois. Le scaling permet donc d’économiser ces 480 yuan.
Mais il y a un piège de coût contre-intuitif : une nouvelle machine met du temps à démarrer, et si l’image se télécharge lentement ou si les dépendances s’initialisent longuement, les 10 premières minutes de l’instance tournent à vide. Réduire la taille de l’image (voir Optimisation des images Docker) et lancer les scripts de préchauffage à l’avance permet de ramener le démarrage à froid d’une instance de 10 à 2 minutes : ces minutes gagnées sont aussi de l’argent économisé.
| Approche | Coût mensuel des instances | Bande passante/CDN | Coût mensuel total | Cas d’usage |
|---|---|---|---|---|
| 3 instances en permanence, sans scaling | Environ 1800 yuan | 200 yuan | 2000 yuan | Trafic stable et élevé |
| 1 instance permanente + montée en charge programmée | environ 700 ¥ | 200 yuan | 900 ¥ | Pics réguliers |
| 1 instance permanente + montée en charge réactive | environ 600 ¥ | 200 yuan | 800 ¥ | Pics aléatoires |
| Combinaison programmée + réactive | environ 750 ¥ | 200 yuan | 950 ¥ | Recommandé pour les sites indépendants |
5. Supervision : sans elle, vous ne savez pas que la mise à l’échelle fonctionne
Une fois la mise à l’échelle automatique en place, un tableau de bord de supervision est indispensable. Sinon, vous ignorez quand elle se déclenche, pourquoi, et si vous dépassez le budget. Quatre indicateurs clés : nombre d’instances actives, nombre d’événements de montée en charge, taux d’utilisation CPU moyen, taux d’erreur par instance. Consultez le journal des événements une fois par jour et la courbe de coûts une fois par semaine.
Un critère de décision : si la montée en charge réactive se déclenche plus de 5 fois en une semaine, vos règles programmées ne couvrent pas le trafic réel. Ajoutez ces événements au planning. Si elle ne se déclenche jamais, assouplissez les seuils ou désactivez-la pour ne plus être réveillé par des alertes la nuit. La liste complète des alertes de supervision se trouve dans Surveillance et alertes du site.
| Indicateur surveillé | Plage normale | Signal anormal | Action |
|---|---|---|---|
| Nombre d’instances actives | 1 à 3 | Bloqué au maximum de 5 en permanence | Vérifier si le site est victime de scraping |
| Événements de montée en charge/semaine | 2 à 5 | >10 ou 0 | Ajuster le planning ou les seuils |
| Taux d’utilisation CPU moyen | 30 % à 50 % | >70 % en continu | Augmenter le nombre minimum d’instances |
| Taux d’erreur par instance | <0,5 % | >2% | Vérifier l’état des nouvelles instances |
| Coût mensuel des instances | ±20 % dans le budget | 30 % au-dessus du budget | Vérifier le nombre maximum d’instances |
FAQ — Questions fréquentes
Un site indépendant a-t-il vraiment besoin de la mise à l’échelle automatique ?
Quel seuil CPU choisir ?
Nombre minimum d’instances : 1 ou 2 ?
Comment éviter que les robots d’exploration fassent exploser le nombre d’instances ?
Combien de temps prend le démarrage d’une nouvelle machine, et comment l’accélérer ?
Peut-on utiliser en même temps la mise à l’échelle planifiée et la mise à l’échelle réactive ?
Pour conclure
En matière d’autoscaling, plus d’automatisme ne veut pas dire mieux. Pour une boutique indépendante dont la courbe de trafic est prévisible, anticiper de 2 heures les pics déjà notés au calendrier coûte moins cher et est plus fiable que n’importe quel algorithme intelligent. La mise à l’échelle réactive n’est qu’un filet de sécurité, pour faire face aux pics totalement imprévus.
Trois étapes pour passer à l’action : premièrement, analyser la courbe de trafic des 3 derniers mois et identifier tous les pics connus ; deuxièmement, transformer ces pics en tâches planifiées, en augmentant 2 heures avant et en réduisant 2 heures après ; troisièmement, ajouter une règle réactive comme filet de sécurité, déclenchée quand le CPU dépasse 60 % pendant 3 minutes, avec un plafond de 5 machines. Une fois ces trois étapes franchies, le coût mensuel est deux fois moins élevé qu’avec 3 machines permanentes, et les utilisateurs ne remarquent rien pendant les pics. Pour le monitoring associé, voir Surveillance et alertes du site.
Une phrase à retenir : les pics d’une boutique indépendante ne sont pas une surprise, c’est un calendrier — les inscrire dans des tâches planifiées coûte dix fois moins cher que d’attendre l’alerte CPU pour intervenir.