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.

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