Renforcez la sécurité de votre application Symfony pour le Black Friday

Ce blog est basé sur la présentation de Thomás Di Luccio intitulée « Bulletproofing for Black Friday » (Se prémunir contre le Black Friday) lors de la conférence Symfony 2024. Thomás est ingénieur en relations avec les développeurs chez Upsun. Nous avons utilisé des outils d'IA pour la transcription et pour améliorer la structure et la clarté du contenu.

Imaginez : vous êtes une petite start-up de billetterie qui vient de décrocher un contrat important avec une grande salle. Après des mois passés à développer des fonctionnalités et à préparer le lancement, le grand jour arrive : la vente des abonnements saisonniers est lancée. Cette salle pourrait générer jusqu'à la moitié de son chiffre d'affaires annuel en une seule journée. Les enjeux sont donc considérables.

À 10 heures, la vente des billets commence. Les clients en ligne, les visiteurs sur place et les utilisateurs de l'application mobile accèdent tous simultanément à la même API. Pendant 45 minutes, tout semble fonctionner normalement. Puis, progressivement, l'application commence à ralentir. Au bout d'une heure, tout plante complètement.

C'est exactement ce qui est arrivé à Thomás et à son équipe il y a quelques années. Ce fut un échec cuisant qui a affecté non seulement ce client important, mais aussi tous leurs autres clients. L'ambiance au bureau était désastreuse, et personne ne savait ce qui n'avait pas fonctionné ni comment rectifier la situation.

Cependant, cet échec a marqué le début d'un parcours vers la performance et la scalabilité des applications, un parcours que vous n'aurez pas à refaire.

Le problème fondamental : développer des fonctionnalités ou développer pour la scalabilité

Le problème fondamental ne venait pas de Symfony ni d'une technologie particulière. Le problème était simple : l'équipe était tellement concentrée sur la livraison de fonctionnalités qu'elle a complètement négligé de se préparer à des scénarios de trafic intense.

« Nous étions tellement concentrés sur la création du produit, la livraison des fonctionnalités, l'assemblage des fonctionnalités, que nous avons oublié quelque chose d'essentiel : nous préparer pour le grand jour », explique Thomás.

Il s'agit d'un piège courant dans le commerce électronique et dans toute entreprise connaissant des périodes de trafic intense. Les équipes développent d'excellentes fonctionnalités, mais négligent souvent le fait que le succès signifie plus d'utilisateurs, et que plus d'utilisateurs peuvent submerger des systèmes non préparés.

Quatre stratégies essentielles pour des applications à toute épreuve

1. Soumettez votre application à des tests de résistance sans relâche

La première leçon est évidente, mais souvent négligée : testez la résistance de vos applications avant le jour J. Il ne s'agit pas seulement d'effectuer quelques tests de charge, mais de casser systématiquement votre application.

Cassez votre application intentionnellement.

Ne vous contentez pas de tester votre application, mettez-la en échec. Faites preuve de créativité. Trouvez de nouvelles façons de la pousser à l'échec. Comme le dit Thomás, « Ne laissez pas cela entre les mains de vos utilisateurs, car ce sont des fous et ils la mettront en échec d'une manière que vous ne pourrez pas contrôler. »

Investissez dans des outils de test de charge.

Choisissez des outils qui conviennent à votre équipe et utilisez-les systématiquement. Voici quelques options populaires :

• Locust (basé sur Python, très flexible)
• Gatling (basé sur Java, axé sur les entreprises)
• Diverses solutions SaaS pour ceux qui préfèrent les services gérés

La clé est de trouver le bon équilibre entre le temps investi et l'argent dépensé pour créer une configuration que tous les membres de votre équipe peuvent utiliser de manière fiable.

Créez des parcours utilisateur réels.

Les tests de charge génériques ne suffisent pas. Vous devez simuler le comportement réel des utilisateurs :

• Étudiez vos analyses pour comprendre les comportements réels des utilisateurs.
• Cartographiez les parcours complets des utilisateurs, de la page d'accueil à la caisse.
• Utilisez vos API pour récupérer des données réelles (identifiants de produits, catégories, mots-clés de recherche).
• Créez des fonctions de test modulaires qui peuvent être combinées comme des blocs Lego.

N'oubliez pas les cas limites.

Dans le cas de la société de billetterie, son ennemi juré était constitué de groupes de personnes âgées passionnées de théâtre qui envoyaient une seule personne acheter des dizaines de billets pour l'ensemble du groupe. Ces scénarios de paniers volumineux généraient des charges de calcul considérables qui n'étaient pas prises en compte dans les tests normaux.

Testez toujours les scénarios extrêmes :

• Paniers d'achat volumineux contenant plus de 50 articles.
• Configurations utilisateur complexes.
• Processus de calcul lourds.

Simplifiez la procédure en un seul clic.

Tous les membres de votre équipe doivent pouvoir exécuter des tests de charge complets à l'aide d'une seule commande ou d'un simple clic. Cela supprime les obstacles aux tests réguliers et garantit que les tests sont réellement exécutés.

Trouvez vos points de rupture.

Les tests de charge révèlent deux chiffres essentiels :

• Le point où votre application commence à ralentir
• Le point où elle plante complètement

Il est essentiel de comprendre ces seuils, car il existe souvent une corrélation directe entre le nombre d'utilisateurs simultanés et les revenus. Connaître votre point de rupture signifie connaître le revenu maximal que votre infrastructure actuelle peut générer.

2. Travaillez toujours sur des copies de production

Ne jamais effectuer de test de résistance en production. Cela semble évident, mais le défi consiste à créer des copies vraiment fidèles de votre environnement de production.

L'approche d'Upsun

Upsun, où travaille Thomás, fournit une plateforme en tant que service basée sur Git qui rend cela possible. Vous décrivez vos besoins en matière d'infrastructure dans des fichiers YAML enregistrés dans votre référentiel :

• Applications Symfony avec PHP 8.3 ou 8.4
• Applications frontales dans Node.js
• Pipelines de science des données
• Go workers
• Toute combinaison de services dont votre application a besoin

Chaque commit crée une nouvelle version, et chaque branche crée une copie complète de l'environnement parent, quelle que soit sa complexité.

Solutions DIY

Si Upsun n'est pas une option, investissez dans la création de capacités similaires :

• Clonage d'environnement en une seule commande.
• Provisionnement automatisé de l'infrastructure.
• Configurations identiques dans tous les environnements.

Pour les applications de commerce électronique, cette fonctionnalité est essentielle.

3. Intégrez l'observabilité dans tout

Il ne suffit pas de disposer d'environnements de test de charge et de mise en scène si vous ne pouvez pas comprendre ce qui se passe à l'intérieur de votre application pendant les tests de résistance.

Qu'est-ce que l'observabilité ?

L'observabilité est « la capacité à observer le comportement d'une application, à détecter les goulots d'étranglement et à améliorer les performances ». Considérez-la comme des lunettes bioniques pour votre application, un moyen de voir à travers les boîtes noires et de prendre des décisions éclairées.

Principales fonctionnalités d'observabilité

Les outils d'observabilité modernes tels que Blackfire offrent plusieurs fonctionnalités essentielles :

• Surveillance : suivez le trafic CLI et HTTP sur l'ensemble de votre stack d'applications.
• Profilage continu : collecte de données légère avec une surcharge minimale (impact sur les performances de 0,05 à 0,1 %) qui fonctionne dans plusieurs langages : PHP, Python, Node.js, Go, Ruby, Rust et Java.
• Comparaison des périodes : comparez les périodes calmes avec les tests de charge ou le trafic réel du Black Friday pour évaluer les performances. Cette comparaison visuelle montre quelles parties de votre application consomment proportionnellement plus de ressources sous charge, ce qui permet d'identifier les goulots d'étranglement.
• Profilage déterministe : profilage approfondi et précis pour des requêtes spécifiques qui montre exactement comment votre code s'exécute, y compris les boucles, les appels de fonction et la consommation de ressources dans toutes les dimensions.
• Tests de performances : tests de performances automatisés qui peuvent empêcher les régressions de performances d'être intégrées dans la production.
• Surveillance de l'infrastructure : suivez le trafic HTTP et la consommation de ressources pour tous les services et conteneurs afin de garantir une mise à l'échelle appropriée.
• Prendre des décisions éclairées
• L'objectif est d'améliorer l'expérience utilisateur, d'identifier rapidement les domaines à améliorer et de garantir une mise à l'échelle efficace de votre application. Que vous utilisiez Blackfire ou d'autres solutions, investissez dans des outils qui fournissent des informations similaires.

4. Évoluez de manière intelligente et granulaire

La dernière étape consiste à comprendre comment évoluer efficacement. Cela implique de répondre à une question complexe : « Quelle partie de votre application a besoin de quelles ressources pour obtenir quels résultats ? »

Commencez par vos objectifs

Définissez vos scénarios d'évolutivité :

• Périodes calmes (trafic de base).
• Périodes de pointe (Black Friday, lancements de produits).
• Scénarios intermédiaires.

Effectuez des tests pour chaque scénario jusqu'à ce que vous compreniez les exigences exactes.

Identifiez les exigences précises

Utilisez vos outils de test et d'observabilité pour déterminer :

• Les besoins en ressources par conteneur
• Si vous avez besoin d'un équilibrage de charge (la réponse n'est pas toujours oui)
• Le nombre optimal d'instances pour différents niveaux de trafic

Prenez des décisions basées sur les coûts et les performances en utilisant des données réelles, et non des hypothèses.

N'oubliez pas les travailleurs

Adaptez vos travailleurs en arrière-plan à vos applications web. Assurez-vous qu'ils disposent de ressources suffisantes dans des conteneurs correctement configurés.

Allocation fine des ressources

Upsun permet une allocation granulaire des ressources ; vous pouvez ajouter plus de mémoire à un conteneur tout en réduisant le CPU dans un autre où il est gaspillé. Vous pouvez également adapter le nombre d'instances grâce à l'équilibrage automatique de la charge.

Évitez les solutions à échelle fixe

De nombreuses applications fonctionnent à leur capacité maximale toute l'année, car leurs hébergeurs rendent difficile l'augmentation ou la réduction de leur capacité. Cela entraîne un gaspillage d'argent et une empreinte carbone inutile. Trouvez des solutions qui permettent une adaptation dynamique en fonction de la demande réelle.

Le cadre d'application à toute épreuve

En combinant ces quatre stratégies, vous créez un cadre à toute épreuve :

1. Tests de résistance : cassez votre application de manière systématique dans des environnements contrôlés
2. Clonage de production : testez des copies parfaites de votre configuration de production
3. Observabilité à 360° : comprenez ce qui se passe à l'intérieur de votre application pendant les tests de résistance
4. Mise à l'échelle fine : adaptez précisément votre application en fonction des données réelles et des exigences

L'impact dans le monde réel

Vous vous souvenez de la panne initiale ? Le goulot d'étranglement s'est avéré être les paniers d'achat volumineux que l'équipe n'avait pas anticipés. Des groupes de passionnés de théâtre achetaient 50 à 100 billets en une seule commande, ce qui créait une charge de calcul énorme pour l'attribution des places, le calcul des prix et la génération des billets.

Mais le problème technique n'était qu'un symptôme. Le véritable problème était l'isolement de l'équipe par rapport aux utilisateurs réels. Elle développait des fonctionnalités sur la base d'hypothèses plutôt que de comprendre comment les salles vendaient réellement leurs billets.

« Nous étions totalement isolés dans le département d'ingénierie, nous nous contentions de livrer des fonctionnalités à partir d'un backlog. Nous n'étions pas avec les gens sur place pour voir comment ils travaillaient réellement, comment ils vendaient réellement les billets », se souvient Thomás.

L'objectif est la transformation : passer d'un état de panique lors des événements à fort trafic à un état de détente et de confiance. Lorsque vous disposez de tests de résistance, de clonage de production, d'observabilité et de mise à l'échelle appropriés, vous pouvez aborder le Black Friday en sachant que vous maîtrisez parfaitement la situation.

Au lieu de courir partout pour essayer de réparer les choses, vous pouvez réellement profiter d'un verre tout en surveillant des systèmes dont vous savez qu'ils géreront tout trafic, quel qu'il soit.

Une brève séance de questions-réponses avec le public

Q : Quel niveau de surveillance est suffisant ?
R : Maintenez le profilage continu. Pour la surveillance des requêtes, un taux d'échantillonnage de 10 % est un bon point de départ pour de nombreuses applications. Les applications à très fort trafic peuvent atteindre un trafic plus faible tout en conservant une fiabilité statistique. Les premiers gains obtenus grâce à l'utilisation de ces outils compensent souvent leur coût.

Q : Quelle est la cause de la panne initiale ?
R : Des paniers énormes, une allocation de sièges et une logique de billetterie lourdes, combinées à des choix axés sur les fonctionnalités d'expédition plutôt que sur le comportement réel des utilisateurs le jour du lancement. Même les imprimantes ont reçu des images surdimensionnées. Les tests faisaient défaut. La correction a commencé par l'observation des processus réels et le renforcement du système.

Q : Comment éviter une fausse confiance dans les tests de performance ?
R : Écrivez des tests de performance en parallèle des tests unitaires et d'intégration. Commencez par les parcours utilisateurs les plus critiques : testez les causes, pas seulement les résultats. Par exemple, affirmez « moins de N requêtes SQL » au lieu de simplement « moins de 10 ms », afin de ne pas passer à cause de caches chauds tout en masquant les coûts réels.

Q : Qu'en est-il des services tiers pendant les tests de résistance ?
R : Dirigez les environnements de test vers des comptes sandbox via des variables d'environnement. N'utilisez les identifiants de production qu'en production. De cette façon, vous pouvez tester en toute sécurité sans épuiser vos quotas réels.

Conclusion

N'attendez pas que le désastre vous frappe. Commencez dès maintenant à effectuer des tests de résistance, investissez dans des outils adaptés et construisez des systèmes capables de gérer le succès. Votre futur vous-même et vos utilisateurs vous remercieront lorsque le prochain Black Friday arrivera et que tout fonctionnera parfaitement.

La différence entre un événement à fort trafic réussi et un échec catastrophique réside souvent dans la préparation. Faites de cette préparation une priorité, et non une réflexion après coup.