Chez Allo-Media, comme beaucoup d’autres entreprises, notre chaîne de valeur ressemble à un pipeline : nous collectons les conversations (principalement par téléphone) que nous envoient nos clients, nous les transcrivons, nous marquons les transcriptions avec des entités nommées, nous anonymisons à la fois la transcription et l’audio, puis nous qualifions le contenu avec des balises sémantiques, et enfin nous les indexons et fournissons une interface utilisateur et une API pour consulter, rechercher, analyser les conversations. Toutes ces étapes sont réalisées automatiquement par des algorithmes de NLP et d’IA.
Ces pipelines sont bien adaptés aux architectures basées sur les services. Si vous devez ajouter une nouvelle fonctionnalité, vous introduisez un nouveau service dans le pipeline.
Notre première tentative était basée sur les services REST.
Malheureusement, comme le montre le schéma ci-dessus, cette approche présente un certain nombre d’inconvénients :
- il introduit un couplage fort entre les composants, car presque chaque service doit connaître les autres services connexes, leurs adresses, leurs objectifs, leurs API… ;il introduit un couplage fort entre les composants, car presque chaque service doit connaître les autres services connexes, leurs adresses, leurs objectifs, leurs API… ;
- l’équilibrage de la charge nécessite des solutions ad hoc (comme pour le Transcription Pool Manager avec Celery) ;
- la haute disponibilité est délicate en raison de la communication synchrone : si le service demandé est en panne, l’appelant doit mettre en œuvre des stratégies complexes de « réessai ultérieur » ou abandonner ! Et ainsi de suite pour chaque service.
- La mise à niveau ou l’ajout de nouveaux services représente un travail considérable, car ils ont une incidence sur d’autres services et nécessitent des mises à disposition soigneusement coordonnées. De plus, vous devez leur fournir des adresses IP et DNS.
Un an plus tard, alors que notre activité augmentait et que le développement s’accélérait, nous nous sommes rapidement rendu compte que nous avions besoin d’une solution :
- un découplage maximal des services ;
- une distribution aisée ;
- l’équilibrage de la charge est un jeu d’enfant ;
- communications asynchrones de un à un, de un à plusieurs, de plusieurs à un, de plusieurs à plusieurs ;
- haute disponibilité : redémarrage à chaud des services, ajout ou suppression transparente d’instances de services (travailleurs), résistance aux temps d’arrêt (raisonnables) de certains services ;
- prise en charge des charges utiles lourdes (mégaoctets d’audio mp3) ;
- aucune perte de données, quoi qu’il arrive.
L’architecture pilotée par les événements
La meilleure façon d’atteindre ces objectifs est de se libérer du point de vue classique du pipeline et de considérer la chaîne de valeur comme un écosystème de services commerciaux, chacun étant axé sur la fourniture d’une valeur spécifique et réagissant à des événements (entrées) et produisant de nouveaux événements (sorties). Cette nouvelle métaphore présente non seulement des avantages techniques, mais aussi des avantages commerciaux et organisationnels. En raisonnant en termes d’unités commerciales de votre chaîne de valeur, il est plus facile d’identifier les personnes impliquées, les experts commerciaux qui sont les références pour le travail, la valeur ajoutée exacte du service, etc…
Voici le schéma de notre nouvelle architecture :
Dans cette nouvelle architecture, les événements sont des messages définis avec précision qui circulent sur un bus de messages, et chaque service logique (mettant en œuvre un service d’entreprise tel qu’expliqué ci-dessus) s’abonne aux événements qui le concernent, sans avoir besoin de savoir ce qui les a produits et comment. Ils poussent également leurs propres événements sur le bus, sans se soucier de ce qui les consomme.
De cette manière, nous découplons complètement les services les uns des autres et le courtier de messages qui gère le bus de messages nous fournit gratuitement l’équilibrage de la charge, la distribution et la haute disponibilité.
Aujourd’hui, les messages sont l’API, la seule référence commerciale et technique.
Après beaucoup de réflexion et d’expériences, nous sommes arrivés à des principes de conception fondamentaux qui sont très importants pour le succès d’une telle architecture axée sur les événements et après 4 mois d’utilisation en production, nous sommes très heureux d’avoir respecté ces principes dès le départ. Mais c’est le sujet d’un autre article de blog à venir. Restez à l’écoute !
