Hey, bonjour tout le monde, j'espère que vous allez bien.
Alors bienvenue dans un nouveau podcast pour apprendre et progresser ensemble autour de la chaîne Xavki.
Alors aujourd'hui on va s'intéresser à un sujet qui se prête plutôt bien au mode podcast,
c'est-à-dire c'est un concept.
L'idée c'est de revenir sur les comic-logs et les messages que vous comprendre quel est leur rôle
et quel est leur intérêt, pourquoi ça apporte autant que ça dans une infrastructure.
Alors ce que je vous propose c'est d'abord un petit jingle et c'est parti.
Alors pour ce podcast que je vous propose c'est un plan en deux parties.
Première partie on va découvrir ce que c'est qu'un comic-log, une message Q.
Et ensuite une deuxième partie on va s'intéresser à cinq sujets, la maintenance, la scalabilité,
la flexibilité, le caractère asynchrone aussi de certaines parties d'infrastructure
et puis également la gestion d'événement.
Donc commençons par comic-log versus message Q.
Le comic-log qu'est-ce qu'on peut en dire ?
Bien tout simplement si on devait se le représenter en étant en forme podcast,
je vais pas vous faire un schéma mais imaginez-vous ça dans votre tête,
prenons une base de données avec une table, une table qui est orientée en row donc en colonne
et avec des lignes et tout simplement derrière on a un applicatif qui va venir ligne, lire,
pardon ligne à ligne.
Et bien pour lire ligne à ligne en fait ça représente un petit peu ce principe de comic-logs,
c'est-à-dire le comic-log on attend à le représenter comme une file chronologique de
messages qui sont accumulés les uns derrière les autres et finalement ce qui se différencie
notamment de la message Q, c'est pas qu'on va déplacer les messages, c'est-à-dire les prendre
un à un, c'est qu'on va déplacer le curseur, l'applicatif, ce qu'on appelle l'offset finalement
au fur et à mesure.
C'est-à-dire que si on reprend notre exemple de base de données avec une table qui est en colonne,
eh bien c'est comme si notre applicatif au fur et à mesure du temps avancé de ligne en ligne.
Mais pour autant les lignes qui sont déjà consommées, déjà regardées, déjà étudiées,
eh bien elles ne sont pas supprimées, elles sont conservées en mémoire, soit en certains laps de temps,
soit vraiment totalement indéfiniment ou soit également en volume aussi on peut fonctionner comme ceci.
Donc ça c'est une des principaux éléments à retenir du comic-logs,
c'est ce fonctionnement qui est finalement on déplace un offset et donc on peut se permettre de garder
les messages stockés tout simplement et vous allez voir ça a d'autres intérêts du coup derrière.
Ensuite donc la queue, donc le message queue c'est un fonctionnement qui a un petit peu
d'afférence, c'est-à-dire qu'on va envoyer des messages dans, alors si on prend un bitmq ça
va être un exchange ou en tout cas un système qui est un petit peu en amont qui va permettre de
rediriger les messages dans des queues et c'est que finalement donc vont servir à accumuler des
messages et de l'autre côté on va avoir des consommateurs. Chaque consommateur va venir
consommer des messages et ces messages au fur et à mesure qu'ils sont consommés ils sont acquittés
et ils sont finalement supprimés. Alors il existe des systèmes pour éviter ou en tout cas rejoindre
le système qu'on a vu de comic-logs mais c'est un fonctionnement qui est relativement différent
puisque vous le voyez si on veut revenir dans le temps, eh bien là en l'occurrence on ne peut
pas le faire puisque les messages ont été supprimés donc on pourra pas revenir dans le temps.
Avec le comic-log potentiellement si pendant une journée on fait de la merde on va le dire entre guillemets
eh bien on va pouvoir revenir en arrière et se dire ok bah moi je vais en jouer tous les
événements qui est tous les messages qui ont été stockés depuis une journée et je vais tout
rejouer dans le même ordre et ça va être assez sympathique pour ça. De la même manière si on
veut avoir une plateforme de démo, de test eh bien on va pouvoir fonctionner de la même manière on
va se dire ok je vais empiler des messages d'une journée et je vais les rejouer x fois de manière
à tester ma nouvelle version d'applicatif donc ça c'est assez sympathique. Sur le message que vous
voilà donc le fonctionnement est assez différent on va venir récupérer les messages un à un et
donc ces messages ont finalement disparaît, leur but c'est pas d'être stocké avec le modèle qu'on
avait de base de données et de table, c'est un fonctionnement qui est très très différent. Attention
il existe quand même des systèmes qui permettent aussi quand même de s'y retrouver un petit peu
comme je vous disais donc ça c'est aussi à garder en tête et souvent l'enjeu de chacune des
technologies de message que c'est d'essayer de permettre aussi de retrouver les qualités du
comic log. Alors si on parle de technologie, comic log c'est par exemple Kafka, pulsar, message
que c'est par exemple rabbit mq, 0mq et plein d'autres quoi, il y en a vraiment beaucoup beaucoup
d'autres. Donc ça c'était la première partie de ce podcast, on a donc en tête ces deux éléments
là la différence entre comic log et message que maintenant on va faire un petit peu abstraction
de tout ça et on va parler des concepts qui tournent autour de l'utilisation de ce type
d'outil. C'est quelques concepts dont je vous ai parlé tout à l'heure donc la maintenance,
la scalabilité, la flexibilité, le caractère asynchrone d'infrastructure et la gestion
d'événement. Ça c'est quelque chose qui est important à voir en tête donc première chose,
la maintenance. Ces types d'outils vont permettre de faciliter généralement la maintenance de
partie d'infrastructure. Pourquoi ? Alors sur deux aspects important d'une part eux-mêmes,
eux-mêmes sont des systèmes distribués, un coup prenez Kafka, RabbitMq ou autre,
c'est des clusters, donc des systèmes en mode cluster qui vont permettre aussi de gérer la
performance un petit peu avec puisque on a des systèmes distribués, on va avoir des systèmes
de partitionnement, c'est-à-dire la capacité à répartir des messages différents sur différentes
machines, différents serveurs quand on est en cluster et ça va permettre aussi de répartir
la charge. L'autre aspect important d'ailleurs tout ça, c'est la haute disponibilité aussi de
ces clusters, soit Kafka ou RabbitMq. C'est-à-dire que si j'ai besoin de maintenir un de ces
applicatifs ou le système sur lequel ils reposent, je vais pouvoir le faire parce que
je vais pouvoir sortir du cluster un œuf proprement et ensuite appliquer mes tâches de maintenance,
les upgrades etc. Donc ça c'est pour l'appartis spécifiquement de l'applicatif lui-même qui
gère le commitlog ou le message queue. L'autre élément qui est important, c'est que dessus on va
brancher soit des producteurs, soit des consumers et on l'a vu donc le but c'est d'avoir des messages
finalement qui vont être quand même agglomérés les uns derrière les autres, que ce soit en commitlog
ou un message queue. Dans un cas où ils disparaissent, dans l'autre cas ils ne disparaissent pas,
néanmoins s'ils ne sont pas consommés ces messages, ils vont rester dans le topique ou la queue,
c'est-à-dire l'élément, le buste de messages dans lequel ils sont stockés. Et derrière ça veut
dire que par exemple si je veux maintenir un consumer, quelque chose qui va consommer les
messages de ces topiques ou de ces queues, et bien derrière je vais pouvoir le sortir de mon
infrastructure, stopper les machines, stopper les potes, stopper les containers peu importe,
on va pouvoir les stopper et reprendre là où on en a été arrêté juste après. C'est à dire qu'on
a un aspect stateful qui est maintenu et qui est géré vraiment très très fortement. Donc ça c'est
quelque chose qui est très très important, ça permet du coup d'avoir une très très bonne
gestion de l'infrastructure, en tout cas des capacités de maintenabilité de ces parties,
de ces breaks d'infrastructure. Donc ça c'est quelque chose qui est important. De la même manière,
et là ça rejoint du coup ce principe de maintenabilité, ça apporte aussi de fortes capacités de
scalabilité. De la même manière que par exemple je vous ai dit on peut stopper des consumers et on
va reprendre là où on en était, donc on a un caractère asynchrone, on a notre base de données,
tant qu'on n'a pas consommé, ces messages sont toujours là et on va les rejouer, on va les
rejouer dans le même ordre. Et bien sur la scalabilité c'est le même principe, plutôt que de passer à
zéro, à ce moment là ce qu'on peut faire c'est augmenter le nombre. Peut-être qu'à un moment de
la journée je vais tourner à un consumer et peut-être que à des peaks par exemple le soir entre 18
et 20 heures, je vais avoir besoin de scaler, c'est à dire augmenter le nombre d'applicatives
parce que j'ai avoir beaucoup plus de messages. Je vais pouvoir le faire facilement puisque mes
messages sont consommés alternativement, donc dans l'ordre où ils ont été reçus. Et donc plus je
vais avoir d'applicatives, plus je vais les consommer rapidement mais pour autant je ne vais pas
forcément en perdre l'ordre. Attention je dis pas forcément, ce n'est pas toujours le cas, il faut
bien veiller à ces éléments là si vous avez une nécessité de comment. De prendre en compte ce
paramètre, c'est à dire vraiment l'ordre strict des messages. Et l'ordre strict des messages a
nécessité vraiment d'étudier très finement les applicatifs, éventuellement de stocker des états à
côté, ça on en parlera probablement une autre fois. Donc ça c'est quelque chose qui est important
et de la même manière pour les producers on retrouve cet aspect scalabilité qui est aussi très très
important. Par exemple on va pouvoir aussi scaler sur le nombre de messages que l'on a dans la queue
ou dans le topic. Si on voit qu'on a beaucoup de retard sur la consommation de messages on va pouvoir
dire ok le nombre de consumers il va falloir que je l'augmente et de ça on va pouvoir complètement
l'automatiser grâce à du monitoring de l'observabilité et on va coupler ça par exemple avec du
Kubernetes, de la conteneurisation mais pas forcément et on va pouvoir forquer, recréer des
instances pour pouvoir consommer un petit peu plus vite le temps donné. Alors ça on le retrouve
c'est quelque chose qu'on retrouve très très souvent par exemple dans les sites de e-commerce.
Vous avez des très fortes variations des vagues importantes au cours de la journée à des moments
de la journée par exemple minuit, une heure du matin, vous n'allez pas forcément avoir beaucoup de
commandes de trafic puis à d'autres moments de la journée vous allez avoir vraiment besoin de beaucoup
beaucoup scaler de manière à pouvoir consommer ces messages qui sont par exemple des commandes.
Donc ça c'est un point important la scalabilité. La flexibilité également c'est à dire que derrière
ça permet un découplage des fonctionnalités qui est généralement lié à l'approche micro service des
infrastructures. C'est à dire imaginons, on va prendre un scrapper c'est à dire quelque chose qui
passe des pages web c'est à dire qui récupère leur contenu. Généralement ça quelque chose qui peut
être gourmand en CPU, éventuellement en RAM et donc on va dire c'est une bric applicative qui
a des spécificités. Derrière si je veux qu'on soit quelque chose de relativement monolithique,
ce qui peut se passer c'est que je me dis bah voilà je collecte des informations sur des pages web
et je vais vouloir les écrire en base de données. Donc on va peut-être rajouter à cette bric qui est
d'une part la fonction de scrapping c'est à dire de récupération de l'information. On va rajouter une
deuxième fonction au sein du même applicatif qui va permettre d'ingérer les data dans la base de
données. Là on est en format monolithe on va dire quand on fait ça et l'inconvénient c'est que
finalement j'ai pas besoin du même type de ressources que ce soit pour écrire dans la base de données
ou que ce soit pour récupérer les éléments de la page qui va être scrappé et ça c'est très très
important. Le fait de découpler les deux fonctionnalités on va pouvoir y mettre entre les deux par
exemple ce type d'éléments c'est à dire le commit log ou les message queue et qu'est-ce que ça va
permettre tout simplement ça va permettre de découpler les deux fonctionnalités. Donc notre
producer ça va être celui qui va récupérer les informations sur nos pages web et il va les écrire
dans les queues de messages les topiques peu importe et derrière ça va être consommé par notre
consumer donc qui lui a pour but de simplement de récupérer les messages les écrire en base de
données. Écrire dans la base de données potentiellement ça peut être très très rapide et ça peut
consommer très très peu de ressources finalement alors que en amont le scrapper lui par contre il
va avoir besoin de potentiellement plus de ressources et là ce qui est bien c'est qu'on va pouvoir
scalez vraiment plus finement donc c'est les histoires si on devait le faire le parallèle c'est
les briques de l'ego plus ma brique est grosse en termes de l'ego moins je vais pouvoir la placer
partout plus elle est fine plus je vais pouvoir la mettre partout. Là c'est exactement le même
principe mon producer qui est relativement gros je vais pouvoir le faire scalez du coup vraiment
beaucoup plus par son profil en tout cas et adapter les VM qui par exemple que je vais utiliser
les potes que j'ai utilisés mettre plus de cpu moins de RAM et inversement côté consumer
je vais pouvoir peut-être en avoir très peu de consumer et spécifiquement avec le profil adapté.
Donc ça c'est quelque chose qui est très très important c'est ce que j'appelle la
flexibilité ça porte vraiment de la souplesse et couplé à ce qu'on a vu auparavant la scalabilité
plus là maintenant c'est quand même relativement intéressant ensuite donc on a aussi la possibilité
comme je disais en termes de flexibilité c'est de mirorer les messages d'une manière ou d'une
autre attention chaque outil dispose un petit peu de ces spécificités quand on est au commitlog
c'est certaines manières quand on est en tout cas c'est très très natif quand on est par exemple
sur des messages que comme rabit mq c'est beaucoup moins natif là derrière néanmoins ça apporte
quand même une flexibilité qui est importante c'est à dire le jour où j'ai besoin de double
consommé ou de tester des nouvelles briques applicatives je vais pouvoir les tester avec
le flux de la production puisque vous voyez que par exemple dans notre cas de ce qu'on avait tout
à l'heure qui était le le scraper par exemple je vais pouvoir récupérer les messages qui sont
scrappés une seule fois et je vais pouvoir les dupliquer derrière et les mettre dans deux queues
différentes une queue qui va être ma queue de production l'autre que qui va être la queue de
développement et toute la chaîne derrière ça va pouvoir être ma chaîne de développement pour
pouvoir tester les développements en question sur un flux de production donc ça c'est quelque
chose qui est aussi très très important alors voyez je tourne mes pages parce que petit à petit
j'ai juste des bullet points mais il y a tellement de choses à dire le caractère a synchro maintenant
et ça c'est aussi quelque chose qui est très très important c'est ce qu'on vient de voir tout
de suite c'est à dire c'est la capacité à arrêter des briques applicatives finalement on
stop la consommation on la reprend quand on le souhaite sous réserve bien sûr d'avoir la
capacité de stockage sur ces outils là comme il t'a ou mais c'est de la vente à se dire on peut
fonctionner complètement en a synchron si on prend notre site de e-commerce par exemple notre site
e-commerce j'ai beaucoup de commentes à un moment de la journée à la journée pardon et là qu'est
ce qui se passe et bien soit je j'ai une infrastructure qui est scalable à volonté et dans
ce cas là je me pose aucune question elle va se quitter tout de suite mais pour ce qu'elle est
justement j'ai besoin de ce type de boutilles généralement soit sinon elle n'est pas scalable
et ça veut dire quoi ça veut dire que si mon infrastructure n'est pas scalable et bien j'ai un
problème il va falloir que je paye tout le temps une infrastructure qui est relativement grosse et
que je sois dans le cloud ou hors cloud ça a un coût relativement important ça plus un coût
important dans le cloud que hors cloud hors cloud une infrastructure quoi qu'il arrive on la paye
dans le cloud on paye que ce qu'on se consomme donc du coup là ça a un intérêt encore plus important
dans dans le cloud et derrière donc qu'est ce qui se passe ben peut-être qu'à des moments de la
journée je vais empiler des commandes mais je vais peut-être pas avoir besoin de les traiter
tout de suite tout de suite c'est à dire que par exemple si je considère entre 12 heures et 14
heures j'ai beaucoup de commandes je peux peut-être les faire en sorte qu'elle s'accumule dans
cette message que ça ne m'empêche pas que je vais les consommer toujours à un rythme donné et
puis finalement je sais que le reste de l'après-midi est relativement soft calme et à ce moment là
ce que je vais faire et bien je vais les garder toujours le même rythme de consommation mais
comme je redescend en dessous de mon rythme de croisière de consommation je vais petit à petit
ré-consommé tout ce qui a été accumulé entre 12 heures et 14 heures et de fait mon infrastructure
j'ai pas eu besoin de la faire ce qu'elle est up et j'ai réussi à tamponner à gérer ça grâce
aux caractères asynchrones de l'infrastructure attention ça ne m'empêche pas que c'est pas
la technique qui fait tout à derrière il faut concevoir les infrastructures aussi pour qu'elles
soient prêtes à gérer ces émails ensuite il y a la gestion d'événement alors ça on va le
prendre sous forme d'un exemple c'est ce qu'on appelle l'event drive on va reprendre l'exemple
du site de e-commerce qu'est ce qui se passe dans un site de e-commerce généralement ben on a des
clients qui se promènent sur des pages et à un moment donné ils font un panier et qui débouchent
sur une commande la commande elle est unique mais derrière elle enclanche différentes actions
pour réaliser ces différentes actions on a besoin des caractéristiques de la commande ce
soit pour préparer un colis en logistique donc ça va être par exemple juste faire le colis dans
notre pot mais ça va être aussi peut-être de prévenir le transporteur qui a un colis qui est
en préparation donc ça fait deux éléments de fil finalement on a également le fait que
il faut faire payer notre client quand même on travaille pas pour rien non plus donc il va
falloir préparer la transaction réaliser la transaction donc ça c'est un autre élément
et puis par exemple on va envoyer bien sûr un email de confirmation à notre client pour dire ok
ta commande elle a été passée et tu risques d'être livré d'ici trois quatre jours etc. donc ça
c'est des files différentes néanmoins chaque file différente va consommer le même message
c'est à dire la commande la commande elle va contenir les pièces le nom de la personne etc.
éventuellement plus ou moins dans le détail suivant la conception de l'infrastructure mais
en tout cas c'est un événement on va dire ok j'ai reçu la commande x et c'est elle qui va
déclencher la mise en colis c'est elle qui va déclencher la transaction c'est elle qui va
déclencher l'email et donc c'est là on parle d'événements c'est des événements et chacune
des briques qu'on a vu donc le mail par exemple bah ça va être un applicatif ou un groupe d'applicatif
qui va charger d'envoyer le mail la transaction ça va être un autre groupe d'applicatif qui va
le réaliser la gestion des colis également et donc derrière voyons on commence à décrire
une infrastructure de microservice qui est basée sur des événements et l'intérêt derrière ça va
être d'éviter de dupliquer la donnée entente qui est la commande la commande je vais l'écrire
une fois pour toutes dans mon fameux topic par exemple donc en mode commit log donc je vais
insérer petit à petit des messages qui vont être chacun une commande et finalement je vais avoir
ma fameuse table des commandes si on devait faire le parallèle avec la base de données et derrière
qu'est ce qui va se passer ? Bah chaque applicatif va lire à son rythme la table en question le commit
log il va pouvoir le dépiler et faire avancer son propre offset lié à chacun des applicatifs
c'est à dire que si j'ai un applicatif d'email qui va très vite lui il va pouvoir envoyer des
mels à la voler relativement de manière synchrone pardon et donc derrière il va pouvoir suivre les
choses à son rythme il fait évoluer l'oset très très vite et puis par contre bah par exemple
les transactions ça peut être peut-être plus long peut-être les colis peut-être ça va être plus
long avec peut-être l'intervention d'humains je sais pas et derrière ça va être relativement
moins synchrones et relativement plus asynchrones et derrière bah l'oset va avancer plus lentement
donc ça vous voyez que c'est un caractère très très intéressant ce type de fonctionnement on pourrait
prendre le même parallèle par exemple si on prend une grande chaîne d'hôpital d'hôpito pardon
on va respecter le français et derrière bah imaginons j'ai un patient qui arrive il pointe
à l'accueil et derrière il y a plein de choses qui peuvent en y arriver en cascade par exemple
derrière bah ça veut dire peut-être que son médecin on va confirmer qu'il va recevoir le comment
les éléments de l'entretien qui va passer avec le patient peut-être qu'en parallèle on va aussi
déclencher un autre événement qui va être par exemple le pré rendez vous pour la mise en place
dans la une file d'attente pour les pour réaliser des radios par exemple etc etc donc là ça
fonctionne vraiment dans beaucoup de cas de figure c'est aussi très très utilisé dans le monde
bancaire dans le monde des assurances c'est un fonctionnement ce qu'on appelle en pub sub
publicer subscriber donc quelque chose qui est très très pratique et là encore ce qui est très
intéressant c'est que chaque applicatif va pouvoir s'y retrouver travaillé à son rythme on le retrouve
aussi en infrastructure dans la gestion de log notamment en matière de sécurité d'ailleurs on
va vouloir par exemple bah passer des logs savoir s'il y a une alerte et quand il y a une alerte
réaliser différentes actions on peut retrouver ce type de fonctionnement là également alors
j'espère que ce podcast vous a plu essayer de me faire des petits retours avec les podcasts c'est
pas si évident que ça parlez-en autour de vous partagez ces podcasts vous avez plein de
manière de pouvoir vous abonner que ce soit par apple par google podcast et plein d'autres
manières vous pouvez également vous abonner par mail puisque c'est un fonctionnement sous
newsletter aussi avec le site qui me permet de partager les podcasts et moi je vous dis à très
bientôt sur gavki ciao à tous