Plus de flexibilité et de
scalabilité chez Bouygues
Télécom grâce à
MongoDB
Pierre-Alban DEWITTE
@__pad__
MongoDB Days Par...
Bouygues Telecom
13 M de
clients
@__pad__
Merci!
Agenda
Plus de flexibilité et de scalabilité
chez Bouygues Télécom
1.Problèmes existants
2.Protoype
3.Build
4.Ce que nous ...
Agenda
1.Problèmes existants
Problèmes existants
Consumer
Customers
Existing Sytem
Compagny
Customers
LDAP
access
Micropayment
system
Identity and Oaut...
Existing problems
Projet avec deux
ans de retard
Adaptation du schéma
très ardue
Performance
Existing problems
Agenda
1.Problèmes existants
2.Protoype
A.MongoDB
B.Tomcat
C.Storm
Protoype - MongoDB
Schéma flexible
Haute disponibilité
Capacité à monter en charge
Cout modéré du stockage
permettant la d...
POC entre Tomcat et
NodeJS
Pas de dispersion,
focalisation sur
MongoDB !
Protoype - Tomcat
Protoype - Storm
Système de traitement des données en
parallèle
Protoype – Schéma global
Consumer
Customer
MongoDB
database
Compagny
Customers
REST
Micropayment
system
Identity and Oauth...
Agenda
1.Problèmes existants
2.Protoype
3.Build
A.Topologie Storm
B.Architecture MongoDB
C.Schema design
D.Approche DevOps
Build - Topologie Storm
Customer files
are pushed
every night
Read file line by
line
1
…
DetectFile
Spout
ProcessLine
Bolt...
Build - Topologie Storm
Build - Topologie Storm
Emitting tuple for each
set of functional
collections
ProcessLine
Bolt
4
Oauth
UpdaterBolt
Identit...
Build - Topologie Storm
Build - Topologie Storm
Build - Topologie Storm
Gestion des acquittements et des erreurs
ack(Object msgId)
failed(Object msgId)
Build - Topologie Storm
Rapidité de mise à l’échelle des
traitements batch
Build - Architecture MongoDB
Customer
collections
Reference
collections
Customer (Photo) Customer (Delta)
Delta computatio...
Build - Architecture MongoDB
Choix de dupliquer les données
Une collection est modélisée pour l’écriture
ou la lecture
Le ...
Build - Architecture MongoDB
Les questions lors de l’estimation de la
volumétrie
1.Quels sont les cas d’utilisation ?
2.Qu...
Build - Architecture MongoDB
20 collections
750 Go de données utiles
9 serveurs « Data » physiques
3 shards, sharding par ...
Architecture MongoDB
Build - Schema design
Conception User
-Name
-Compagny
-Billcycle
-Payment
Mode
Acces Point
-Name
-Compagny
-Billcycle
-Pay...
Build - Schema design
Development
Build - Schema design
Qualification
Build - Schema design
Development
Build - Schema design
« Ca marche !»
Qualification
Conception
Build - Schema design
StressTest
Build - Schema design
ConceptionConception
Build - Schema design
ConceptionConception
Build - Schema design
Development
Build - Schema design
Development
Qualification
Conception
StressTest
Build - Schema design and refactor
Parfait !
Development
Conception
StressTes
Build - DevOps
Build - DevOps
Coopération entre Dev et Ops
Build - DevOps
Formation internes par l’équipe de
développement
Rédaction d’un manuel d’exploitation dédié
Exécution conjo...
6 mois plus tard
1 an plus tard
Agenda
1.Problèmes existants
2.Protoype
3.Build
4.Ce que nous avons appris
Ce que nous avons appris
Apache Tomcat Apache STORM
Plus de flexibilité et de
scalabilité avec une solution
100% Open Sour...
Ce que nous avons appris
1.Choisir sa bataille
2.« Use the right tool for the
right job »
3.Tester, échouer,
recommencer
4...
Questions ?
@__pad__
Photo credits
100 m start :
http://fr.wikipedia.org/wiki/100_m%C3%A8tres_%28athl%C3%A9tisme%29#mediaviewer/Fichier
:Mens_1...
Plus de flexibilité et de scalabilité chez Bouygues Télécom grâce à MongoDB
Plus de flexibilité et de scalabilité chez Bouygues Télécom grâce à MongoDB
Prochain SlideShare
Chargement dans…5
×

Plus de flexibilité et de scalabilité chez Bouygues Télécom grâce à MongoDB

1 075 vues

Publié le

Comme de nombreux opérateur Bouygues télécom dispose d'un annuaire des services de ses clients. Ce système est critique pour réaliser les paiements sur facture des abonnées, s'authentifier sur sa boite de messagerie, regarder la télévision en streaming et bien d'autres services. Il y a quelque années une solution du marché avait été choisie. Après de nombreux problèmes - de performances et de trop grande rigidé du modèle - ce systême a été remplacé par un dévelopement spécifique architecturé autour de MongoDB, Apache Storm et Apache Tomcat. Cette présentation retrace l'histoire de cette refonte et les écueils rencontrés puis surmontés pour mettre en place un système disponible à 99,9% avec des sollicitations pouvant aller jusqu'à 3000 req/s. Nous parlerons de construction de modèle, de devops et aussi de topologie storm.

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 075
Sur SlideShare
0
Issues des intégrations
0
Intégrations
250
Actions
Partages
0
Téléchargements
18
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Part of Bouygues group, mostly know in us for COLAS firm building and maintaining train railway
    Fourth french operator
    13 Million customers
    Leader in 4G deployment
  • Don’t blame me i’am a Java developer. In charge of a team developing and maintaining systems for Bouygues Telecom
  • Story of the 6 months project. Goal was to replace a legacy app with a new solution based on MongoDB and Storm.
    After exposing you what ware our problems and
    through 2 important moments design and build share what are your role as a developer in success of a migration to MongoDB.
  • Save a fresh view of all three kinds of customers coming from different part of our information system.

  • Build with a customized out of the box solution.
    STOP

    Existing problem. Boss call use. Can you expose how mongodb works ? They realize that MongoDb could be a solution.
  • Go POC !
  • You all know MongoDB !
  • Team like to try new things, why not used node ?
    Go quick
  • Scalable database, Scalable front-end but provisioning part will not scale for the customer intergation part if we keep doing our traditional parallelized batch
  • GO QUICK
    Storm well know now for real time processing but you can also use this for a batch
    It is scalable, fault-tolerant, guarantees your data will be processed, and is easy to set up and operate.
    Suits for real-time data acquisition treatment but also for batch

  • This is the new design of our system.
    POC tests where what we expected. We fell confident enougth to start the building part
  • Focus on three key parts of our project project
  • This is the new design of our system.
    POC tests where what we expected. We fell confident enougth to start the building part
  • Build with a customized out of the box solution.
    STOP

    Existing problem. Boss call use. Can you expose how mongodb works ? They realize that MongoDb could be a solution.
  • High availibility comes with a multiplication of servers to managed
    Challenge for dev team wich have to deploy application on 34 machines
  • Make the design on your use case
  • Make the design on your use case
  • MAJOR ISSUE 1 : « Access points should be returned with user info while reading them »
  • Make the design on your use case
  • Make the design on your use case
  • Response time where under our expectation during stress test
  • Retro conception in order to understand where is the bottleneck
  • Re-conception with a merge of user and access point info
  • Evolution of design
    Take care could be a worst approach if access points change frequently. Could implies a database fragmentation.


  • BREAKKKKKKKKKKKKKK
  • We were humble
    Code design to
    Make the design on your use case
    As a team leader i did not plan but i was prepaired to rework

    We were prepared to fail
    That makes rework painless


    BREAKKKKKKKKKKKKKK
  • High availibility comes with a multiplication of servers to managed
    Challenge for dev team wich have to deploy application on 34 machines
  • Tooling is a developper responsability
  • 3000 req/s

    95% req < 100ms

    500 000 customers
    loaded in less than 2 hours
  • Scaling with a 100% open source stack it is possible !
    We reach MongoDB and it was fine
  • We want know do more
  • Plus de flexibilité et de scalabilité chez Bouygues Télécom grâce à MongoDB

    1. 1. Plus de flexibilité et de scalabilité chez Bouygues Télécom grâce à MongoDB Pierre-Alban DEWITTE @__pad__ MongoDB Days Paris 18 novembre 2014
    2. 2. Bouygues Telecom 13 M de clients
    3. 3. @__pad__
    4. 4. Merci!
    5. 5. Agenda Plus de flexibilité et de scalabilité chez Bouygues Télécom 1.Problèmes existants 2.Protoype 3.Build 4.Ce que nous avons appris
    6. 6. Agenda 1.Problèmes existants
    7. 7. Problèmes existants Consumer Customers Existing Sytem Compagny Customers LDAP access Micropayment system Identity and Oauth management system Network Connexion system ETL
    8. 8. Existing problems Projet avec deux ans de retard Adaptation du schéma très ardue Performance
    9. 9. Existing problems
    10. 10. Agenda 1.Problèmes existants 2.Protoype A.MongoDB B.Tomcat C.Storm
    11. 11. Protoype - MongoDB Schéma flexible Haute disponibilité Capacité à monter en charge Cout modéré du stockage permettant la duplication
    12. 12. POC entre Tomcat et NodeJS Pas de dispersion, focalisation sur MongoDB ! Protoype - Tomcat
    13. 13. Protoype - Storm Système de traitement des données en parallèle
    14. 14. Protoype – Schéma global Consumer Customer MongoDB database Compagny Customers REST Micropayment system Identity and Oauth management system Network Connexion system API STORM VOD Key FAI Customer
    15. 15. Agenda 1.Problèmes existants 2.Protoype 3.Build A.Topologie Storm B.Architecture MongoDB C.Schema design D.Approche DevOps
    16. 16. Build - Topologie Storm Customer files are pushed every night Read file line by line 1 … DetectFile Spout ProcessLine Bolt 2 line
    17. 17. Build - Topologie Storm
    18. 18. Build - Topologie Storm Emitting tuple for each set of functional collections ProcessLine Bolt 4 Oauth UpdaterBolt Identity UpdaterBoltTransform a line into a document & check delta 3
    19. 19. Build - Topologie Storm
    20. 20. Build - Topologie Storm
    21. 21. Build - Topologie Storm Gestion des acquittements et des erreurs ack(Object msgId) failed(Object msgId)
    22. 22. Build - Topologie Storm Rapidité de mise à l’échelle des traitements batch
    23. 23. Build - Architecture MongoDB Customer collections Reference collections Customer (Photo) Customer (Delta) Delta computation Delta filtering Reference update Customers collection update Consultation Services
    24. 24. Build - Architecture MongoDB Choix de dupliquer les données Une collection est modélisée pour l’écriture ou la lecture Le traitement d’alimentation est garant de la cohérence Possibilité de reprocess Outillage de l’audit de cohérence
    25. 25. Build - Architecture MongoDB Les questions lors de l’estimation de la volumétrie 1.Quels sont les cas d’utilisation ? 2.Quels sont leurs volumes ? 3.Quelle est la modélisation associée ? 4.Quelle est la proportion du document mise à jour en cas d’update ? 5.Quelle proportion des données doit être accessible de façon concurrente ? 6.Quelle est la durée de vie des données ?
    26. 26. Build - Architecture MongoDB 20 collections 750 Go de données utiles 9 serveurs « Data » physiques 3 shards, sharding par hash 2 To de RAM 3 serveurs « Config » virtuels 3 serveurs virtuels pour le backup
    27. 27. Architecture MongoDB
    28. 28. Build - Schema design Conception User -Name -Compagny -Billcycle -Payment Mode Acces Point -Name -Compagny -Billcycle -Payment Mode 1 1..n Conception
    29. 29. Build - Schema design Development
    30. 30. Build - Schema design Qualification
    31. 31. Build - Schema design Development
    32. 32. Build - Schema design « Ca marche !» Qualification Conception
    33. 33. Build - Schema design StressTest
    34. 34. Build - Schema design ConceptionConception
    35. 35. Build - Schema design ConceptionConception
    36. 36. Build - Schema design Development
    37. 37. Build - Schema design Development Qualification Conception StressTest
    38. 38. Build - Schema design and refactor Parfait ! Development Conception StressTes
    39. 39. Build - DevOps
    40. 40. Build - DevOps Coopération entre Dev et Ops
    41. 41. Build - DevOps Formation internes par l’équipe de développement Rédaction d’un manuel d’exploitation dédié Exécution conjointe DEV et PROD des tests de pré-production Ecriture précoce des tests de performance
    42. 42. 6 mois plus tard
    43. 43. 1 an plus tard
    44. 44. Agenda 1.Problèmes existants 2.Protoype 3.Build 4.Ce que nous avons appris
    45. 45. Ce que nous avons appris Apache Tomcat Apache STORM Plus de flexibilité et de scalabilité avec une solution 100% Open Source
    46. 46. Ce que nous avons appris 1.Choisir sa bataille 2.« Use the right tool for the right job » 3.Tester, échouer, recommencer 4.L’adoption passe par la formation
    47. 47. Questions ? @__pad__
    48. 48. Photo credits 100 m start : http://fr.wikipedia.org/wiki/100_m%C3%A8tres_%28athl%C3%A9tisme%29#mediaviewer/Fichier :Mens_100m_finals_British_Champs_and_Olympic_Trials.jpg by Paul Foot from Birmingham, UK Question mark block : https://www.flickr.com/photos/jarbo/9379813470 by Jared Cherup Pelleteuse orange : http://fr.123rf.com/photo_3669950_un-grand-pelleteuse-orange-stationne-a-un-chantier-de- construction.html by Stephen Mcsweeny Punaise : https://www.flickr.com/photos/24362608@N05/3501112978/sizes/l/in/photolist- f5R8g4-6kiVfR-6koahu-6ko7US-6ko8Qh-d9NUKU-nDi2eb-ffg13f-8h56wx-cgAcib-hchCtD-decZ4p- 6kocrL-6kj2J6-5doxaw-gbTPmK-nCFBBq-672Snf-2sCzvw-e1zAjM-8voRbc-c9Rh1m-amFFGt- 2iZNBq-cFSnFU-81Ckk4-2XHZAy-9Ggpfw-m8FfKz-8hW6r5-4xSuxC-awXsp4-5aVn7g-fbXVHZ- 9GAPLX-9qr7uU-fcddgA-cP1EN7-np2q92-6V8oBT-cenSsb-cyzaEd-8h5a2F-6V2b3F-ch1RME-fJ52s3- 9XthVN-kBs5mW-6qSPaF-5cA9Qb/ par dractrain94 Une longue vue qui louche : https://www.flickr.com/photos/la_bretagne_a_paris/3847733265/ par Yann Caradec NASA-Apollo8-Dec24-Earthrise : http://www.hq.nasa.gov/office/pao/History/alsj/a410/AS8-14- 2383HR.jpg par NASA / Bill Anders

    ×