Successfully reported this slideshow.
Your SlideShare is downloading. ×

Tartine - Pixelle, Refonte de l’ingestion et présentation de l’architecture

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 40 Ad
Advertisement

More Related Content

More from confluent (20)

Recently uploaded (20)

Advertisement

Tartine - Pixelle, Refonte de l’ingestion et présentation de l’architecture

  1. 1. Tartine — Pixelle Refonte de l’ingestion — présentation de l’architecture
  2. 2. Agenda
  3. 3. • WayKonect, qui sommes-nous • Pourquoi devons-nous évoluer • De quoi avons-nous besoin • Nouvelle architecture • Kafka for the Dummies • Merci Tartine-Pixelle — agenda
  4. 4. Présentation WayKonect
  5. 5. GREENTECH DE LA MOBILITÉ
  6. 6. GreenTech de la mobilité • Être exemplaire en termes de sécurité des collaborateurs et des données • Faire de WayKonect une « low carbon company » • Être un acteur local reconnu en matière de développement durable Une entreprise humaine et responsable NOS VALEURS D’ENTREPRISE NOS SOLUTIONS POUR NOS CLIENTS • Être une entreprise où il fait bon vivre • Développer une équipe engagée prête à défendre notre stratégie et nos valeurs • Être reconnu sur le marché et dans la compagnie comme un expert de la data au service de la mobilité responsable Une équipe soudée et fière de participer à la révolution énergétique • Contribuer à réduire l’empreinte carbone et renforcer la sécurité de la mobilité. • Développer notre capacité d’innovation et renforcer notre culture Data driven • Développer des solutions modulables, ouvertes, 100% digitales • Avoir des produits rentables Concevoir des solutions Innovantes, performantes et durables • Créer une relation de proximité avec nos clients pour concevoir et faire évoluer nos solutions • Avoir des clients satisfaits et promoteurs de nos solutions • Délivrer de la valeur à chaque itération Le client au cœur de nos décisions NOS VALEURS D’ENTREPRISE NOS SOLUTIONS POUR NOS CLIENTS
  7. 7. Une proposition de solutions riches et complètes Parcours digitaux Véhicules Electriques Connect Car sharing Parcours digitaux Mobility Corporate
  8. 8. Pourquoi devons-nous évoluer
  9. 9. Contexte — l’ingestion ? koi cé t’esk? • L'ingestion joue un rôle majeur dans la structure Iot de la solution du portail Mobility Business: elle est responsable de l'essentiel des traitements d’intégration des données de télématique. • La solution comportait certains défauts. De la performance à la fiabilité, l'ingestion devait être renforcée, repensée pour pouvoir évoluer. • Pour atteindre ses objectifs, l’architecture doit évoluer en permanence • Dans sa version actuelle, l'ingestion lit les informations de plusieurs fournisseurs de données de télémétrie de véhicules (boitiers sur prise Obd, ou système préembarqué du constructeur automobile) • L'ingestion gère actuellement de nombreux concepts fonctionnels et déclenche de nombreux processus externes
  10. 10. Contexte — Architecture actuelle
  11. 11. Contexte — quels problèmes résoudre Que faut-il faire avec l’ingestion pour que cela fonctionne: - Les autres concepts métiers et fonctionnels doivent être retirés et pris en charge au sein traitements séparés. - La logique itérative de ces processus actuellement au sein de l'ingestion est une cause principale des différentes préoccupations identifiées : ü Montée en charge limitée par les choix techniques initiaux. ü Gestion des erreurs techniques complexes. ü Interfaçage avec un modèle de donnée en graph . ü Complexité de la maintenance de la solution initiale. ü L'ingestion, écrite en 'C#,' est actuellement hébergée sur un cluster Azure Service Fabric ce qui implique un accès contraint aux journaux d’application (Logs) ü Montée en capacité limitée Au centre de ces notions d'entreprise se trouve celle de voyage, ou trajets J L'ingestion doit être le seul processus à gérer ces derniers. Autrement dit, l’ingestion devrait être un Micro Service Comme vous pouvez le voir, l'ingestion est ce que l’on appelle un point de défaillance unique
  12. 12. De quoi avons-nous besoin
  13. 13. - Un outil capable de centraliser les flux de données provenant des systèmes externes ou au sein de l’entreprise. - Un système distribué capable d'évoluer horizontalement - Un système capable de lire tout type de flux de données (JSON, binaire pur, etc.) - Un système capable de prendre en charge des vitesses très élevées pour la publication ou la lecture de données. - Le rythme actuel relevé auprès de notre principal prestataire de données est de 400 000 messages / minutes - 1 message représente 8000 enregistrements - Nous avons plusieurs milliers de boitiers roulant simultanément aujourd’hui. - Une télémétrie (mesure enregistrée sur un véhicule) pour un boitier d’usage basique c’est 150 champs - Une télémétrie (mesure enregistrée sur un véhicule) pour un boitier d’usage prémium c’est 500 champs - Ce produit doit supporter la consommation d'un flux de données par de multiples consommateurs, - Il faut s’assurer d’un découplage des systèmes producteurs et consommateurs de données, la défaillance de l’un ne doit pas impacter l’autre - Il faut permettre la consommation de messages en temps réel et en mode batch. Besoin 1 : La réception des données Nous devions trouver un système de messagerie distribué en mode Producteur — Consommateur, capable de s'adapter facilement, de supporter des débits de données très élevés et d'assurer la persistance des données qu'il reçoit.
  14. 14. Réponse 1 — Kafka Nous devions trouver un système de messagerie distribué en mode Producteur — Consommateur, capable de s'adapter facilement, de supporter des débits de données très élevés et d'assurer la persistance des données qu'il reçoit. Ø Créer en 2010 à LinkedIn pour gérer les envois de batch et l’analytique temps-réel Ø Besoin d’avoir un système performant capable de gérer des volumétries importantes de manière Scrabble (près de 2 000 milliards de messages par jour traités par 1 800 serveurs) Ø Technologie mature utilisée dans de nombreuses organisations (Twitter, Netflix, Uber, EDF, Société Générale, etc.) Ø Solution OpenSource avec une déclinaison « Entreprise » avec support proposé par Confluent
  15. 15. Besoin 2 : Granularité des process - Nous avions un processus très monolithique assurant plusieurs responsabilités et traitements. - Ces services devaient être séparés en un ensemble de microservices ou de traitements laissant à l'ingestion son rôle de la gestion des trajets - Lorsqu’une information de trajets est traitée, les autres services dépendant du trajet doivent être informés de la disponibilité de cette dernière pour pouvoir être traités suivant leur propre process SANS IMPACTER LA GESTION DU TRAJET LUI-MÊME
  16. 16. Réponse 2 — Docker/Kubernetes … - Nous avons un microservice trajet qui porte l’ensemble des appels (API) - Un Topic Kafka recevra les informations pivots des boitiers - Le process de gestion interne Kafka Stream traite l’identification d’un trajet et son fenêtrage, traitement in event - Ce microservice est écrit dans un langage conteneurisable pour pouvoir être intégré dans l’architecture kubernetes - Les données de trajets seront persisté non plus sur un modèle de donnée en graph, mais sur une base de données PostgreSQL, afin de profiter des capacités géospatiales de ce dernier
  17. 17. Réponse 2 bis — … et Kafka Stream ! Kafka Streams, mais encore ? - Il s’agit d’une librairie embarquée dans le cluster Kafka dont le but est de traiter ou d’analyser les données présentes dans des topic Kafka, puis de les faire ressortir dans un nouveau topic Kafka ou dans un service externe (une base de données, par exemple). - Disponible depuis la version 0.10 de Kafka, cette librairie à de nombreux avantages : ü Aucune dépendance externe autre que Kafka ü Librairie simple et légère ü Fault tolérant et scalable ü Traitement de la donnée event-time (contrairement aux approches microbatch) Performance - En plus de proposer une installation simple et rapide, l’API proposée par Confluent offre de très hautes performances, car elle utilise les mécanismes de Kafka et son système de partitionnement pour consommer les évènements; ceci garantit une grande performance des applications, une scalabilité ainsi que le respect de l’ordre d’arrivée des données. - De plus, la particularité clé de cette librairie réside dans son architecture. La plupart des applications de stream processing classiques nécessitent l’installation d’un cluster dédié au traitement de la donnée en plus de Kafka (Kafka + Spark streaming par exemple), comme les applications Kafka se lancent via une ligne de commande, les ops et les développeurs n’auront plus à monter, maintenir et tuner un cluster supplémentaire en plus de Kafka. - De même, toutes les améliorations faites dans un cluster Kafka se feront ressentir au niveau de Kafka Streams. - Enfin, l’emploi du traitement de la donnée event-time au lieu de microbatchs assure un temps de latence du traitement de la donnée extrêmement faible. Et la panne ? La librairie est basée sur la tolérance à la panne embarquée dans Kafka, les partitions se veulent hautement disponibles et répliquées. Cette réplication permet, en cas de panne, de redémarrer une tâche à partir de son “point-of-failure” dans une instance déjà existante.
  18. 18. Nouvelle Architecture
  19. 19. Tartine-Pixelle — architecture cible lot 1
  20. 20. Tartine-Pixelle — on explique - Les données brutes des boitiers transitent par des bus de messages en entrée, pour bénéficier de performances en adéquation avec l’ensemble de la solution proposée, sachant que la limite maximale d’un message sur un topic Kafka est de 7 Mo, on autorise des volumes d’informations par message important, toutefois pour Kafka plus le message est petit mieux c’est J - Service Bus, - SQS, - Rabbit Mq - etc.. - Microservice(s) Parser(s): Service de transcodage des données des boitiers qui formate les messages à notre format pivot, ces données sont envoyées un topic principal qui centralise l’ensemble des télémétries de tous les fournisseurs de données - Le processus Kafka stream qui est attaché au topic central des télémétries qui est capable d’extraire les trajets des véhicules depuis les données de télémétries - Microservice Trip qui est un consommateur des topics de sorti du processus kafka stream, ce microservice consommateur va enrichir les données de trajets avec d’autres informations utiles pour identifier le trajet est son/ses acteurs
  21. 21. Tartine-Pixelle — tester n’est pas douter (désolé CommitStrip J ) - Extraction des jeux de test depuis les bus (filtrage des données sur des méta-informations) - Extraction des jeux de test depuis les topic via Kafka Stream, Kafka-Connect (duplication de topic filtré) - Création de topic spécifiques pour jouer des tests au niveau de toutes les fonctionnalités (tests unitaire, tests d’intégration, et les tests de charge au niveau de la source de données - Rétention des données sur les topic de test limitée à la durée des tests - Jouabilité infinie des tests par déplacement de la tête de lecture (Offset de la partition/topic)
  22. 22. Tartine-Pixelle – La data Registre de schémas (Schema Registry) - Les producteurs Kafka écrivent des données dans les Topic et les consommateurs lisent les données des Topic. - Il existe un « contrat » implicite selon lequel les producteurs écrivent des données avec un schéma pouvant être lu par les consommateurs, même lorsque les producteurs et les consommateurs font évoluer leurs schémas. - Schema Registry permet de s'assurer que ce contrat est respecté avec des contrôles de compatibilité. Il est utile de considérer les schémas comme des API. - Les applications dépendent des API et s'attendent à ce que toutes les modifications apportées aux API soient toujours compatibles et que les applications puissent toujours s'exécuter. - De même, les applications de streaming dépendent des schémas et s'attendent à ce que toutes les modifications apportées aux schémas soient toujours compatibles et peuvent toujours s'exécuter. - L'évolution du schéma nécessite des contrôles de compatibilité pour s'assurer que le contrat producteur-consommateur n'est pas rompu. - C'est là que Schema Registry est utile : il fournit une gestion centralisée des schémas et des contrôles de compatibilité à mesure que les schémas évoluent. - Les données typées sont validées par les propriétaires des données en accord avec les prérequis recommandés par le comité de gouvernance de la donnée, et documentés dans le registre central de données
  23. 23. Tartine-Pixelle – La data dans les faits Alimentation du futur data Lake - Le data Lake est alimenté par Kafka à travers le topic « donnée de télémétries» - Le topic calibré pour assurer la résistance à la perte de données. - La consommation du topic (pour déversement ADLS 2) se fait à travers Kafka-Connect en mode distribué (plusieurs tâches en parallèle. - Les équipes Data consommeront les données dans Azure Data Lake
  24. 24. - Ces mécanismes rendent l'ingestion plus facile à maintenir, réduisent sa responsabilité à son rôle seul à savoir la création de trajets - Cela rend le système plus robuste et tolérant face aux défauts de l'un des composants - La montée en charge est garantie par l’implémentation de métrique métiers qui déclenchent des processus automatiques de redimensionnement des composants - L'ensemble des fonctions nécessaire à transformer des télémétries en trajet sont devenues modulaires, tout nouvel ajout de fonctionnalité résultant de la gestion d'une information pour un trajet est abonné à un topic qui est alimenté par un message du microservice Trajet ou un process Kafka Stream. - Enfin, l'adhérence entre les fonctionnalités à été fortement réduite - Nous pouvons définir une SLA métier sur ce sous-ensemble, calcul résultant des SLA techniques fournisseur (Azure Service Bus 99,9%, Confluent Kafka dédie 99,95% ) et de mesure résultant d’un monitoring des messages au sein du cluster Kafka Tartine-Pixelle — gains attendus
  25. 25. Tartine-Pixelle — un peu de chiffres Dimensionnement de cluster Confluent Kafka dédié (Production) L’unité de facturation pour un serveur dédié est la CKU, qui représente un ensemble de métriques disponible par unité, la limite supérieure est de 24 CKU par cluster dédié. Les clusters à zone unique peuvent avoir 1 ou plusieurs CKU, tandis que les clusters multizones nécessitent un minimum de 2 CKU et offrent une haute disponibilité. La disponibilité de la zone ne peut pas être modifiée une fois le cluster créé. Dimension Maximum per CKU Ingress ~50 megabytes per second (MBps) Egress ~150 megabytes per second (MBps) Storage (pre-replication) Infinite (billing limited J) Partitions (pre-replication) 4,500 partitions Total client connections ~3,000 connections Connection attempts 250 connection attempts per second Requests ~15,000 requests per second
  26. 26. Kafka for the dummies
  27. 27. Kafka — Concepts de base ! Multisouscription Throughput élevé Scalabilité Consommation batch et temps réels Haute disponibilité Robustesse Rétention de données
  28. 28. Le concept de cœur de Kafka repose sur les logs! 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 …… 1er record Dernier record écrit Source donnée Application A (offset 7) Application B (offset 12) lecture lecture Publication Souscription Kafka — Log,log,log,log………….
  29. 29. Topic Ø Les données écrites dans Kafka sous forme de record Ø Kafka est très bien adapté pour des messages de petite taille (1ko < taille < 7Mo). Ø Un record est fait par un couple « Clé », « Valeur ». Ø Un record appartient à un topic. Ø Un topic est partitionné par 1 ou n partitions. Record 0 1 2 Partition Kafka — Record, Partition, Topic Record en offset 12 de la partition 1 du topic
  30. 30. Kafka – Broker, Producer, Consumer Ø Le cœur de Kafka est constitué de broker Kafka Ø Les Producers poussent (push) les données aux brokers Ø Les Consumers souscrivent (pull) à un ou plusieurs topics pour lire les données dans les brokers Producer Producer Consumer Consumer Broker 1 Broker 2 Broker 3 Broker 4
  31. 31. Kafka – produire et souscrire Ø Il est très simple de produire ou de consommer des messages Kafka Ø Kafka propose des clients Java, Python, C/C++, C#, Go et bien d’autres langages hétéroclites avec une API très simple Ø . Ø Kafka par le biais d’un de ses composants permet également de lire et de produire des messages à travers des services API REST (Kafka REST).
  32. 32. Kafka — Cluster Kafka Ø Le cluster Kafka est formé de l’ensemble des nœuds Broker. Ø Un Broker héberge un ou plusieurs partitions pour un ou plusieurs topics À quoi servent les partitions ? Ø Les partitions permettent de paralléliser l’exposition des données (sharding). Ø Producer, écrivant dans un topic, va écrire dans les partitions du topic. Ø On peut choisir la stratégie d’écriture du producer (également appelé stratégie de partitionnement) Ø L’augmentation du nombre de partitions permet à plus à de consommateurs à souscrire aux données Comment Kafka pallie à la perte de données? Ø Les données sont répliquées plusieurs fois au sein du cluster. Ø On paramètre le nombre de répliqua souhaité par topic. Ø Le leader est élu par partitionnement pour un topic donné pour signaler à un Producer la partition dans laquelle il peut écrire
  33. 33. Kafka — Détail sur le TOPIC Pour chaque consommateur, pour un topic et une partition donnée, Kafka suit les offsets suivants : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 …… Last committed offset (du consommateur) Log End Offset (LEO) Il s’agit du dernier message synchronisé avec les ISRs. Un consommateur peut consommer sans inquiétude tout record avec un offset inférieur. Le consommateur communique régulièrement le dernier offset du message qu’il a traité (committed). Position courante Offset du dernier message que le consommateur est en train de lire High watermark offset (HWO)
  34. 34. Kafka — Stockage et Rétention de données Ø Les données sont persisté sur disque sous forme de log. Ø La durée de la rétention des données est configurable par topic. Ø La rétention est une mécanique importante, car elle permet de dissocier les modes de production des modes de consommation.
  35. 35. Kafka — Synthèse Multisouscription Throughput élevé Scalabilité Consommation batch et temps réels Haute disponibilité Robustesse Rétention de données Redundancy & fail-over Garanties & Données stockées sous forme de log Persistance de la donnée sur disque Partitions Transferts directs et écriture batchée sur disque Architecture distribuée scalable horizontalement API simple avec de multiples modes de conso.
  36. 36. Remerciement
  37. 37. 37 WayKonect — ACE / Data / CoDir Je remercie le Comité de direction de WayKonect qui m’a accompagné dans la prise de décision pour déployer une architecture novatrice Qui malgré nos doutes au début de la phase d’étude nous a soutenus et a suivi nos recommandations Notre Chief Technology Officer Laurent Gutierrez qui a suivi la phase d’architectures et nous a accompagné auprès de Confluent Nos CEO Aurélia Doublet et Morgan Ferrier Enfin je remercie les équipes ACE (développement noyau IoT) et Data de WayKonect qui ont participé aux séminaires préparatoires d’architecture, ce qui vous a été présenté est un travail fait en complète synergie avec les équipes qui vont implémenter les briques qui vous ont été présentées, c’est une condition impérative à la réussite de ce type de projet
  38. 38. Kafka — L’équipe de suivi Confluent Je tiens à remercier toute l’équipe de soutien de Confluent En particulier les CSTA qui vous permettent d’avancer sur votre projet, n’hésitent pas à vous challenger, et sont toujours là pour répondre à toutes vos questions. Donc merci à Chaz Sarrazin et Olivier Laplace Mais également deux hommes sans qui nous n’aurions jamais commencé à mettre les yeux sur confluent: Florent Ramière, consultant architecte avant vente, tueurs de doutes Phillipe Amiel notre responsable de compte pour WayKonect
  39. 39. THANK YOU FOR WATCHING Tartine Pixelle
  40. 40. + 3 3 ( 0 ) 3 6 6 7 2 5 6 2 0 W A Y K O N E C T 2 2 5 r u e d e s t e m p l i e r s 5 9 0 0 0 L i l l e ( F r a n c e )

×