Tech • IA • Robotique • Jeu
Qu’est-ce que l’architecture des systèmes ?
3/10INTRO
Un système simple de commande en ligne fonctionnait bien au départ, mais un trafic promotionnel plus important a révélé les limites de CPU du serveur applicatif, poussant l’équipe à revoir l’architecture pour améliorer la scalabilité, la résilience, la reprise et le contrôle d’accès.
POINTS CLÉS
Architecture initiale
La première mise en place de la boutique en ligne reposait sur une conception simple en trois parties: un site web côté client, une application sur un serveur et une base de données sur un autre. Les clients pouvaient parcourir les produits, choisir des quantités et envoyer leurs commandes, tandis que le personnel pouvait consulter les commandes entrantes et les préparer.
Flux principal de commande
Lorsqu’une commande était envoyée, l’application validait la requête, enregistrait la commande dans la base de données, puis renvoyait une confirmation. Les premiers tests ont montré que les produits se chargeaient correctement, que les commandes étaient bien sauvegardées et que le personnel pouvait accéder aux enregistrements nécessaires.
Une hausse de trafic a révélé un goulot d’étranglement
Le système a bien fonctionné pendant plusieurs semaines, jusqu’à ce qu’une promotion attire davantage de visiteurs simultanés. Les pages produit sont devenues plus lentes, et certains clients ont reçu des erreurs au moment de passer commande, alors même que les fonctionnalités de l’application n’avaient pas changé.
Le diagnostic a pointé la couche applicative
L’analyse a montré que la base de données suivait encore la charge, tandis que le CPU du serveur applicatif tournait presque à pleine utilisation. Reproduire le problème avec un test de trafic similaire a donné à l’équipe une cible claire d’amélioration.
Montée en charge avec un load balancer
Au lieu de s’appuyer sur un seul serveur plus puissant, l’équipe a ajouté un deuxième serveur applicatif et placé un load balancer devant les deux instances. Les clients pouvaient ainsi continuer à utiliser une seule adresse, tandis que les requêtes entrantes étaient réparties entre les deux copies de l’application.
La gestion de l’état est devenue un enjeu de conception
L’ajout d’un deuxième serveur a obligé à vérifier que n’importe lequel pouvait traiter n’importe quelle requête. Si des informations nécessaires à la requête suivante n’existaient que sur un seul serveur, envoyer le client vers l’autre pouvait casser le processus; l’application a donc dû être adaptée pour éviter toute dépendance propre à un serveur.
Les performances se sont améliorées, mais la complexité a augmenté
Après la refonte, des tests de trafic répétés ont montré des réponses plus rapides et moins de requêtes en échec pour la même charge. Ces gains se sont accompagnés de coûts et d’efforts d’exploitation supplémentaires: un serveur de plus à financer, un load balancer à configurer et davantage d’infrastructure à superviser.
La panne d’un seul serveur ne signifiait plus une indisponibilité totale
Lorsqu’un serveur applicatif est ensuite tombé en panne, les vérifications d’état du load balancer ont détecté le problème et ont cessé de lui envoyer de nouvelles requêtes. Le serveur restant a continué à traiter le trafic, même si les requêtes déjà en cours sur le serveur défaillant pouvaient encore être perdues et si le serveur survivant devait disposer d’une capacité libre suffisante.
La base de données restait une dépendance critique
Même avec plusieurs serveurs applicatifs, la base de données restait un point unique dont dépendait l’enregistrement des commandes. Si elle devenait indisponible, aucun des serveurs applicatifs ne pouvait sauvegarder de nouvelles commandes, ce qui a déplacé l’attention de la montée en charge vers la planification de la reprise.
Les objectifs de reprise ont guidé la stratégie de base de données
L’équipe a discuté avec le propriétaire de deux questions métier: combien de temps la prise de commande pouvait être interrompue et quelle quantité de données récemment enregistrées pouvait être perdue. Les réponses ont déterminé si des sauvegardes seules suffisaient ou si une standby database était nécessaire pour un basculement plus rapide, avec des compromis différents en coût, complexité et garanties sur les données.
La sécurité exigeait plus qu’une interface fonctionnelle
Le contrôle d’accès est apparu comme un autre enjeu central de conception. Les clients ne devaient pouvoir voir que leurs propres commandes, tandis que le personnel ne devait accéder qu’aux commandes utiles à son travail, et ces vérifications devaient être appliquées par l’application elle-même plutôt que par le simple masquage de boutons sur le site.
La conception du système reliait toutes les décisions
Ces changements illustrent la conception de système comme le processus qui consiste à décider quels composants sont nécessaires, ce que chacun fait, comment ils communiquent, où vivent les données, comment le système gère la demande, comment il se rétablit après une panne et comment les accès sont contrôlés. La leçon ne portait pas seulement sur la façon de corriger un ralentissement, mais aussi sur l’alignement des choix techniques avec les besoins métier avant que les problèmes n’apparaissent en production.
CONCLUSION
La plateforme de commande de la boutique est passée d’une première version simple et fonctionnelle à un système façonné par les limites de performance, les scénarios de panne et les exigences de sécurité. Le défi central consistait à équilibrer fiabilité et montée en charge avec le coût et la complexité supplémentaires nécessaires pour soutenir l’activité lors des pics de demande.
Poser une question