Adopter les flux tirés dans la conception logicielle

Nous abordons un des points essentiels de l’architecture réseau et applicative efficace et économe : les flux tirés.

Commencons par une définition. Les flux tirés correspondent à une démarche de gestion des flux de production qui consiste à fournir les matériaux lorsque la production les demande et à n’avancer dans les différentes étapes de la production que lorsque l’etape suivante est en capacité d’absorber le travail.

Sur une chaine de production automobile par exemple, cette conception s’oppose totalement au Fordisme qui a pour objectif d’améliorer la productivité de la chaîne et a pour conséquence un fort stockage ainsi qu’une forte pression sur les unités de production. Une chaîne produit en continu et les produits finis sont stockés… en espérant qu’il y ait de la place pour stocker et que la demande soit en permanence au moins aussi forte que la production.

Lorsque la demande est forte ce système permet de réduire les coûts, de baisser le prix du produit et d’augmenter les marges. C’est donc un cercle vertueux qui enrichit tout le monde… en théorie.

Cependant plusieurs problèmes d’importance majeure se posent :

  1. le stock coûte très cher
  2. si la demande faiblit ou s’effondre, il faut arrêter de produire et vendre le stock, en d’autres terme la flexibilité est faible
  3. si le produit ne se vend plus il faut vendre le stock à perte ou le liquider.

A la fin, les marges s’effondrent lamentablement.

Si l’on applique ce principe à la conception logicielle cela pourrait donner le cas suivant : vous vendez des logiciels sur votre site Internet. Pour ce faire, vous avez un unique serveur pour gérer le site Internet, les ventes par carte bancaire et la génération des numéros de licence pour vos clients après que le paiement a été vérifié.

Vous testez votre site avec un volume de 1 000 ventes en une journée (8h-20h), soit 83 ventes par heure, soit près de 3 ventes toutes les 2 minutes.

Le processus de gestion des paiements et de génération des licences, avec envoi d’emails et mises à jour de la base de données dure 30 secondes.

Ainsi, avec votre serveur web, vous êtes capable de traiter une vente toutes les 30 secondes.

A présent regardons le processus de gestion de la vente :

Ce processus est tout à fait linéaire, il commence sur un serveur et se termine sur le même serveur.

Si deux commandes doivent être traitées, elles le seront successivement. Pour traiter plusieurs commandes en même temps il faudra paralléliser. Qui dit parallélisation dit perte de la maîtrise de l’utilisation des ressources : combien allez-vous parralléliser de processus ? Quelle sera votre capacité maximale de traitement sur ce serveur ?

En réalité en parallélisant vous ne faites que repousser le problème : si vous arrivez à augmenter votre capacité de traitement à 3 000 commandes par jour, qu’arrivera-t-il lorsque vous aurez 4 000 commandes par jour ? Et si vous avez un pic à 10 000 commande sur une journée alors que votre système est conçu pour gérer 1 000 commandes par jour ?

Cette conception montre ses faiblesses particulièrement dans ca capacité à monter en charge, mais aussi dans son aspect économique : devez-vous dépenser plus chaque jour pour une surcapacité de traitement, ce qui aura pour conséquence d’éviter la rupture de production mais aussi de réduire vos marges. Jusqu’à quelle échelle pouvez-vous faire cela ?

Nous proposerons deux autres modèles de conception non exclusifs, mais un seul fait l’objet de cet article :

1 – adopter une architecture réseau distribuée

2 – adopter une architecture logicielle utilisant les flux tirés

 

Architecture réseau distribuée

Nous aborderons ce sujet en surface car il ne fait pas l’objet de cet article, nous pourrons le présenter plus en détail dans un autre article.

L’idée maîtresse est de considérer que si la capacité de production d’un seul serveur est insuffisante, il suffit de multiplier le nombre de serveurs pour augmenter cette capacité. Certes cela règlera le problème puisqu’il suffira d’ajouter des serveurs pour suivre les besoins de la production. Cependant, ajouter un serveur a un coût puisqu’il faut “construire” un serveur, cela prend du temps, coûte de l’argent et nécessite des ressources.

Il est bien entendu possible, pour obtenir la plus grande souplesse, de faire appel à des services de cloud comme Amazon EC2, mais le coût d’une telle plateforme est énorme, vos marges vont en souffrir.

De plus, les compétences nécessaires sont celles d’un architecte réseau. Disposez-vous de cette compétence dans une équipe de développeurs ?

Bref cette solution est intéressante car elle résoud le problème et offre une souplesse très importante mais elle est coûteuse, complexe et nécessite des compétences spécifiques.

 

Architecture logicielle utilisant les flux tirés

Une solution plus simple à mettre en oeuvre et moins coûteuse consiste à inverser les flux.

Au lieu de déclencher un long processus qui commence à la validation de la commande et qui finit par un envoi d’email, le processus sera divisé en 3 parties :

Le premier processus commence lorsque l’utilisateur valide la commande et se termine par la mise à jour du statut de la commande dans la base

Le deuxième processus commence lorsque la banque envoie la notification de validation du paiement par CB et se termine par la mise à jour du statut de la commande dans la base.

Le troisième processus est une boucle infinie qui scrute l’état des commande dont le paiement a été validé. Il s’achève avec la mise à jour du statut de la commande dans la base.

Avantages :

  • Le serveur web ne traite que le premier processus, qui dure quelques instants. Il peut donc supporter une forte montée en charge et dépasser de très loin la limite de traitement de commandes précédemment atteinte. Ce serveur peut très facilement être dupliqué et intégré dans une architecture distribuée et cloudée type EC2. Ce type de serveur ne coûte presque rien.
  • Les deux autres processus peuvent être exécutés sur autant de serveurs que vous le souhaitez, ils sont totalement indépendant les uns des autres. Vous pouvez commencer avec 1 serveur pour les deux, puis évoluer vers 1 serveur pour traiter les paiements et 10 serveurs pour réaliser les commandes.
  • Vous avez une souplesse optimale car la montée en charge peut être absorbée très facilement, sans coût excessif par la multiplication des unités de production.

Les plus attentifs d’entre vous auront remarqué que nous n’avons pas totalement tiré les flux puisque nous continuons à accepter toutes les commandes alors que nous aurions pu réduire notre capacité commerciale pour l’adapter à notre capacité de production… ce qui est contre-intuitif économiquement.

En réalité, nous avons stocké les commandes reçues. Mais ce stock ne coûte rien. En revanche nous avons adapté notre rendement à notre capacité physique de production. Ce rendement augmentera dès lors que nous aurons augmenté nos capacités de production, et ce avec un coût maîtrisé et réduit au minimum, garantissant nos marges.

Ce principe peut, et doit être appliqué aussi à l’architecture des applications. Nous traiterons dans un prochain article de la gestion des flux réseau sur un serveur TCP pour l’illustrer.

Partagez cet article !

Abonnez-vous à notre newsletter !

Si vous souhaitez être notifié lorsqu'un nouvel article est publié, abonnez-vous à notre newsletter et vous recevrez un email dès qu'un article sera publié.

Articles similaires

Qt : pourquoi et quand ut... La gestion des threads dans Qt est simple mais elle mérite quelques explications car elle engendre souvent des problèmes conceptuels chez les développeurs peu expérimentés en Qt.
Qt : l’influence du... Lorsqu’on développe une application mutli-plateformes il est important de se poser la question des performances sur les plateformes ciblées. A machine égale, selon le compilateur utilisé les
Qt : comment implanter un... Il existe plusieurs façons d’implanter des threads dans son application Qt.  Voici la méthode que je préconise. Partagez cet article ! Abonnez-vous à notre newsletter ! Si
Utiliser la technique du ... Le lazy-loading, ou chargement paresseux en français, est une réponse simple à la question simple “pourquoi charger plus de données que nous ne pouvons en afficher ?”.
Adopter les flux tirés d... Nous abordons un des points essentiels de l’architecture réseau et applicative efficace et économe : les flux tirés. Partagez cet article ! Abonnez-vous à notre newsletter !
Qt : Traiter une liste de... Pour qu’une interface graphique reste fluide aux yeux de l’utilisateur, le thread qui la gère ne doit jamais être interrompu plus d’une poignée de millisecondes. Or le
Livre Maîtrisez Qt 5 ... La seconde édition du livre de Tristan Israël, Maîtrisez Qt 5 – Développement d’applications professionnelles, est parue. Vous pouvez le découvrir sur le site des éditions ENI.
Qt : distribuer ses appli... La distribution d’une application est une étape importante de la vie d’une application, elle nécessite d’être pensée très tôt dans la conception. Cette série d’articles présente les

Laisser une réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *