swiss.blackfriday : gérer un pic de charge massif grâce à Hidora Cloud

Le Black Friday est devenu un événement commercial incontournable en Suisse. Et pour les plateformes qui agrègent les offres et redirigent les acheteurs vers les marchands, c'est le jour le plus critique de l'année. Une seconde de latence en trop, une page qui ne charge pas, et ce sont des milliers de francs de revenus perdus.

swiss.blackfriday est la plateforme de référence en Suisse pour les offres du Black Friday. Pendant 364 jours par an, le trafic est modéré. Mais le jour J et la semaine qui le précède, le site doit encaisser des pics de charge qui multiplient le trafic normal par 50 à 100. C'est un défi d'infrastructure que peu de plateformes cloud traditionnelles peuvent relever sans préparation spécifique.

Voici comment Hidora Cloud a permis à swiss.blackfriday de traverser cette période sans incident.

Le contexte : un site à deux vitesses

swiss.blackfriday présente un profil de trafic unique. Pendant la majeure partie de l'année, le site reçoit entre 2 000 et 5 000 visiteurs par jour. Le contenu est essentiellement statique, avec quelques pages dynamiques pour les inscriptions à la newsletter et les alertes de prix.

Mais à partir de la troisième semaine de novembre, tout change. Les visiteurs commencent à affluer pour découvrir les offres en avant-première. Le trafic monte progressivement jusqu'au pic du Black Friday lui-même, où le site peut recevoir plus de 200 000 visiteurs en une seule journée, avec des pointes de plusieurs milliers de requêtes par seconde.

Ce pattern de trafic pose un problème fondamental : dimensionner l'infrastructure pour le pic signifie payer toute l'année pour des ressources utilisées seulement quelques jours. Mais sous-dimensionner signifie un site planté le jour où il doit absolument fonctionner.

Les échecs passés

Avant Hidora, swiss.blackfriday avait connu plusieurs Black Fridays difficiles. En 2022, le site avait été hébergé chez un prestataire classique avec des serveurs dédiés. L'équipe avait anticipé en louant des serveurs supplémentaires pour la période, mais le scaling avait été mal calibré. Résultat : le site est tombé pendant 45 minutes en milieu de matinée, pile au moment du pic de trafic. Les pertes estimées : plus de 15 000 CHF en commissions d'affiliation non générées.

L'année suivante, l'équipe avait tenté de résoudre le problème avec un CDN mondial. Cela avait amélioré les choses pour le contenu statique, mais les pages dynamiques (recherche d'offres, filtres par catégorie, comparaison de prix) continuaient de surcharger le serveur d'origine. Le site n'est pas tombé, mais les temps de réponse dépassaient les 8 secondes aux heures de pointe, une éternité pour des utilisateurs impatients de trouver la bonne affaire.

La préparation avec Hidora

Quand swiss.blackfriday a contacté Hidora en septembre, l'objectif était clair : zéro downtime et des temps de réponse inférieurs à 2 secondes, même au pic de charge maximal.

L'équipe Hidora a mis en place une stratégie en trois volets.

1. Architecture optimisée pour les pics

L'infrastructure a été conçue spécifiquement pour le pattern de trafic de swiss.blackfriday :

• Serveurs applicatifs avec auto-scaling horizontal. Le nombre d'instances s'adapte automatiquement à la charge. En temps normal, deux instances suffisent. Pendant le Black Friday, la plateforme peut automatiquement monter jusqu'à douze instances en quelques minutes, sans intervention manuelle.

• Base de données avec read replicas. La base de données principale gère les écritures (ajout d'offres, inscriptions), tandis que plusieurs read replicas distribuent les requêtes de lecture. C'est essentiel car 95% du trafic du Black Friday est en lecture seule.

• Cache multi-niveaux. Un cache Redis gère les sessions utilisateur et les résultats de recherche fréquents. Un cache Varnish en amont absorbe les requêtes répétitives sur les pages d'offres les plus populaires. Combinés, ces deux niveaux de cache permettent de servir 80% des requêtes sans toucher la base de données.

• CDN pour les assets statiques. Images, CSS, JavaScript : tout le contenu statique est servi depuis des points de présence proches des utilisateurs, libérant la bande passante des serveurs applicatifs.

2. Tests de charge préalables

Trois semaines avant le Black Friday, l'équipe Hidora a exécuté une série de tests de charge simulant les conditions réelles du jour J :

• Test progressif : montée en charge de 0 à 5 000 utilisateurs simultanés sur 30 minutes pour vérifier le comportement de l'auto-scaling.
• Test de pic : injection brutale de 3 000 utilisateurs simultanés pour valider la réactivité du système face à un spike soudain.
• Test d'endurance : maintien de 2 000 utilisateurs simultanés pendant 4 heures pour identifier d'éventuelles fuites de mémoire ou dégradations progressives.

Les tests ont révélé un goulot d'étranglement dans la gestion des sessions PHP, qui a été corrigé avant le jour J. Sans ces tests, ce problème serait apparu en production au pire moment.

3. Plan de monitoring et d'intervention

Un tableau de bord dédié a été configuré pour le Black Friday, affichant en temps réel :

• Le nombre de requêtes par seconde
• Les temps de réponse par page (P50, P95, P99)
• L'utilisation CPU et mémoire de chaque instance
• Le hit rate du cache
• Le nombre d'instances actives et les événements d'auto-scaling

Un ingénieur Hidora était en astreinte dédiée pendant toute la période du Black Friday, avec des seuils d'alerte configurés pour intervenir proactivement avant qu'un problème ne devienne visible pour les utilisateurs.

Le jour J : résultats

Le Black Friday 2024 s'est déroulé sans le moindre incident technique.

Trafic absorbé : 247 000 visiteurs uniques sur la journée, avec un pic de 4 200 requêtes par seconde à 10h32.

Temps de réponse : Le P95 est resté sous les 800 millisecondes toute la journée, même au pic de charge. Les pages d'offres les plus consultées se chargeaient en moins de 400 millisecondes grâce au cache.

Auto-scaling en action : L'infrastructure est passée de 2 à 9 instances applicatives entre 8h et 10h, puis est redescendue progressivement à 4 instances en fin d'après-midi. Le tout de manière entièrement automatique.

Disponibilité : 100%. Zéro seconde de downtime. Zéro erreur 5xx visible par les utilisateurs.

Coût de l'opération : Le surcoût lié au scaling du Black Friday a représenté environ 400 CHF sur la semaine, une fraction de ce que coûtait l'ancien setup avec des serveurs dédiés réservés pour la période.

Le retour à la normale

Un des aspects les plus appréciés par l'équipe de swiss.blackfriday est le retour automatique à la configuration de base. Dès le lendemain du Black Friday, le trafic a chuté de 80%. L'infrastructure s'est automatiquement adaptée en réduisant le nombre d'instances. Pas besoin de résilier des serveurs, de modifier des configurations, ou de contacter un support technique. La facture du mois de décembre est revenue à son niveau habituel.

Ce modèle de facturation à l'usage est fondamentalement différent de l'hébergement classique. swiss.blackfriday ne paie les ressources supplémentaires que quand elles sont réellement utilisées (quelques jours par an) au lieu de payer un forfait annuel dimensionné pour le pic.

Les enseignements

L'expérience de swiss.blackfriday illustre plusieurs principes fondamentaux de la gestion des pics de charge :

Tester avant, pas pendant. Les tests de charge préalables ont permis d'identifier et de corriger un problème qui aurait causé une panne en production. Investir quelques heures de test, c'est éviter des heures de crise le jour J.

L'auto-scaling n'est pas magique. Il doit être configuré correctement, avec les bons seuils et les bonnes métriques de déclenchement. Un auto-scaling mal configuré peut être pire que pas d'auto-scaling du tout, par exemple en lançant trop d'instances trop tard, ou en déclenchant des oscillations.

Le cache est roi. Pour un site à forte lecture comme swiss.blackfriday, une stratégie de cache bien pensée fait plus de différence que l'ajout de serveurs. Servir 80% des requêtes depuis le cache, c'est diviser la charge effective du serveur par 5.

Le monitoring proactif sauve des revenus. Avoir un ingénieur dédié qui surveille les métriques en temps réel permet d'intervenir avant que les utilisateurs ne voient un problème. La différence entre "on a évité un incident" et "on a géré une crise" se mesure en milliers de francs.

Pour toute entreprise confrontée à des pics de charge saisonniers ou événementiels, le message est clair : une infrastructure cloud bien configurée avec de l'auto-scaling intelligent n'est pas un luxe, c'est une nécessité économique. Payer toute l'année pour des ressources inutilisées, c'est du gaspillage. Planter le jour du pic, c'est pire.