Du découplage
(Jean fait la queue avec Vincent au Starbucks) Jean : Quel monde ! Dire que je n'ai que 20 minutes, nous n'allons jamais avoir le temps de boire notre café ! Vincent : Ce n'est pas grave Jean, 20 minutes à faire la queue, ca reste un moment pour décompresser.
Serveuse : Bonjour messieurs, que désirez vous commander ? Jean : Bonjour, un frappuccino s'il vous plait. Vincent : Bonjour, avec un café liégois s'il vous plait. Serveuse : Merci, un prénom ? Jean : Jean. Serveuse : Merci. (elle donne un ticket à Jean)
Jean : Oui mais tout de même, je préfère être assis. C'est plus agréable ! Vincent : Cela fait presque un mois que l'on ne s'est pas vu... Quoi de neuf ces derniers temps ?
Jean : Ne m'en parle pas ! La panique ! Je passe mon temps à éteindre les feux entre la production et les intégrateurs ! Vincent : Que se passe-t-il ? Tu avais l'air plutôt content la dernière fois que l'on s'est vus.
Jean : Je l'étais oui. Nous avions enfin réussi à mettre en production notre solution de suivi de eRéputation. Vincent : Et les utilisateurs n'ont pas suivi ? Jean : Au contraire ils ont suivis, trop même ! Rapidement, nous avions tellement d'utilisateurs que nos serveurs ont commencé à être surchargés. 4000 requêtes à la seconde, tu imagines... Vincent : C'est un bon début. J'imagine que le marketing est content.
Caissier : Bonjour messieurs, votre prénom s'il vous plaît ? Jean : Jean. Caissier : Un frappuccino et un café liégois. Ca fera 9€. (Jean paye) Caissier : Vous pouvez aller chercher votre commande à côté. Jean : Merci.
Jean : Justement non. Le marketing n'est pas content car le service est devenu extrêmement lent et les serveurs plantent régulièrement. Vincent : C'est parcequ'ils sont trop chargés. Vous n'en avez pas ajouté de nouveaux pour faire face à la charge ? Jean : Justement oui ! Nous avons essayé mais tu sais, il ne suffit pas d'ajouter des serveurs pour tenir la charge, c'est plus compliqué ! Vincent : Comment cela ? Jean : Et bien, chaque serveur contient le site et l'API. Les données clients sont stockées sur une base de données et nous avons une machine dédiée aux batchs de calcul de eRéputation. Nos serveurs web et API sont aujourd'hui trop chargés et...
Préparateur : Le frappuccino et le café liégois de Jean ! Jean : C'est ici. Merci. (ils vont s'assoir)
Vincent : Donc vos serveurs web et API sont trop chargés c'est cela ? Jean : Oui (dessinant sur un bout de serviette). Regarde, on a essayé d'en ajouter de nouveaux mais cela n'a pas amélioré les temps de réponse... vincent : Pourquoi ? Jean : Parceque le nombre de requête par seconde à la base de données a augmenté. Et cette dernière atteint ses limites...
Vincent : Et votre serveur de batch ? Jean : Même problème ! On a acheté un serveur avec un gros CPU et beaucoup de mémoire pour faire les calculs en quasi temps réel mais avec l'augmentation de la charge, chaque calcul prend de plus en plus de temps ! Il faudrait presque avoir un serveur de batch par client mais économiquement, ce n'est pas tenable.
Vincent : (réfléchit...) Tu as remarqué ? Jean : Quoi ? Vincent : Nous sommes assis. Jean : C'est vrai que cela a été plutôt rapide malgré l'affluence ! Vincent : C'est étonnant, il y a bien trois fois plus de monde que d'habitude... Jean : Oui mais si tu regarde bien, il n'y a toujours qu'une vendeuse mais les deux caisses sont ouvertes et ils ont triplé le nombre de préparateur. Vincent : Et alors ? Jean : Alors, chaque commande est indépendante. Plus il y a de vendeuses, plus il peuvent prendre de commandes rapidement. Plus il y a de caisses ouvertes, plus ils peuvent encaisser les commandes rapidement, plus il y a de préparateurs, plus ils peuvent préparer les commandes rapidement. Et comme ils ont découplé ces trois composantes de leur chaîne de traitement et mis en place une file d'attente pour réguler leurs interactions, absorber les afflux revient à faire varier le nombre de ressources sur chaque composante indépendamment. La décision est prise en fonction de la charge de chaque composante à un moment T.
Vincent : Donc si je comprend bien, ils découplent les composants, ces derniers ne travaillent pas directement ensemble mais passent par des files d'attente. Leur but est donc de vider ces files d'attente le plus vite possible. De cette manière, si un composant est surchargé, lui ajouter de la ressource ponctuellement peut se faire sans risquer d'impacter les performances des autres. C'est cela ? Jean : Oui, exactement !
Vincent : Penses tu que ce serait applicable à ton problème de montée en charge ? Jean : Maintenant que tu en parles, c'est vrai qu'il y a de grosses similitudes... Un consultant m'a d'ailleurs récemment recommandé de re-architecturer la solution autour d'un bus de message. Il disait que si les composantes de la solution communiquaient au travers de files de message, cela découplerait l'ensemble et permettrait de réguler les montées en charge plus facilement.... (dessinant sur un autre bout de mouchoir) Ca ressemblait un peu à cela.
Vincent : Intéressant, peut être que tu peux découpler en fonction des sujets de publication que tu as mis. Jean : Oui, Le stock et les produits préparés sont deux éléments distincts. Dans mon cas, si j'applique le même raisonnement je pourrai séparer mon stock, les données utilisateurs de mon produit fini, la donnée calculée par les batchs qui pourrait se trouver dans une base à part en lecture seule... D'ailleurs j'y pense, les données utilisateurs devraient elles même être séparées des données sources des batchs qui est ma véritable matière première en fait...Je vais peut être le rappeller finalement.
Jean : Bon allez, c'est l'heure et j'ai du boulot ! A bientôt Vincent ! Vincent : A bientôt !