Event driven architecture : comment Deezer passe en mode réactif
•Télécharger en tant que PPTX, PDF•
0 j'aime•144 vues
Slides du talk du meetup AFUP Paris Janvier 2020
Recommandé
Recommandé
Contenu connexe
Similaire à Event driven architecture : comment Deezer passe en mode réactif
Similaire à Event driven architecture : comment Deezer passe en mode réactif (20)
Dernier
Dernier (20)
Event driven architecture : comment Deezer passe en mode réactif
- 1. Add a picture here Event-driven architecture Comment Deezer passe en mode réactif Add a picture here
- 2. événement “Tout ce qui se produit, arrive ou apparaît” Larousse
- 3. Qui est intéressé ? ● Artistes / Labels ● Equipe Produit ● Data scientists
- 5. Hey! Il écoute un titre des Black Keys
- 11. Syslog
- 12. Syslog - avantages + Asynchrone + Facile à utiliser par les équipes Data + Facile à utiliser par les développeurs
- 13. Syslog - limitations - Pas de temps réel pour la Data - Pas de contrat d’interface - Workers limités à un serveur - Pas de monitoring sur RTLog - Confusion entre logs et événements
- 14. Ce qu’on a mis en place
- 16. Event bus Robuste Scalable Performant
- 17. Anatomie d’un message ✉️ Privé Public Producer == consumer Producer Consumer Json schema ConsumerConsumers
- 18. Bus d’événements - avantages + Asynchrone + Facile à utiliser par les équipes Data même en streaming + Facile à utiliser par les développeurs grâce à des librairies + Monitoring out-of-the-box + Outillage disponible pour valider les messages
- 19. Bus d’événements - attention - Plus de travail pour les développeurs - Consommateurs en PHP… ce fut épique ! cf. “Kafka - Consume topics in PHP from nightmare to performance” - talk de Loïc D au SFPot de Février 2019 https://fr.slideshare.net/gdflkgjdfklgj/deezer-consume-topics-in-php-from-nightmare-to-performance
- 20. Focus sur PHP - Php-rdkafka → https://github.com/arnaud-lb/php-rdkafka - Librdkafka → https://github.com/edenhill/librdkafka - Capable de consommer 1.3 milliard event / jour Pic de 30K / s 80 ms
- 21. Et pour la suite ?
- 23. Key takeways L’architecture orientée événement apporte un découplage des services et réduit la latence L’importance du contrat d’interface dans les événements Outillage, outillage, outillage
- 24. Thank you Vincent Lepot Lead web architect @neozibok
Notes de l'éditeur
- Pour vous c’est quoi un événement. Demandons à Larousse. (clic) Dans un SI on pourrait dire que ce sont les interactions avec l’extérieur, les actions internes, les réactions à ces actions.
- Prenons un exemple d’un événement : un utilisateur d’un site musical écoute de la musique(clic) Qui est intéressé par cet événement ? Pas l’utilisateur lui-même mais (clic) Les artistes et leurs labels pour les royalties qu’ils doivent recevoir (clic) L’équipe produit pour connaître les usages des utilisateurs grâce au contexte (clic) Les data scientists pour pouvoir travailler sur la recommandation
- Dans une approche traditionnelle, on ferait les actions à réception de l’appel API Mais ceci serait : Coûteux en latence d’un point de vue utilisateur Risqué en cas d’indispo d’un sous système
- L’idée de l’architecture orientée événement (EDA) est de dire ce qu’il se passe et de laisser les intéressés venir se servir, réagir. On n’attend plus que tout le monde soit servi Découplé
- Et des événements dans un SI, il y en a plein ! Login, logout, inscription, souscription, mise en favoris, nouvel album... En y réfléchissant 2 secondes, quelque soit le business, vous en avez déjà plein en tête.
- Quelque part on modélise ce qui se passe dans la nature. Nous, êtres vivants, réagissons à des stimuli. Son, lumière, contacts physiques, odeurs,... Et nous réagissons tous différemment. C’est pareil dans un SI. Chaque service, chaque application va réagir à sa manière à certains événéments. Par exemple : takedown. Site doit invalider son cache, paiement s’en fout
- Pourquoi je dis ça ? → Deezer il y a quelques années c’était ça : le fameux monolithe. Vous savez sans doute déjà que ça a des avantages mais surtout des inconvénients (pb de code spaghetti, responsabilités non claires, difficultés à mettre en production et à maintenir…)
- Donc comme beaucoup, nous avons commencé à exploser ce monolithe en plusieurs morceaux qui interagissent tous ensemble pour fournir le service et nous aider à le faire évoluer plus vite, de manière plus aisée. (Je ne vous fais pas l’article sur l’approche SOA/microservices…) Et c’est là où l’approche par événement prend tout son sens (clic) : plutôt que de faire des appels HTTP partout, certains traitements sont faits de manière asynchrones par de l’écoute d’événements.
- Avant de vous expliquer ce qu’on a fait, revenons sur ce qu’on faisait avant. Car on avait déjà des traitements asynchrones avant (quand même)
- Et on utilisait syslog (plus précisement rsyslog) pour transporter de l’information La data vient chercher les logs de J-1 (ou de H-1) pour import Pour l’asynchrone, RTLog (genre de tail -f) envoie les lignes à des workers
- Ce qu’il y a de bien dans cette solution Asynchrone Ce sont des fichiers plats à importer côté data Pour les développeurs, ce sont les mêmes outils que pour du log, c’est natif dans PHP
- Par contre, on se retrouve limités sur : Le manque de temps de réel (pas de stream possible) Le manque de contrat d’interface (pas lié à la stack technique) L’absence de monitoring sur RTLog (on se repose sur le râlomètre pour détecter les outages) La pédagogie à mettre en place pour faire la différence entre log applicatif et événement métier
- On envoie nos messages dans un bus d’événement qui est en fait en broker de messages et ces messages peuvent être consommés par n’importe quelle application, quelque soit son langage (tant qu’elle sait se connecter au broker) Pour la partie Data, on utilise Spark streaming pour le temps réel
- Notre bus d’événements est basé sur Kafka Nous avons fait ce choix car des milliards d’événements par jour (4 milliards environ). scalable, … Par contre, ce serait tout aussi valable avec d’autres brokers de messages comme RabbitMQ, ActiveMQ ou NSQ. Peu importe
- On distingue 2 cas d’usage : Privé : une application consomme ses propres messages. Elle est libre du format, du versionning, de casser de la compatibilité. Les autres applications n’ont pas à les utiliser (si elles le font, ce sera à leurs dépends) Public : un application émet des messages pour d’autres applications consommatrices => Alors (clic) elles ont un contrat d’interface à mettre en place Le contrat est un JSON schema qui doit répondre à une norme définie pour Deezer, et peut contenir des notions d’acteurs et de contexte.
- On a déjà dans notre migration commencé à implémenter un pattern CQRS. L’idée est d’ajouter une notion d’event source pour avoir les avantages de ce genre de solution: Historisation (pour l’audit notamment) Une capacité de replay en cas de problème En ajoutant une dose d’asynchronisme (là où ce sera possible évidemment)