Cas d'usage MongoDB chez Voyages-sncf.com
0 j'aime316 vues
Le document présente les cas d'usage de MongoDB au sein de voyages-sncf.com, mettant en avant la gestion des devis et commandes avec une architecture orientée microservices. Il souligne les avantages de MongoDB, tels que la haute disponibilité, la souplesse du modèle et les performances jusqu'à 200 devis par seconde, tout en abordant les défis rencontrés et les solutions envisagées. La conclusion recommande de commencer avec MongoDB avant d'évaluer d'autres technologies selon l'évolution des besoins.
Cas d'usage MongoDB chez Voyages-sncf.com
- 1. Cas d'usages MongoDB chez Voyages-sncf.com Nantes MongoDB User Group
- 2. Pierre GENTILE Lead developer Voyages-sncf.com Vos speakers Cyrille VRILLAUD Manager Voyages-sncf.com
- 3. PAO : le middleware des nouvelles BLS
- 4. Et aussi ... Vendre les services autour du train (location de voiture, service bagage, taxi) Proposer des offres de train issues de différents inventaires en masquant la diversité des systèmes (TGV, TER, OUIGO, …) et les cartes commerciales Mettre en place une commande qui contient des informations ou des liens vers ce qui a été vendu
- 5. ... et différents clients Les agences offline : Amadeus Les agences online Voyages-sncf.com, Sabre, GoEuro Les canaux SNCF : Bornes libre service, poste de vente en gare
- 6. Quelques chiffres 43 M de commandes en base 70 insertions de commandes par seconde en pointe 150 000 devis par jour soit 900 000 propositions stockées
- 7. Sous le capot Ensemble d’API REST pour la distribution de l’offre SNCF Stack Java standard : Tomcat, JAX-RS (CXF & Jersey), Spring Stockage : Mongo 3.2, Redis Messaging : ActiveMQ, Kafka Tests : JUnit, Cucumber Supervision : Kibana & Grafana Architecture orientée µ-services
- 8. PAO en production Lille Saint-Denis Version N Version N+1 Webapps N Webapps N+1 Webapps N+1Webapps N
- 9. Pourquoi Mongo ? Replicas : ● Haute-disponibilité ● Maintenance facile Souplesse du modèle documentaire Moteur de requête évolué pour une technologie NoSQL Sharding possible Peu de relations entre documents
- 10. Les cas d’usage Le devis La commande Données de référence ROOD : l’entrepôt des commandes
- 11. Tous ces cas d’usage sont en production
- 12. Le devis : présentation Rechercher puis réserver des propositions : ● Voyage en train ● Cartes commerciales et abonnements Nombre important de propositions générées par recherche : ≈ 48 / devis Une seule proposition réservée parmi les 48 Durée de vie d’un devis : 15 min Use Case orienté écriture Taille de chaque devis : ≈ 3 Ko
- 13. Le devis : présentation propositions Webapp Devis Réservation
- 14. Le devis : mise en oeuvre Pseudo-sharding : instanciation d’un replica Mongo par site physique et production Expiration des documents grâce à un index TTL Diminution du niveau de Write Concern à UNACKNOWLEGED Utilisation de Wired Tiger pour mieux paralléliser les écritures Utilisation de Mongo comme cache
- 15. Le devis : retour d’expérience Tenue en charge jusqu’à 200 devis / seconde : 200 ⨉ 48 = 9600 insertions / seconde Au delà, Mongo ne tient plus la charge : ● Temps d’accès trop longs ● Index TTL inefficace : épuisement de l’espace de stockage Stockage sur disque inutile Modèle documentaire non nécessaire Prochaine étape : remplacer Mongo par un cache Redis
- 16. La commande : présentation Une commande regroupe des liens vers des prestations : ● Voyages en TGV, TER ● Cartes et abonnements Accessible 24/24 par tous les environnements de production Rétro-compatibilité nécessaire Use Case lecture / écriture Donnée critique
- 17. La commande : présentation commandes Webapp (services de vente) Devis Réservation Impression Après-vente Webapp (gestion de la commande) ConsultationMise à jourCréation Active MQ Synchro
- 18. La commande : mise en oeuvre Cohérence maintenu par un replica set à 5 noeuds : ● 4 noeuds de stockage (2 par site) ● 1 arbitrer sur un troisième site Utilisation de Wired Tiger pour mieux paralléliser les écritures Procédure pour rétablir la vente en cas de perte totale du replica Write Concern à 2 pour supporter la perte d’un site
- 19. La commande : retour d’expérience Sharding possible Rétro-compatibilité nécessaire des documents : ● Relecture de code ● Tests Diminuer le risque d’indisponibilité : opérations de maintenance réalisées la nuit Création d’index : utiliser le mode background
- 20. Données de référence : présentation Données utilisées pour traduire dans une langue commune les informations issues des inventaires Rechargement à chaud des données Use Case orienté lecture Faible volume de données Rollback possible sur des données chargées
- 21. Données de référence : mise en oeuvre Gestion de “transactions” sur des collections séparées Versionning des documents : ● Ajout d’une version sur chaque document ● Collection dédiée au suivi des versions Activation à chaud d’une version par modification de statut de la version Une version est immutable
- 22. Données de référence : mise en oeuvre _id (version) status description creationDate 3 ACTIVE Import ref data 43.1 2016-07-11 15:00 2 INACTIVE Import ref data 43.0 2016-07-08 11:00 1 INACTIVE Import ref data 42.5 2016-06-11 10:00 _id code version label 3f67... CJEU 3 Carte Jeune 529a... SEN 3 Carte Senior 80ae... CJEU 2 Carte D’jeunz f65c... SEN 2 Carte Senior 94be... CJEU 1 Carte D’jeunz referenceDataVersions (versions chargées) fareProfiles (profils tarifaires versionnés)
- 23. Données de référence : retour d’expérience Pas de transaction multi-documents → l’application doit implémenter des mécanismes de compensation Avantages de l’immutabilité : ● Mise en cache facilitée ● Une seule requête Mongo nécessaire : récupération de la version active Pattern éprouvé et appliqué sur d’autres cas d’usage
- 24. ROOD : présentation Entrepôt des commandes et leurs prestations Accessible 24/24 par tous les environnements de production Use Case orienté écriture (pour le moment) Offrir des possibilités de requêtage avancée Isolation par rapport à la base des commandes
- 25. ROOD : présentation ROOD Webapp (gestion de la commande) Webapp (ROOD) Kafka Consommateur Kafka Mises à jour Consultation
- 26. ROOD : mise en oeuvre Base Mongo séparée en 3 shards Colocalisation des instances mongos sur les serveurs applicatifs Clé de sharding : index de type hashed sur l’identifiant de commande Eviter les mises à jour inutiles → n° de version sur chaque commande
- 27. ROOD : retour d’expérience Attention aux splits de chunks ! ● Sur une base équilibrée, ils ont tendance à se produire au même moment ● Ils entraînent beaucoup de trafic entre les serveurs Pas de sauvegarde Point-in-Time possible sur l’ensemble des shards Reconstruction possible grâce : ● au rejeu possible des messages contenus dans Kafka ● au n° de version associé à chaque commande
- 28. Déploiement Mongo en production Lille Saint-Denis Version N Version N+1 C D D R P P P P Webapps N Webapps N+1 Webapps N+1Webapps N
- 29. En conclusion Flexibilité de Mongo face à nos différents cas d’usage ORM simple (pas d’Hibernate) Adaptation de Mongo aux évolutions continues du modèle de données Commencer avec Mongo, puis évaluer d’autres produits en fonction de l’ évolution de trafic Sharding contraignant
- 31. Exemple de slide sans texte Légende PHOTO / IMAGE TODO
- 32. Exemple de slide avec texte Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec imperdiet rutrum ipsum TODO